[unpack] followed by [pack] going out of Sync?
Hi, long-time coder, first-time Max-er. :)
I have attached a simple Project in which I am trying to do an [unpack] of a 3-part Message, followed by a [pack] of the same data, in order to swap the order of two arguments in the Message. (This is so that the Message format interfaces easily with a [routeswap].)
The input data is simple MIDI notes. The data retains integrity after the [unpack], but when the data is rearranged and re-[pack]-ed, the Note Number from the Prior MIDI note sent is "lagging behind" and finding its way into the Note On part of the next MIDI note sent.
(It looks like [zl.swap] may allow me to sidestep my "[unpack], swap, [pack]" method, but since this is such a fundamental behaviour that's strange to me, I'd like to understand why this is happening.)
Thanks! File and Image are attached. rs
Hi Ryan, welcome to the forum.
The "lag" you mention is due to the way (most) Max objects work: data is output from the different outlets from right to left. So, out of the unpack, the number on the right is output first, then middle, then left.
Now, with [pack], you trigger an output with the leftmost inlet ("hot" inlet), so in your case, you are triggering the pack output before the number from the left outlet of the unpack has gone out.
One way to do what you want to achieve is like this:
Make sure you study what the [t] (or [trigger]) object does.
One more thing: when you post such questions to the forum, select the piece of code in Max, then go to the Edit menu, and choose Copy Compressed. Paste in your post in the forum. That's the easiest/fastest way to exchange code snippets here.
Thanks for the helpful advice about attaching Files! And I'll review the [trigger].
rs
Max has a right-to-left input and output order. Most objects only provide output if the first (left) input gets data. Similar, data output begins at the rightmost output and ends at the first output. You can rely on this order.
In your patch you connected the 2nd output of [unpack] to the first input of [pack]. This way [pack] does immediately output if the 2nd [unpack] output sends data. The 1st output of [unpack] comes too late. You get it always an attempt later.
There are several methods to rearrange the in/output order. In the screenshot below you see three of them.
Consult the help files of the objects and/or the reference pages to learn what they do.
A note:
Since we deal with graphical programming, the right-to-left thing also happens if you distribute one output to more inputs or objects. If the order of data is important, don't just put objects somewhere on the screen. Use the [trigger] object which can also be written as [t]. A trigger can have many outputs of similar or mixed types and you always know the order. From right to left.
Thanks again for all these possibilities! Knowing about the "right-left" thing and the "hot inlet" rules are helping me to understand why things that looked "synchronous" to me, coming from the perspective of text-based programming languages, would not be in this case.
Of the examples you mentioned, I had seen info about [zl] and [swap]. The [buddy] is actually the one that seems most intuitive to me, as I said, coming from languages that are written line-by-line and evaluated top-to-bottom.
I have Favorited this thread while I am learning. Thanks again! rs