[PD] peak amplitude in pd vanilla (was: [env~] vs [vsnapshot~]: which one is more cpu consuming?)

[Matt Barber]

> hello
>
> im sorry i left the thread for some time now.
> thank you all very much for your replies.
>
> Your results are confirmed here too: the two methods with vsnapshot~  and
> writing-reading to a table are equally inefficient.
> Matt's suggestion --whilst much more efficient-- has a serious disadvantage:
> it seems that there is no way of reseting [max~ ] without losing some
> samples (which could include a "peak").
> Generally, i had many confusing problems while testing that one. Has anyone
> else tried it??
>
> I give up for now due to the lack of time
> if anyone has another idea, please share! :-)
>
> (By the way: there is another limitation i noticed in [bang~ ]: it won't go
> faster than 1 bang every 64 samples, even if the block size is set under
> that)
>

Best would be to reset it with the result of subtracting a dirac delta
from a constant signal of 1 (which should give a one-sample 0).

Attached is a [dirac-delta~] abstraction -- it could be far more
efficient for your purposes, but it's meant to work more or less like
the [dirac~] object from zexy so it has a couple of extra goodies you
probably don't need.

I forgot what the [bang~] is supposed to do -- was it to reset the
[max~] every block?  In that case a tentative solution would be to set
a phasor to run at exactly the frequency corresponding to the period
of a block size, and divide it by itself.  If the phase remains zero
and you feed it nothing but powers of two, it should produce a 0 once
per cycle (and thus once per block).  There are more robust solutions,
but this might work in a pinch.

MB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dirac-delta~.pd
Type: application/octet-stream
Size: 1253 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100215/ef701682/attachment.obj>