<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Alexandre,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Looking at your original question, G05.execution.order says the following:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">"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."</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">As the others have pointed out, there are basically two ways of "getting the write sorted before the read [in the DSP chain]":</div><div class="gmail_default" style="font-family:verdana,sans-serif">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).</div><div class="gmail_default" style="font-family:verdana,sans-serif">2) on purpose, using subpatches, which is guaranteed both to work and to be inferred from the structure of the patch.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">====================================================</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">If you look at the first test patch you attached, you can tell a few things about execution precedence based on patch cords.</div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">There are some cases when you actually need a block delay, and you can specify that behavior in the same way.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Matt</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 25, 2015 at 7:17 PM, Alexandre Torres Porres <span dir="ltr"><<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Well, even though the example works as described, I was doing some tests and didn't get the same results. </div><div><br></div><div>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.</div><div><br></div><div>See my patch attached.</div><div><br></div><div>So what now, huh?</div><div><br></div><div>cheers</div></div>
<br>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div></div>