[PD] Patch acting weird with Pd 0.46.6

[Jonathan Wilkes]

On 06/04/2015 02:11 AM, Chris McCormick wrote:
> On 04/06/15 06:03, Jonathan Wilkes via Pd-list wrote:
>> (And fanouts are more obvious than [trigger] objects wired in the
> wrong order, and especially where recursion is involved.)
>
> I am confused by this assertion. Can you explain like I am five?

An Argument Against Dogmatic Triggers

My toolkit:
* fanouts mean I think the order doesn't matter (or else it's a bug)
* triggers mean the order I chose is necessary for the program to work 
properly

Your (proposed) toolkit:
* no fanouts
* trigger either means the order you choose is necessary, _or_ the order 
doesn't
matter but you forced yourself to use trigger anyway

>
> Probably my failing but I am unable to imagine a situation in which
> "fanouts are more obvious than [trigger]"

If I run into a bug that looks like I screwed up the order of
operations, I can start with the fanouts and try to violate my own
fanout premise.  If I find a part of the patch where order of fanout wires
indeed does matter, I instantly know it is the bug and can immediately
fix it.

If you run into a bug that looks like you screwed up the order of
operations, you can't immediately tell the difference between the
triggers that are required to run the patch properly, and the ones
that you used merely because you want to avoid the danger of
using fanouts (i.e., dogmatic triggers).

Now, you might say that dogmatic use of [trigger] actually forces
you to consider the order of operations in a way that my fanouts do
not.  And that may be true.  But inevitably you will end up with
a few parts of your patch where you _think_ order doesn't matter.
If you use [trigger] in those cases anyway (and choose some
arbitrary ordering), you remove the visual evidence that you thought
the connection order could be unspecified.  If it turns out you indeed
chose the wrong order for your trigger, you make it harder to track
down that mistake because you cannot tell the difference between
your dogmatic triggers and the normal triggers.

>   and I don't understand the
> qualifier "especially where recursion is involved".

If I have a choice to debug a recursive (control) object chain using
my toolkit vs. your toolkit, I'll choose mine.  Because I know to start
with the fanouts, and then move to the triggers if I still haven't found
the bug.  With yours I can't do that because I don't have any visual
information about where in the object chain you may have assumed that
the ordering of some operations wouldn't affect the function of the patch.

That may sound crazy, except that a) recursion is _really_ awkward and
difficult to reason about in Pd and b) Pd _lets_ you make fanouts. If the
UI didn't allow fanouts maybe it's a different story.  But there are just
so many examples in the wild that use fanouts, even fundamental idioms
like [f]x[+ 1].  Scripture-style quotations or no, there's just no going 
back
at this point.

So to me, it's more instructive to try to consider which parts of a patch
require ordering, which don't, show that in the patch, and think critically
about all the above.

>   How do you define
> "obvious" as used here?

For example, looking at a patch... *2 seconds of eyeballs doing their 
thing*... oh, there is the fanout.

vs...

Oh, _everything's_ a trigger.  Thinking... *2-2000 seconds of 
thought*... oh, there is the dogmatic trigger.

There are of course other types of bugs, but that's the comparison for
wire-ordering bugs.

>
> Last night I spent several hours tracking down a bug that turned out to
> be because I had used a fan-out instead of a trigger. I am not 100% sure
> if this backs up your point or refutes it but either way it sucked. :)
>
> I think I will continue to try and make myself use trigger objects
> instead of fan-outs to avoid that type of bug again.

I think the more you consider the consequence of how things are
ordered in Pd, the easier it will be to track down bugs.

You might still achieve that by dogmatic use of trigger.  But I think
it's counter-productive to make proclamations against
a feature that the UI allows, _and_ that everyone including the original
author uses in every non-trivial patch.

-Jonathan

>
> Cheers,
>
> Chris.
>