[PD] [env~] issues

[Raphaël Ilias]

Thank you Jonathan, this is very instructive !

2014-12-17 22:53 GMT+01:00 Jonathan Wilkes <jancsika at yahoo.com>:
>
> Hi Raphaël,
>
> The problem is not very intuitive to solve.
>
> It's difficult enough to understand the flow in a patch that only uses
> signal objects.  And it'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.)
>
> 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.
>
> That isn't trivial to understand, much less come up with as a solution in
> the situation of [env~].
>
> 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:
> [env~]
> |
> [bang]
> |
> [delay 1000]
> |
> [print delayed]
>
> [env~]
> |
> [bang]
> |
> [print normal]
>
> 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:
> * 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:
> 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.
> 2) message goes from [env~] to [bang] to [print normal].  We get an
> immediate printout to the console.
> 3) 1000ms passes, and [delay 1000] finally sends to [print delay].  We get
> the second printout to the console.
>
> 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.)
>
> 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.
>
> 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.
>
> Anyway, I hope everything I wrote above is correct!  These things are
> definitely difficult to explain and understand.
>
> -Jonathan
>
>
>   On Wednesday, December 17, 2014 2:10 PM, Raphaël Ilias <
> phae.ilias at gmail.com> wrote:
>
>
>  oh, but that is just trivial:
>
> messages and signals are always calculated one after each other (first
> all messages; once they are done, signals are processed).
>
> so an even easier way would be to use a latch ([f]) and [bang~]+[del 0]
> to do the calculation in msg-domain.
> [bang~] will output a bang before each signal block (or after; it really
> will trigger a bang before the *next* signal block).
> unfortunately, this bang can happen before or after the events sent out
> by [env~], so we need to make sure to get an event *after* all [env~]s
> have triggered.
> the simplest way to achieve this is by using an additional [delay 0],
> which will schedule an event at the same logical time NOW but after all
> events already scheduled for NOW (e.g. those from [env~]).
>
> see attached patch. (in the attached patch i wasn't able to trigger an
> undesired behaviour without the [delay 0]; however i haven't tried hard
> and i'm pretty sure that you *can*; thus you should use [del 0])
>
>
> thanks !
> yes, with [delay 0] it ensures to get the good result (same block)...
> (also tried to get an undesired behaviour without [del 0], but didn't
> succeed !)
>
> i already used [delay 0] sometimes, but i don't see where it's role is
> documented
>
> 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~]..."
>
> well, maybe i'm going too far with this... since you gave me a working
> solution :-)
>
> 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...
>
> cheers,
>
> Raphaël
>
> _______________________________________________
> 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/20141218/a0df819b/attachment-0001.html>