strange bondo/pak behaviour (patch included)
|
Jun 17, 2012 at 4:41am
strange bondo/pak behaviour (patch included)hello, 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] 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. please, could somebody explain it? below is the patch. thanks daniel – Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
|
|
|
Jun 17, 2012 at 9:44am
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. |
|
|
Jun 17, 2012 at 2:43pm
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). + 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. thanks, |
|
|
Jun 17, 2012 at 3:34pm
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. -110 |
|
|
Jun 17, 2012 at 4:59pm
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. |
|
|
Jun 17, 2012 at 5:33pm
Hello, even if i do not know _exactly_ what’s happened, IMHO it looks like a low/high thread concurrency problem ; kinda stuff very good for headache … but why do you use set $1 message to [pak] ? The patch below not do the job ? – Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
EDIT : – Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
|
|
|
Jun 17, 2012 at 5:59pm
oops … sorry, NO, it doesn’t do the job … OK i see now what’s your problem ;-) |
|
|
Jun 17, 2012 at 6:56pm
So it looks like [pak] is the culprit here. Using [pack] instead seems to work. – Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
|
|
|
Jun 18, 2012 at 2:01am
broc: interesting. |
|
|
Jun 18, 2012 at 5:17am
Hello, yep ; problem is the “set” message to [pak] ; – Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
with a [deferlow] before it seems to work fine : – Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
|
|
|
Jun 19, 2012 at 2:46am
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. |
|
|
Jun 20, 2012 at 12:04am
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. |
|
|
Jun 23, 2012 at 3:09am
Thanks Andrew. Good to be aware of this. |
You must be logged in to reply to this topic.