Patch following music to control motor. work in progress ;)
Hi,
I'm trying to select a list of data with [switch] controlled with the knob at the right top.
But I have a bug, the data list is not good. I guess I need to refresh the data just before changing data.
What should I do, please?
Thank a lot.
I did a patch in order to refresh data when I 'am making changes with list 1
But I think there is a more elegant way to join a 11 dynamic list with 7 different index?
Could you adapt it or show me the way ?
Thanks a lot, exactly what I want and keep on develop.
I would like todo an other thing and I guess that I need to record 2 list of 11 datas and add this data.
The aim is to increment rotation of each knob by adding the former data with the actual data, then add modulo 32 in order that rotation is set between 0. and 32.
here a list of 11 position
11.0792 0.791861 18.865381 12.694014 11.265123 8.106085 16.827556 13.140423 12.191384 14.466989 18.7
here a list of of 11 new position
15.416 15.416 16.374557 15.64894 16.262595 16.074036 16.217383 15.636523 15.887823 15.713601 16.1626
I want to add each data and finish with modulo 32.
position of each knob follows the MAX envFollower.
But I can't mange to record these 11 different position. all data after [coll] are the same. :(
*scheduler overload and waste of objects alarm*
wakes up.
...or do the modulo on your own. (here for (a+b)%32.)
vexpr ($f1+$f2)-int(($f1+$f2)/32.)*32.
Hi.
Thanks for yours answers.
Actually, I would like to see how the sound could be propagated to 11 different knob
As you can see at the bottom of the screenshot I tested a method with 3 knob moving on clockwise way.
But to be perfect I would like that all knob go forward without going backward as we can see sometimes.
I don't know how to do that.
Hi,
Thanks again and thanks a lot.
Position of each knob will be use to control steppers motor.
To control motors with a global harmonic shape , I would like to use your patch as envelop follower detector
I would like to use the level of the signal each 10 cycle and assign the same phase offset between each knob. Phase Offset is proportionnal of the signal detected. The phase shift is added to the old one. Those that were detected 10 cycles ago.
If the level detector is 1.0, I would like to have a phase offset between each knob set as PI, or 180°
If the level detector is 0.5, I would like to have a phase offset between each knob set as PI/2, or 90°
If the level detector is 0.1, I would like to have a phase offset between each knob set as PI/10, or 18°.
Here your patch with the envelop follower. It doesn't kill Max this time!
I use envelope follower to have an moving average of the signal detected, in order to have "smoother " signal
Here an other patch giving same offset phase
I think I have to mix both patches, but I'm afraid to loosing me for nothing 8(
Hello, Thank you very much for your patience and involvement.
For the moment, I would like the motors to be offset from each other, always adding the same phase difference between each of them compared to their previous positions. This phase difference depends on the level of the signal detected every 100 ms.
As several interpretations are possible I made a drawing. In blue I show where we add phase.
Hi,
Big thanks. Exactly what I needed ;)
Moreover, by making these two parameters independent:
cycle value with 10 outputs at 100 ms interval.
update the level value at count 1 every 100 ms.
I found some nice beautiful movements that follow the music. I can adjust this movement by adjusting "signal detected update between 10 and 100 ms"..
Then I have a last question to control stepper motors.
I would like to have a counter of rotation for each knob.
I think by doing if previous value is upper than actual value then add 1.
Could you show me the way ?
Hi.
Thanks so much.
I will use this patch with very good "playability", adding some small features.
I adapt your patch to create a M4L device like this in presentation mode
But I have this with Live
But it's just a bug of presentation. We shouldn't see [loadmess25]
I really would like , for the moment, to be able to switch moves of knob going to a CCway.
And spin counters should subtract 1 every spin.
Could you please, trying to do this ?
HiIIIIII,
Very very nice!!!
It is absolutely great. Thanks so much!
I add CW rotation following a function like this :
And now we can map the position of the bottom right knobs to other Live parameters.
In the future I will have to add rotation from the function in both way, not only in CW.
Mouvement of these knobs with counters will be the movement of motors.
Thanks again, aGAIN and again!! ;)
Hi !
I think I understood your patch [control], it 's almost perfect for my use, but I need improve the patch to have a more harmonic movement.
I would to synchronise detection in order that if we set speed at 10, data coming in inlet 5 changes only each 100 ms. If we set speed at 50 data coming in inlet 5 change only each 500 ms.
This way, knobs should have always the same phase shift before the next detection of signal.
I'm not sure we have to use [zl.stream] or [bucket]
Ps: I'm not sure I'm asking for what I want very explicitly, but my previous drawing would help with understanding
Hi.
I tried to well understand [grab] but I can't . But I found a manner to grab the value detected form the counter 10. This way, I see movement all of knobs as I wanted.
Here the entire patch
So now we have, for example, if knob '10' goes from value 10 to 20 =>
knobs 1 to 9 go from 10 to 20. It is what I wanted.
And now, I would like that if knob '10' goes from 10 to 20 =>
knob 1 go from 10 to 19
knob 2 go from 10 to 18
knob 3 go from 10 to 17
......., ....,
knob 9 go from 10 to 11
That's means that we have to add the same value to each knob
minus 10% for the first one,
minus 20% for the second,
...,..,
minus 90% for the third
I think there is a trick that I don't know
Yes, I'm sorry. I don't speak properly.
I have found a solution and the movement is exactly as I wanted ;)
I'm sorry to not speak properly, I 'm trying to do my best.
Thanks so much
here my patch, I let it for people
Just a question,
In your former patch in which I just added a sound player, when you select CWW and you stop the sound movement still turning. Can you try to fix it please?
Hi!
Thank again for simplify and improve the patch ;)
I will do changes from your patch to mine.
I changed the manner to add the same phase offset between knob, and I don't have problem anymore when I go CCW.
In my entire patch, processes are from right to left.
First is your patch + Second is a manner to trig rotation + Third is a manner to add phase offset between buttons.
It works well, all buttons are always with the same phase shift.
An interesting new feature could be the automatic selection of 0 to 14 of the button (on the left marked in pink) in proportion to the detected sound. How could we do this?
Hi,
I sets lots of dials to see all processes managing the final movement.
Your patch [control+scaler] works perfectly. I 'm going to plug it with the others features, (rotation and phase shift) as soon as possible.
Also, I see the pink dial that change continually of values with the signal detected, but I would to trig the change of the value of the pink dial only when the counter from [control] is at 1. Could you set up this please?
You said " You can do all 3 parts in a single addition ", you mean like this ?
Rotation is given from data coming from [scale 0.1 0. 32.]. How can I do to get data only each 20 ms. In order to add to the two others datas, the data of rotation only each 20 ms.
Thank you in advance.
This looks really cool!!
I have to see how this patch controls the movement of my art installation. I'll see if the movement is smooth and consistent with my concept of followed musical movement.
To do this, I will trig separately the rotation and phase shift with 2 switch M4L's button .
This way, I could see what is the best way to follow the movement of the music.
And later, find a trick to automatise rotation and phase offset. ;)
To show you the global idea, you can see this simulation
I did this with Processing but this software is less well suited than Max to choreograph a movement
Hello,
I have modified the layout of your patch, it is now suitable for an M4L device.
As you noticed, there is something to adapt with the phase shift recall operation.
I think the movement of the buttons should go forward with each significant movement of the pink live dial.
To do that, we need to add the previous phase shift with a actual phase shift as soon as the pink dial moves.
For the momement, if the pink dial go from 0 to 1 and from 1 to 0, knobs go forward and backward, while i would like they go always forward.
I think it is this object to adapt
Thank you again
Ps: Since the last patch you have made, there is a bug with the counter rotation now.
Here the your patch adapted for M4L device
Hi,
Sorry for my English, but I see your last patch and it reacts as I wanted. ;)
Now when I move the recall phase offset from 2 to 3 and 3 to 2 all knobs go CW. Great!
You asked
anyway if you add 19 and 22, then it would become 9 (after &32)
and so drop from 19 to 9.
To fix this we can test this, if the next number is smaller or equal to the previous one AND pink dial is changing --> add 1 to the counter. This way motors will go always forward, in the same way, CW or CCW.
But there is still a problem with [turns], the counter of turn adds 1 turn each time there is only a little offset.
Same problem in CCW mode [turns] subtract 1.
Globally, to control and set precisely all the entire movement we have to make 3 processes independently.
Offset, rotation and phase shift.
To do that we should be able to trig rotation or recall phase shift even if the blue button start is off o even if there is no sound.
In the future I think it will be nice nice to control offset and phase shift with two diffrent sample of sound, one to control offset and the other to control phase shift.
I undestant that I change the way to control the entire patch and i 'm sorry in advance if is going to be hard to do. But i'm sure result will be fine.
Thank u again to improve the patch so fast. It's a pleasure.
Hi,
I understood what you said. Indeed there is a problem.
I found a solution. I will send the patch tonight or tomorrow.
Thanks to be smart !
Hi,
The counter is working fine now!
For the moment, forget the problem you noticed
It is not possible to say what happened when dial jumps from 12 to 29.
did it jump 17 or 17+32 forward ? or 15 backward ?
You patch is nicer that I asked ;)
When I add rotation and choose CCW, I see that the dials rotate in CCW. Great !!!! This way I don't need to change the drawing of the function to change the direction of rotation!
Also, I see that rotation is triggered by the interval.
That's a good idea, I wanted to do that later, and you did it now. That's very nice ;)
Now, I think it is my last question :
Would it be possible to add a feature that adds rotation continuousely, regardless of interval?
Thank for all!
sure it would be possible , one could perform calculation of all 3 inputs
whenever something changes, but that would disable time offset between dials.
all you need to do is to use pak f f f instead of pack f f f for all 10 dials.
But that would run on 20ms interval ... to fast for arduino ?
one could reduce line grain interval .. if needed.
as third option you could keep using pack f f f,
but use switch that triggers output when rotation changes independent of counter interval
Undertood.
I will switch between two processes then, one with pak fff and the other with pack fff
Just to tell u an other thing,
To control the movement of the rotation, I will remplace the function to control the rotation with a live dial button in order to map it in Live.
I will map this button with the movement shaped with this M4L device.
With this M4L device, I will control speed and shape of rotation.
I hope you will keep on follow me in my research!!
Please don't complicate the controls patcher.
if you use pak f f f then all inputs, including phase shift
will trigger output immediatelly.
If you want only rotation to do that, then rather that pack f f f
with switch as shown on last screenshot.
if you know no better but to use that shaper device,
then at least measure the rate of it's output,
and if needed slow it down.
Ok. I will keep on eye this parameter ;)
I
Good morning,
I have a problem with the rev counter add +1 when it shouldn't.
The rev counter works well with each of the features,
offset additions list
rotation
phase shift
The only problem is when I use [change] to recall phase offset, counter of rev adds 1 almost each time each time the recall phase offset change while it shouldn't .
Happily it works well with [change+].
Could you, please see if you would mange to fix it? with [change]
The trigger enabling " add phase shift to istelf %32 " is this
I have added a gate in the patch [all-control] in order that when the knob of " recall phase shift " change, the rev counter works well.
I would like, if it is possible, that rev counter works well with [change] (coming from the left of the screenshot) not only with [change+] ( coming from the middle of the screenshot).
The bug is with the counter rev.
It works with [change+], I don't understand why it doesn't work with [change]
I am not sure to be very explicit, let me know what I should to say to be well understood.
I really don't know what counter rev is and what means that it works well.
look into change help file to understand modes, and see why change +
and change - make no sense here - they don't pass values out, only
show moving direction.
If you want to pass phaseshift only when values change, you don't need gate,
it will only give you timing problems.
Better insert zl.change which passes whole list only if it changed.
another thing which make no sense to me is this Dias/En button / gate :
Hello,
I am completely sorry to complicate my questions so stupidly, and I hope you will apologize me.
I should proceed step by step, otherwise it is too complicated to make myself understood, especially with haphazard translations.
Actually my question is about our last post from 3 august.
So, I took your last " worked well " patch in which I have just changed
[pack f f f] by [pak f f f]
Here
That is why the rev counter adds 1 count as soon as the "recall phase off” button changes.
rev counter are computed in the patch p turns.
ps: I also changed the formula in the [p shifts] patch. The movement corresponds more to my basic idea.
That is not true, in the patch you posted on 24 august you modified patcher all-control into unusable state.
Read again my posts from 01 and 02 august related to turns counter.
You seem not to understand that your values JUMP,
and NEVER really cross ZERO POINT.
Also read again my post from 03 august, to understand what difference between pak fff and pack fff means, and why you should insert this,
if you want to keep offset between 10 dials:
If you don't want to have offset between dials, then delete all related to it,
I have no time to analyse your patches every time to understand what you changed, simply have no time.
In the last patch, you even disabled audio meter level competely.
Hi,
Thank you for answering me.
I made the change you made in your last screenshot to the August 3 patch.
Everything works perfectly.
I am absolutely sorry. I should have finished this last step as soon as you posted it.
" Je me suis emmelé les pinceaux " <=> “I got my brushes tangled”
Thanks again
Here is updated patch from 3 august with some changes to cw-ccw patch,
turns patch which should disable first move , added rotation trigger/switch, and your new shift patcher.
Hello,
I just saw your latest update.
All features are very responsive as expected. That's great! Thank you very much.
To summarize when live mode is selected, all blue buttons move with an interval between 50 and 200 ms.
To finish an important step of this patch, I would like to add two features that I can't do myself, or that I will do badly.
I would like another behavior of all motors.
In a first mode called "phaseShift_only", I would like that when the pink live dial moves,
all blue live dials move together, without interval, nor the shift addition list.
In a second mode called "phaseShiftO_with_interval_offset", I would like that when the pink live dial moves,
all the blue live dials move together without interval,
and add the offset addition list with an interval of 50 to 200.
This way, we can compose a movement with a great playability!!
I hope you enjoy the idea.
That is not as easy as you think.
You have 3 sources of control :
1 audio level + interval + offset
2 rotation
3 phaseshift.
All of them can now be activated individually
Now you want modes where for example only phaseshift works without the others.
How do you want to do that ?
stop the others and disable activation of them while this mode is on ?
what about offset which was allready applied to dials ?
keep values with current offset and just move them ?
or set all dials to some value and have them all move using same value ?
If you want me to do this changes for you, no problem ,
but only if you describe in detail how shoud all that work,
how many modes, how to switch modes,
and exact behaviour of each component within each mode.
What to do with individual switches for all 3 inputs ?
Without that precise infos I can't do anything.
Hi,
You are right, there is indeed a problem with index 1
So I changed [scale] like this [scale 0. 1. 2 14] to not recall index 1
Now, if you start the patch and click on [ezdac~] to hear the sound, you can see that the buttons all move at the same time and that the rev counters work well
If you click on the start button, you can see that the buttons are well offset with the time interval
I changed the rotation to make a turn in 8000 m.s
Now the movement is fluid, the offsets of the "offset addition list" are clearly visible and the "phase shifts" advance at the same time.
Everything is perfect! But I don't understand why the index 1 of the recall phase offset makes the rev counter bug, while I changed the index 1 to +1. , as you pointed out to me.
But, I am super happy that everything works ;)
Thank you again, thank you very much!!
Hello,
I added different modes to enable/disable the 3 modes
To get phase shift only, the textbutton must be on stopOffset and the textbutton must be on offset+phase.
Also to control the phase shift more reactively, I added sel 6 in addition to sel 1
I also changed the shift-new patch as you pointed out to me.
In presentation mode the patch is now adapted for max4live.
Also, we can now map elements in live
Everything works, I will probably have other features later, but this is already very good.
Thanks for everything!!
Hi dear teatcher,
When the drumLoop is activated, we see that the first live.dial is not well offset compared to the others.
And when you stop the music or lower the volume to the maximum, live.dial1 repositions itself well in relation to the others.
Could you please explain and correct me?
By changing in patch [all-control....], [sel 1] by [sel 10], all live dial are well offset
but I'm not sure is the good method, but it works.
I don't understand what you mean.
I did not look at your patch from 30 august, you meant all is ok there.
but in this last one you again modified the patch in a wrong way.
for example :
wrong 1
wrong 2
wrong 3
wrong 4
and so on.
THIS IS NOT FROM LAST PATCH I POSTED:
Means you take different patches and forget which is current ?
Start from the beginning from last patch I posted.
don't change patcher objects offset, and don't touch patch chords, because I can't see the objects, and for me red is color for ON, and some dark for Off.
Sorry, I have no time to adapt to that, patch is growing too much to just take a short look and see all changes without loosing too much time.
Start by adding stuff one by one and verify that it works.
then proceed with next.
If you don't know how to do changes correct, ask and I will do it one more time for you.
I have removed most of my old replies, this thread became too long,
maybe you could do the same.
have a look at this patch:
I started modifying the patch from 26 august to add phaseshift
trigger same as for rotation. (which you asked for)
Also some improvements to turns counter.
take a good look at it, and if it makes sense, take it as starting point
to add new things.
But keep in mind what I wrote in previous post.
AGAIN : this is modified patch from 26 august.
It has old offset, phaseshift coll etc, not what you modified in last patch
Hi,
Thank you very much for all your comments.
As I have to speed up my project, I try to change things in the patch but apparently never properly.
Please excuse me.
Next time all the changes I will make them in green.
I saw the latest patch, and I just have a question.
Would it be possible for the turn counter to work automatically?
In the sense that when we use [function] to control the rotation in both directions, then if we rotate in CCW the turn count subtracts 1, in the CW direction it adds 1
if we set function like this for example
Thank for you help.
No - function is adding values no matter if previous value was higher or lower.
Only CW / CCW switch can do that in this concept.
if function was the only source of movement, and if it allways reaches min and max values,
one could match them to count up or down.
But that is not the case in your patch.
Good morning,
I took exactly your last patch from September 1st and I adapted its presentation so that it displays well in presentation mode. Like this it looks good on the M4L device.
I wanted to add the Align and rotateData functionalities but I think I did it badly.
In the all- control patch, I only edited and added green objects whose outlines are colored green. On the right you can see the rotate_data patch in which I added a zl.rot object.
Everything works as before, but now I have a problem with the turn counter only in the CW direction. While the turn counter still works very well in the CCW direction I don't understand why.
I hope you can resolve the turn counter problem.
Ideally, when [zl.rot] will work fine, we should be able to automate the rev counter, that's why I automated a TextButton CW/CWW.
Thanks for your help.
You copied patch items in presentation mode,
everything is missing in that posted patch.
I am not sure if I have time to get my brain again into all that again.
If I manage it, I will post.
But I allways had trouble understanding your intentions.
Like now : what means to align and rotate data ?
Difficulty is that you don't understand how stuff works in that complex patch,
and make expectations that one can do this or that by simply inserting
stuff in the process chain, which can't work most of the time.
for example :
"Everything works as before, but now I have a problem with the turn counter only in the CW direction. While the turn counter still works very well in the CCW direction I don't understand why. "
Hi,
I undestrand I'm sorry. I say to much things for nothing.
Here the patch
The knob rotStep (that you can see in the others screen shot) is set at 6. The value 6 goes to the inlet 3.
Here a screen shot of the patch rotate_data. [zl.rot] is set at 6 . The patch rotate_data is inside the patch all_control
Above you can see data moved from 6 locations.
I have problem when live.dial go in clock way
Here you can see the 10 buttons with rotStep set at 5
Here you can see the 10 buttons with rotStep set at 4
Button 2 went from 30.44 to 0.54 and the turn counter didn't change.
That's good! I explain that the live.dial went from 30.44 to 0.54. That means the live.dial is rotating counterclockwise. The TextButton is set to CW, so the spin counter works fine.
But the problem is that all the other turn counters added one to all the other live.dials.
The other live.dials are rotating clockwise, so it shouldn't have added one to the turn counter.
I think there is a problem with the way I connected the rotateData patch with [pak] and [unpack]. They are inside the all_control patch.
I hope you understand. I'll try to handle the Align functionality myself.
ps : Should I say " spin counters " ? or turn counter
" spin counters " ? or turn counter
that is irrelevant, keep it turn so we know allready what is meant.
the problem with that turn counter - we discussed that allready several times,
and I tried to explain why it can't work at all in my opinion.
because of value jumps when exceeding modulo range.
I was fiddling arround till you seemed to find it ok,
now something changed, I must see what...
...
...
...
after taking a short look.
you use textbutton to switch rotation on/off,
but pass that into bang, which toggles the gate ?
Why that mistakes again and again ?
If I see it correctly you rotate 10 values and expect that turn counter can work with that ?
No way.
because now a value can move in unexpected way.
how to tell if 20 -> 1 happened because of added value,
or because you rotated the list so that now it got value from
different list member ?
Or in other words - that turn counter looks if a value increased or decreased.
that can be followed if values move in expected direction,
but NOT if that happens because you rotate the list.
Can you explain to me how should that work ?
I think I have a solution for you.
1 no switch but Dial that sets rotation 0(off) - 9.
Because rotation 10 is same as 0 or none, why switch ?
Don't rotate in between, but at the end.
rotate both dials AND turn counter.
I understood your change with rotStep sets between 0 and 9.
But for the moment, If you test the patch in CWW mode and you trig the rotation function, you will see that all turn counters work well.
If you stop the rotation function, and you change rotStep in both way from 9 -> 0 or 0 -> 9 all turn counters work well.
The problem is in CW. If you trig the rotation function, you will see that all turn counters work bad.
Turn counters have worked bad since I use [pack], [zl.rot] and [unpack]. I didn't have this problem before.
Also If you stop rotation, and you change rotStep from 9 -> 0 all turn counters work bad.
I have added rotation at the very end of output, both dials and turn counter.
Which means - they run exactly the same as before,
only output gets rotated.
If you are not happy with it, then it was not working well before rotation got added.
Ot you did not copy stuff correctly from the screenshot.
which uses pak and NOT pack.
Another thing you could change is align function.
If you understand that in both modes CW or CCW turns counter detects
when value increased or decreased.
if CW and value decreased - it counts up.
if CCW and value increased - it counts up.
if some dials are less than 16 and other more than 16 when you align them
then they will increase or decrease, turns counter will give you wrong
results.
here is modified patch.
rotation for dials and turns counter is independent.
there is red patchcord in both subpatches which retriggers the list
when rotation dial changes. It rotates even if no changes are coming in.
disable or remove it if you don't want that.
Align button first disables turns counter, then alignes the dials
and after 10ms enables turns counter again.
that avoids wrong counts.
Hello.
Thanks a lot for cleaning and simplifying my patch. !!
I understand where the problem comes from.
If you trigger the rotation with the textButon ON_R with CW mode, you will see that the turn counters add 1 to each new position while they should add one only after 1 turn.
With CWW mode, there is no problem.
So I tested to change the way of the sign > into < for the first live dial.
Now the first turn counter adds 1 only when the live dial makes a turn.
So I think I need to change the sign depending on whether CW or CWW mode is triggered.
But I don't know how to do that. Also, I don't need to rotate the turn counter value. That's why I removed it.
if you don't rotate turn counter then it shows wrong count.
CW and CCW switch inc / dec.
for that reason > should need no change
I am talking only about rotating list:
that new green stuff.
The rest is unchanged
If it worked ok for you then
there is nothing to fix
Here is turn counter fix CW/CCW.
problem was pak f f f f f f f f ... in all-control patcher.
I inserted change 0. in several places to prevent repeated values from being sent out.