[PD] [env~] issues

[IOhannes m zmölnig]

On 12/15/2014 11:53 PM, Raphaël Ilias wrote:
> Ok, I get the trick, it seems similar to  the one used to make delay line
> shorter than one block.
> However, I still feel that an object "give-me-RMS enveloppe-on-bang" (for
> the last N samples or blocks) would appear to me an easier way to handle
> this case.
> If it doesn't exist, I'll try to build something like this... one day !
> Many thanks !

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])


mfgadsr
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: env-orderforcing.pd
Type: text/x-puredata
Size: 1563 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141216/5000c246/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141216/5000c246/attachment.sig>