[PD] "G05.execution.order" issue (bug? just wrong?)

[Matt Barber]

Alexandre,

Looking at your original question, G05.execution.order says the following:

"If you're writing to and reading from a delay line, you have to get the
write sorted before the read or else you'll never get less than a block's
delay."

As the others have pointed out, there are basically two ways of "getting
the write sorted before the read [in the DSP chain]":
1) by accident, or in a way that can't be gleaned from looking at the patch
in Pd (you'd have to take it into a text editor to see that the write was
created before the read).
2) on purpose, using subpatches, which is guaranteed both to work and to be
inferred from the structure of the patch.

So it's not that the idiom on the left will ALWAYS be off by a block in
every instance, but that it may or may not be depending on the unreadable
contingencies of how the patch was created. You can rely on this for your
own stuff, but if you wanted to send it to someone, they wouldn't be able
to tell those contingencies by looking at the patch, so to that user, the
behavior is "undefined" in the same way that failing to use a trigger makes
message execution order "undefined." The behavior is deterministic under
the hood, but your user can't be expected to look under the hood. The
G05.execution.order is specifically tailored to show that it can be off by
a block, but there's no way to know it just by looking; it's possible a
better approach would have been to have shown another one that looked
exactly the same but had the other behavior, and then finally the way to
make it explicit using subpatches.

====================================================

If you look at the first test patch you attached, you can tell a few things
about execution precedence based on patch cords.
1) [noise~] runs before [delwrite~], [pd delay-writer], [pd delay-reader],
both [+~] objects, and the [output~] abstractions, because for each of
those the [noise~] feeds into it or feeds into something that feeds into it.

2) [noise~] may or may not run before [vd~], and likewise [delwrite~] may
run before or after [vd~]. If [delwrite~] runs after [vd~] (because it
happened to have been created after), then setting [vd~]'s delay to 0 has
it reading what [delwrite~] wrote on the previous block.

3) [pd delay-writer] is guaranteed to run before [pd delay-reader] because
of the patch connection between them. If you severed that connection, and
then cut and pasted [pd delay-reader], it would now run before [pd
delay-writer], until you reconnected the cord. You can try this and hear it
change when you reconnect and disconnect the connection.


There are some cases when you actually need a block delay, and you can
specify that behavior in the same way.

Yes, send~/receive~ and throw~/catch~ can be off by a block as well, but
you can force them to run in sync, again using subpatches (unless it
creates a DSP loop).

Matt




On Tue, Aug 25, 2015 at 7:17 PM, Alexandre Torres Porres <porres at gmail.com>
wrote:

> Howdy, the "G05.execution.order" example in Pd shows us how delay lines
> will always delay at least a block of samples, unless you tweak it by using
> some subpatches and stuff.
>
> Well, even though the example works as described, I was doing some tests
> and didn't get the same results.
>
> So it is weird that behaves like that in the example, but when I change
> the patch or make a new patch it just doesn't behave the same way. Meaning
> that it will not delay to at least a block in size, but less than that
> without doing the subpatches thing.
>
> See my patch attached.
>
> So what now, huh?
>
> cheers
>
> _______________________________________________
> 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/20150912/db0f97a3/attachment.html>