dnk777

I encountered a problem while patching and even if I already found a solution, I don't understand what the problem is and why that solution helps.

Imagine you have 4 numberboxes in abstraction (multiple instances of it) and when you change either numberbox, you want the whole set of numbers from the current instance of abstraction, to be set in all other instances.

So, I connected the 4 numberboxes to [pak i i i i] -> [send xxx]

[receive xxx] -> [unpack i i i i] ->into four "set $1" messageboxes, leading to both, the numberboxes and the [pak i i i i] inputs so that it will only set the numbers and don't feed it back again into stack overflow).

But when changing the values, sometimes (almost always) when you go to another numberbox and change it, the one you last changed before will kind of "reset" itself to some value of some other numberbox (no idea how could another numberbox get the number. they doesn't seem to be interconnected at all)

I tried it also with [bondo 4] -> [pack i i i i ] instead of back (set message going into bondo) with same results.

Then after hours of trying to "debug" it (in my patch, it was more complex and 16 numberboxes instead of 4, so it was messy and I thought I just made some mistake when connecting so many wires), I don't know why, but I tried putting [deferlow] object before the send, and it seems to work OK since then, but I'm still unhappy, because I would like to know why it doesn't work without the [deferlow] and why it does help when i put it there.

I even tried going through it in debugging mode step by step, but it did not help me understand.

please, could somebody explain it? below is the patch.

three versions. left one is using pak, middle one is using bondo+pack+deferlow (works ok) and right on is bondo+pack. try changing the numberboxes in the left and right versions and watch the last changed number box when you change the next one. can you explain that, please?

So, I connected the 4 numberboxes to [pak i i i i] -> [send xxx]
[receive xxx] -> [unpack i i i i] ->into four "set $1" messageboxes, leading to both, the numberboxes and the [pak i i i i] inputs so that it will only set the numbers and don't feed it back again into stack overflow).

Then after hours of trying to "debug" it (in my patch, it was more complex and 16 numberboxes instead of 4, so it was messy and I thought I just made some mistake when connecting so many wires), I don't know why, but I tried putting [deferlow] object before the send, and it seems to work OK since then, but I'm still unhappy, because I would like to know why it doesn't work without the [deferlow] and why it does help when i put it there.
I even tried going through it in debugging mode step by step, but it did not help me understand.

please, could somebody explain it? below is the patch.
three versions. left one is using pak, middle one is using bondo+pack+deferlow (works ok) and right on is bondo+pack. try changing the numberboxes in the left and right versions and watch the last changed number box when you change the next one. can you explain that, please?

strange-bondopak-behaviour-patch-included

In feedback loops [deferlow] is usually required to "encapsulate" the message flow, ie. to ensure that an event is finished before it can be triggered again.

See also this thread for related discussion.

https://cycling74.com/forums/odd-zl-queue-behavior-potential-bug

broc: Yes, I always use defer in feedback loops, but this is no feedback loop at all (the thread you pointed to seems to be also about feedback loops, which my patch isn't). The wires are in a loop , but no feedback, while the data flow is always finished after one single loop, when it gets to the "set $1" commands, setting values in numberboxes and pak (or bondo) WITHOUT having them output any messages further into second loop (there is no second loop here).

There is no doubt, that the event can be finished, without retriggering itself, while the "set n" messages does not trigger the object.

+ I'm also interested in understanding, how can values in the patch get from one numberbox to another (when the glitches occur). I cannot imagime it, looking at the dataflow.

I would really just like to understand, what is really happening, when I don't put the deferlow object.

broc: Yes, I always use defer in feedback loops, but this is no feedback loop at all (the thread you pointed to seems to be also about feedback loops, which my patch isn't). The wires are in a loop , but no feedback, while the data flow is always finished after one single loop, when it gets to the "set $1" commands, setting values in numberboxes and pak (or bondo) WITHOUT having them output any messages further into second loop (there is no second loop here).
There is no doubt, that the event can be finished, without retriggering itself, while the "set n" messages does not trigger the object.

objects like [v], [coll], [table] or [pp] can be quite helpful to synchronize multiple instances of the same abstraction without all that s/r and "set" chaos.

Roman: Thanks, I know [value] and [table] and will take a look at the [coll] ([pp] not recognized by my max), but i am not sure if that is useful for my purpose as I don't want to have them synchronized all the time. In my patch this is meant only as a "set to all instances" function, which you may want to check while doing initial setup and then uncheck and adjust things in each abstraction separately.

What I'm really interested in, is understanding what's really happening without the [deferlow] + why it does not work wihtout it (it still seems to me it just should) + how can one numberbox obtain value of another if they are not interconnected. Seems and feels paranormal to me.

So it looks like [pak] is the culprit here. Using [pack] instead seems to work.

if it works without defer using bang+pack, then why not with bondo+pack?

maybe somebody from cycling74 can help us understand?

broc: interesting.
if it works without defer using bang+pack, then why not with bondo+pack?
maybe somebody from cycling74 can help us understand?


nicolas: I use max6, so it is not solved yet. really seems like a bug of [pak] and also of [bondo] (if you replace the pak in your patch with [bondo 4] and connect it to [pack i i i i] it behaves the same way.

Here's a behind the scenes commentary courtesy of Mr J. K. Clayton.

In Max, many objects that accept multiple value types in right hand inlets use a mechanism we call "proxies". They are called this because we create an internal object for each inlet which acts as a proxy for calling into the object. Essentially, it enables the code to know which inlet is being called at any given moment from the incoming message. The left most inlet is different and never has a proxy associated with it.

This implementation suffers from a technical limitation:

If you have a feedback loop (aka recursion) in your patch, there can be confusion in an object as to which inlet is receiving which message. This is particularly the case when the feedback is sending a value through the leftmost inlet and feeds back into another inlet as a result of the message (or vice versa). This is because the proxies are recording the inlet and the leftmost inlet is not. The solution to this problem is to use deferlow, delay, or some other scheduling mechanism to break the recursive nature of the loop within the processing of the initial event. Or try to figure out a way to perform your operation without strict feedback.

At this point it would be tricky to solve this implementation issue without introducing global performance overhead, while remaining compatible with existing objects. At some point in a future version of Max, we hope to solve this issue in an appropriate way. For the time being, however, hopefully this explains some of the mystery "under the hood", and allows you to patch accordingly to work around this limitation.

Thanks Andrew. Good to be aware of this.


strange bondo/pak behaviour (patch included)