keep max data in sync
Hello list,
i'm doing a max for live object, where the length of the note would be different depending on its height.
To keep the datas synchronized, I use a little "pipe 1" to give the patch enough time to find the good lenght value before sending the note.
i'm maxing for a long time and i'm often facing this kind of problem, and I always use this system of pipe but i'm pretty sure there is a better proper solution.
Someone could tell how I should proceed ?
Thanks a lot for your help and best,
M
Trigger!
(and some more characters)
yes for sure ! thanks !
but if i'm doing more than one operation after the multislider - because here it is just a scaling operation but we could imagine, i have some others objects after - how to be sure to be always in sync ?
"but we could imagine, i have some others objects after - how to be sure to be always in sync ?"
No, not really though? The trigger object and the way Max handles messages through the order of operation make sure that it will always execute the rightmost chain of events first.
ok, I knew the right/left priority rules but I didn't know high/low orders have any influences.
So thanks for the information, it seems clearer !
best,
M
Yeah, hold up. I overlooked the multislider so you're indeed mixing high/low priority objects with eachother. I would like to know though if trigger would "overrule" that or if this is a case where you would use [defer]? (to be honest i'm not to keen on the details regarding high/low priority objects, i just stay away from UI lol)
Anway i would opt for this. I think? everything is in the same priority queue now (please correct me if i'm wrong here!)
just few remarks:
fetch message to multislider starts from index 1,
zl.lookup is zero based.
one would have to use -36 for it.
then - is it faster to fetch or to zl.lookup ?
makes no real difference, speed test shows that order of output depends
on position order.
means there is no benfit from adding zl.lookup
-----
this should be efficient enough, and preserving velocity if needed.
Would split note range not be better instead of clip ?
----------
in some cases it helps to use join with trigger set
to fire on slowest expected list member
"means there is no benfit from adding zl.lookup"
But isn't it so that because multislider is a UI-object you potentially introduce problems with message-routing because UI lives in a different priorityqueue? And by hooking it up to the cold inlet of zl.lookup you eliminate that?
And yeah, i know about lookup requiring a 0 i was just being just lazy :)
in this case multislider does not affect anything directly
only when note triggers it's set value.
and it was set to ouput only on mouse release...
means if one is just mousing, fetch message will pick current drawn value,
zl.lokup will use old one till mouse gets released.
but one can do it so or so.
Maybe it matters in Live with it's timing troubles ?
In max it makes no difference at all
thanks a lot for all your thinkings !
but more generally, how I could be sure all my right-operations are done before all left upcoming value ?
I'm trying sometimes to use the buddy object but i'm not sure it is exactly the way to process.
thanks and best,
M
trigger is a good start point, but sometimes also
join with set trigger inlet.
for example if you have 3 values and you suspect 2nd could come late
only trouble is when 1 list member is too slow and
changes in other ones lead to missed values...
No matter what timing approach one takes.
thanks a lot for your help !
"but more generally, how I could be sure all my right-operations are done before all left upcoming value ?"
if their origin is the same (and if there is no [deferlow] somewhere in the algorithm) it is guaranteed. that is what the law of right-to-left orer is about.
if the origin if not identical, the right-to-left you thought you patched is purely a (psychological) construct.
that can then, like you already found out, only be "fixed" using buddy/bondo/thresh, or like in the example of source audio.
or you could quantize the the two data streams into a time grid...
I'm trying to look the article where i picked up on the nuances when using UI. I think/thought it was in the form of a demystifying article by Cycling74? This must've been around the time of Max6 give or take.
*thought because i skimmed through all of them