[PD] Patch acting weird with Pd 0.46.6

[Jonathan Wilkes]

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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150603/1f9fe966/attachment-0001.html>