<div dir="ltr">here Raphael, using [switch~]. you can do what you originally asked for.  An [env~] object is put inside a subpatch, and that subpatch is explicitly forced to compute one block by banging the [switch~] object.<div><br></div><div>you can see in this example that you can change the order of execution by sending your original control bangs in different order. </div><div><br></div><div><br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 18, 2014 at 6:53 AM, Jonathan Wilkes via Pd-list <span dir="ltr"><<a href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><span>Hi Raphaël,</span></div><div><span><br></span></div><div dir="ltr"><span>The problem is not very intuitive to solve.</span></div><div dir="ltr"><span><br></span></div><div dir="ltr"><span>It's difficult enough to understand the flow in a patch that only uses signal objects.  And i</span>t's more difficult to understand the flow in a patch that uses control objects.  That's because you can no longer just assume that each object will compute its inputs before sending output-- you must instead read all the right-to-left triggering to know where the data will go.  (Plus you must understanding what triggers the object chain traversal in the first place.)</div><div dir="ltr"><span><br></span></div><div dir="ltr"><span>But it's even more difficult to understand a patch that mixes the two. And on top of _that_ you have a [delay] in the object chain, which has its own timing outside of the normal firing of control events.  That normal firing of events in a chain of control objects happens in zero logical time.  Oh, and the value you're providing for your delay time is zero.</span></div><div dir="ltr"><span><br></span></div><div dir="ltr"><span>That isn't trivial to understand, much less come up with as a solution in the situation of [env~].</span></div><div dir="ltr"><span><br></span></div><div dir="ltr">One way to approach this is to think what happens to the following patch if you turned on audio for a single block and then turn it off again:</div><div dir="ltr">[env~]</div><div dir="ltr">|</div><div dir="ltr">[bang]</div><div dir="ltr">|</div><div dir="ltr">[delay 1000]</div><div dir="ltr">|</div><div dir="ltr">[print delayed]</div><div dir="ltr"><br></div><div dir="ltr">[env~]</div><div dir="ltr">|</div><div dir="ltr">[bang]</div><div dir="ltr">|</div><div dir="ltr">[print normal]</div><div dir="ltr"><br></div><div dir="ltr">The [print normal] object will obviously print before the delayed one, right?  It does, but let's look at a part of how Pd schedules this stuff.  It's something like this:</div><div dir="ltr">* fire the messages from each [env~], based on the order in which were created.  Let's assume the first one you created is the one connected to the [delay 1000].  Here's what happens:</div><div dir="ltr">1) message goes from [env~] to [bang] to [delay 1000]. The [delay 1000] schedules a bang to output 1000ms later.  This next part is the key: Pd will _not_ check to see whether 1000ms has passed until it has processed step #2 below.  Also important is that Pd will _immediately_ proceed to step #2 below-- it doesn't wait 1000ms before doing so.  You probably already knew that part, but many programming languages do in fact have mechanisms which let you just sit there waiting before computing the next logical part of the program.</div><div dir="ltr">2) message goes from [env~] to [bang] to [print normal].  We get an immediate printout to the console.</div><div dir="ltr">3) 1000ms passes, and [delay 1000] finally sends to [print delay].  We get the second printout to the console.</div><div dir="ltr"><br></div><div dir="ltr">Now here's the (lack of) magic: if you edit your patch and replace [delay 1000] with [delay 0], the same exact process happens in the same exact order.  The only difference is that Pd waits 0ms before doing step #3 instead of 1000ms.  But you're still guaranteeing the same order, and the program is still following all the same steps.  (In other words, [del 0] doesn't trigger any special code that I know of-- it really does schedule a delay, which just happens to be 0ms.)</div><div dir="ltr"><br></div><div dir="ltr">Finally, notice that the console printout stays the same even if you switch steps #1 and #2.  In other words, the [delay] ensures that you get the printout order you want, _regardless_ of the order in which you created the [env~] objects.</div><div dir="ltr"><br></div><div dir="ltr">Also, notice that this trick doesn't scale very well.  If you had a patch full of [del 0] to force ordering in the way you do above, you're almost guaranteeing that there will be bugs.</div><div dir="ltr"><br></div><div dir="ltr">Anyway, I hope everything I wrote above is correct!  These things are definitely difficult to explain and understand.</div><span class="HOEnZb"><font color="#888888"><div dir="ltr"><br></div><div dir="ltr">-Jonathan</div> <div><br><br></div></font></span><div style="display:block"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div class="h5"> <div dir="ltr"> <font face="Arial"> On Wednesday, December 17, 2014 2:10 PM, Raphaël Ilias <<a href="mailto:phae.ilias@gmail.com" target="_blank">phae.ilias@gmail.com</a>> wrote:<br> </font> </div>  <br><br> </div></div><div><div><div class="h5"><div><div dir="ltr"><div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>

</span>oh, but that is just trivial:<br>
<br>
messages and signals are always calculated one after each other (first<br>
all messages; once they are done, signals are processed).<br>
<br>
so an even easier way would be to use a latch ([f]) and [bang~]+[del 0]<br>
to do the calculation in msg-domain.<br>
[bang~] will output a bang before each signal block (or after; it really<br>
will trigger a bang before the *next* signal block).<br>
unfortunately, this bang can happen before or after the events sent out<br>
by [env~], so we need to make sure to get an event *after* all [env~]s<br>
have triggered.<br>
the simplest way to achieve this is by using an additional [delay 0],<br>
which will schedule an event at the same logical time NOW but after all<br>
events already scheduled for NOW (e.g. those from [env~]).<br>
<br>
see attached patch. (in the attached patch i wasn't able to trigger an<br>
undesired behaviour without the [delay 0]; however i haven't tried hard<br>
and i'm pretty sure that you *can*; thus you should use [del 0])<br>
<br></blockquote><div><br></div><div>thanks !<br></div><div>yes, with [delay 0] it ensures to get the good result (same block)...<br>(also tried to get an undesired behaviour without [del 0], but didn't succeed !)<br><br></div><div>i already used [delay 0] sometimes, but i don't see where it's role is documented<br></div><div></div><div><br>i already knew [bang~] but with this object my doubt was always : "i know that it will happen *every* block during message-domain computation, but *when* in that block ? relatively to other "not-triggerred" objects like [env~]..."<br></div><div><br></div><div>well, maybe i'm going too far with this... since you gave me a working solution :-)<br><br></div><div>however, also sent this to the pd-list because i wonder if i'm the only one to feel that this issue isn't very intuitive to solve...<br></div><div></div><div></div><br></div><div>cheers, <br><br>Raphaël<br></div></div></div></div><br></div></div><span class="">_______________________________________________<br><a>Pd-list@lists.iem.at</a> mailing list<br>UNSUBSCRIBE and account-management -> <a>http://lists.puredata.info/listinfo/pd-list</a><br><br><br></span></div>  </div> </div>  </div> </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" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div></div>