Basic signal routing

jorge ruiz's icon

Hi! I can't seem to figure out how does this patch works vis-a-vis the routing of the signal. I think the left select should only receive a "0". Also the prints goes first b then a and then c, which to me doesn't make any sense. Thanks!

Max Patch
Copy patch and select New From Clipboard in Max.

Jean-Francois Charles's icon

The example is actually interesting when it comes to the feedback loop and the 1. What happens is the following:
- when you press the [toggle], it will output on 2 cables, so whatever happens, it will output a one on the rightmost cable (or the rightmost output if you used a [trigger i i] object). Then it will output a one on the leftmost cable.
- since Max processes messages in depth before moving on to the next cable, it the [toggle] may output a 0 in depth before outputting a 1 due to an earlier command. That's really an interesting example.
For instance, compare the prints d and e in this patch...

Max Patch
Copy patch and select New From Clipboard in Max.


You'll understand why b prints before a when you think about the left to right order and the depth first processing.

Roman Thilenius's icon


for me it is totally clear that and why it doesnt.

however, i fail to properly explain it off the cuff.

i can only offer a cross check: if the loopback would do what he thinks, then messages from elsewhere could also stop objects from outputting what they have been told to.

and as one often can see, the graphics thread is yet another question.

jorge ruiz's icon

Ok thanks guys, now i understand! Before, i put the print "a" left from the message 0, so that's why i got confused. Basically it finishes all the processing from the rightmost cable (which ends at the "sel 1" in the second lap) and then sends the 1 in the leftmost.

Roman Thilenius's icon


would still be great if somebody could shed some light on the technical aspects.

like jfc says, triggering the toggle first induces the stuff at the leftmost output cable, with the other outputs already in queue. first "1" running, the next "1" already waiting.

because the messages are successive messages (like sending "1, 1" between objects), nothing can squeeze in between messages of this queue.

but why is task A not any longer dominant to task B when it comes back into the object? why does it end here? because objects are deliberatly designed like that, or is the runtime responsible for that?


broc's icon

It's also explained in this article
https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue
Quote:
"The way in which these messages traverse the patcher network is depth first, meaning that a path in the network is always followed to its terminal node before messages will be sent down adjacent paths."

Roman Thilenius's icon


yeah, but why is the first external the last node in case you loop the message path back.

for example if it was an abstraction it is not like that. :)