[PD] [env~] issues

Raphaël Ilias phae.ilias at gmail.com
Wed Dec 17 20:08:32 CET 2014

> 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

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

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...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141217/649d5858/attachment-0001.html>

More information about the Pd-list mailing list