Togedge strangeness
I have an input that is either 0 or 1 and wanted to get a bang if the input is 1, and nothing if the input is 0. For some reason (such as being quite new to Max) I had temporarily forgotten about ‘select’ and tried building something with togedge, that detects 0->1 transition and immediately sets the input back to 0 if this transition is detected. For some reason this doesn’t work as expected (Win 7, Max 5.1.9), as only explicit 0->1 transitions are detected. Please see included patch, where I would expect the left and right sides to behave identically. Is this a bug or is it a chance for me to learn something new about Max? ;-)
It’s a chance to learn something about the subtlety of feedback loops.
Thanks, broc. I wasn’t expecting the delay to be necessary, as there is never any risk of infinite feedback in my original construction. So I’m still kind of curious as to the reason why it didn’t work in the first place.
I think the delay is needed here to ensure that the output of togedge is completed before being retriggered.
See also this thread for related discussion.
Thanks. That thread included some information on how to solve the problem, but not on why it’s a problem in the first place. The article that’s linked to only talks about stack problems from infinite recursion, which is not the case here. I guess I was looking for something along the lines of (like you suggest) "When using event feedback, any input these objects (togedge… ) that indirectly comes from its output will be ignored. The reason for this implementation is…"
[if $i1==1 then bang] is yet another solution you had not asked for.
[delay] … brings up data to a higher priority thread.
well if you put a deferlow object between the output and the reset of togedge, it fixes your ‘problem’; I guess this indicates that togedge is an object that ‘expects’ low-priority messages– if that makes sense… not sure if it does… might be a bug. It certainly shouldn’t behave that way anyway