On 06/03/2015 05:03 PM, IOhannes m zmölnig wrote:
On 06/03/2015 09:40 PM, Pierre Massat wrote:
Thank you both very much for the explanations. So if I got it right, the loop in itself was behaving as expected, but what was being printed in the console was not reflecting that. Instead print behaved like a list prepend. That's good to know, I candidly thought that print objects were printing out stuff in real time irrespective of what was going on in the rest of the patch.
no. everything was behaving as expected, and [print] was printing in "real time" (whatever that means).
but time in Pd is a fickle thing, and while things can happen in zero-time they also happen one after the other. [print] immediately prints any data it receives, but your patch was made in a way that would send the "last" message to [print] before it would send the "first" message. hence the reversion.
to re-iterate: [trigger] would have made this more obvious.
But the author of the patch was under the impression that the firing order didn't matter. In cases like this [trigger] won't help-- the user would still have the same 50% chance of making the connections in the wrong order.
If you meant that it would have made the error more obvious to *you*, well... it's hard to beat the speed of proclaiming a rule without even looking at the patch. If the author had slavishly employed [trigger] in place of fan-outs with the same bad luck as their fanout ordering, then your proclamation wouldn't have applied in this case. (And fanouts are more obvious than [trigger] objects wired in the wrong order, and especially where recursion is involved.)
So I'd say use fanouts where ordering doesn't matter, but keep an eye on them and make sure they _still_ don't matter when you need to debug.
Otherwise you'd end up mindlessly inserting/removing a bunch of [trigger] objects just for debugging stumps (like [print] and number box). With GUI software like Pd Vanilla that doesn't have infinite undo your hand will get tired and you'll have to rest. That probably eats at least much time as you'd save avoiding potential fanout bugs.
-Jonathan
gfmsd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list