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

[Jonathan Wilkes]

Actually even for one's own patches, Pd is supposed to go into read-only mode when you depend on creation order for deterministic behavior.  That is-- it shouldn't let you save the patch after that.  But there's a long-standing unfixable bug that lets you do it anyway.
I make this joke with some sadness because data structure drawing commands depend on creation order for the drawings' z-order.  And I can't think of a better way to do it.  (One could use wires to chain them in order but that brings its own problems.)

-Jonathan 


     On Saturday, September 12, 2015 1:03 AM, Matt Barber <brbrofsvl at gmail.com> wrote:
   

 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




_______________________________________________
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/a0f252f5/attachment.html>