ninjatueur

I'm a new user of Max4L, so my question might appear easy for a lot of you... sorry 'bout that

I'm trying to collect midi (CC number and it's CC value) in M4L, process them, and transmit them to another part of the patch.

Problem is I'm doing little more process on the CC number than on it's CC value, so when it's been sent it is not synchronized anymore (probably due to the process's time, CC values transmit faster than CC numbers), I get "bad" couples of CC number and CC values.

So the easy question (I guess) is : how to do it "by step", I mean first I get the couple of CC number/value, then process, then transmit, THEN get another couple and restart the process...

Hi
I'm a new user of Max4L, so my question might appear easy for a lot of you... sorry 'bout that
I'm trying to collect midi (CC number and it's CC value) in M4L, process them, and transmit them to another part of the patch.
Problem is I'm doing little more process on the CC number than on it's CC value, so when it's been sent it is not synchronized anymore (probably due to the process's time, CC values transmit faster than CC numbers), I get "bad" couples of CC number and CC values.
So the easy question (I guess) is : how to do it "by step", I mean first I get the couple of CC number/value, then process, then transmit, THEN get another couple and restart the process...
thanks a lot !!
Fred


wait-for-a-bang-before-transmitting-data

Sounds like you need to learn about the triggering properties of pack, but more importantly, the [trigger] or [t] object, which helps tremendously in ordering events.

Your timing problems are *not* a function of one event taking longer than the other, it's because of your ordering, I can almost guarantee it.

Post the relevant part of your patch, if in doubt; remember to use Copy Compressed to post it here.

Sounds like you need to learn about the triggering properties of pack, but more importantly, the [trigger] or [t] object, which helps tremendously in ordering events.  

Your timing problems are *not* a function of one event taking longer than the other, it's because of your ordering, I can almost guarantee it. 

...I already guessed that I missed some use of the triggering operations, but I didn't know that processing time could not be a problem in synchronizing.

I'll come back here if I still can't manage to solve my problem, but I want to search on my own first, it's the best way to learn !

ok
...I already guessed that I missed some use of the triggering operations, but I didn't know that processing time could not be a problem in synchronizing.
Thanks a lot, I'll go working with that.
I'll come back here if I still can't manage to solve my problem, but I want to search on my own first, it's the best way to learn !
thanks again :)
Fred


As Wetterburg said, Trigger is probably one of the most important objects in the Max environment. Try getting a global metro to trigger from the start of the live transport and choose timings which are similar to 4n or 16n instead of milliseconds. That way the triggering process will always be in sync with your live set regardless of bpm changes.

Also check out [zl reg] for storing data that can be banged out later. Coupled with [trigger]... no can defend.

Also check out [zl reg] for storing data that can be banged out later.  Coupled with [trigger]...  no can defend.


 is less often the problem, more often the problem is a solid understanding of the order messages are handled.

Max looks like it's processing lots of messages in parallel. The fact is that messages are handled serially, one after another. (It used to be easier to explain this when computers only had one processor, but even on modern multi-processors, the main Max thread that's handling message passing is running on a single processor; it's other things, like audio processing and Jitter matrix manipulation that can get farmed out across multiple processors).

The order Max processes messages is well defined and thoroughly documented. The right-to-left thing often seems counter-intuitive to novices, but it's actually a brilliant way to simulate (conceptual) parallel processing on a (real) serial machine. And it does what even novices expect most of the time. But when it doesn't do what you expect, two choices: either come seriously to terms with right-to-left order, or use a lot of [trigger] to make order explicit.

The third choice is to do both, which is the best thing in the long term.

Processing time per se is less often the problem, more often the problem is a solid understanding of the order messages are handled.

The third choice is to do both, which is the best thing in the long term.


I think with the LOM, the right to left format can go slightly out the window. I have found that live.path and uzis don't play the nicest. If one is trying to construct a list comprised of a number label and the id of a live parameter, the uzi may outpace live.path under the right circumstances.

as Peter mentioned, even though Max may appear to be doing things simultaneously to the untrained eye, in reality, it is doing things sequentially. This can have adverse effects with events that manifest themselves a midst a process, and this is the reason one must place a deferlow object after live.observer if said event is to trigger other live.something events. with this same concept in mind, one may need a deferlow in other places.

I'm certain in 99% of cases, a timing issue is simply a misunderstanding in Max syntax, but in case this is the one in 100 cases where the syntax is completely correct, trigger objects were used to maintain order, and zl regs, int/floats, or message boxes were used to store values temporarily to allow a subsequent event to trigger the data, then it's valid to explore other options.

I think with the LOM, the right to left format can go slightly out the window.  I have found that live.path and uzis don't play the nicest.  If one is trying to construct a list comprised of a number label and the id of a live parameter, the uzi may outpace live.path under the right circumstances.

as Peter mentioned, even though Max may appear to be doing things simultaneously to the untrained eye, in reality, it is doing things sequentially.  This can have adverse effects with events that manifest themselves a midst a process, and this is the reason one must place a deferlow object after live.observer if said event is to trigger other live.something events.  with this same concept in mind, one may need a deferlow in other places.

I'm certain in 99% of cases, a timing issue is simply a misunderstanding in Max syntax, but in case this is the one in 100 cases where the syntax is completely correct, trigger objects were used to maintain order, and zl regs, int/floats, or message boxes were used to store values temporarily to allow a subsequent event to trigger the data, then it's valid to explore other options.


thanks you all for your help, you were right as expected the problem was first the triggering order...

...AND the fact that I used a zl.stream to collect to data and transmit them, but I did not send the "zlclear" msg to re-init before every collecting, so when the new list of data (a 10 list) was comming in zl.stream, this one emited 10 times, with only one time in proper order...

I told you I'm a newb, got to get used to all the subtilities of all objects... but I'm glad I can find valuable help on this forum !

Hi guys
thanks you all for your help, you were right as expected the problem was first the triggering order...
...AND the fact that I used a zl.stream to collect to data and transmit them, but I did not send the "zlclear" msg to re-init before every collecting, so when the new list of data (a 10 list) was comming in zl.stream, this one emited 10 times, with only one time in proper order...
I told you I'm a newb, got to get used to all the subtilities of all objects... but I'm glad I can find valuable help on this forum !

wait for a bang before transmitting data