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

[Matt Barber]

If you need to send a 0 at the beginning of each block, here are some
interesting ways of doing it that just occurred to me:

______________________________

[sig~ -1]  [block <blocksize>]
 |
[rfft~]
 |
[/~ <blocksize>]
 |
[+~ 1]
 |

_______________________________


and the best:

_______________________________

[sig~ 1]  [block~ <blocksize>]
 |
[lrshift~ -1]
 |

________________________________

An [lrshift~ 1] will give you a 0 at the end of block.

Attached is an abstraction which should output the signed peak of the
current block as a signal.  Optional creation argument for the size of
the block you want to use, and the block size is also settable via the
right inlet [set <blocksize>(


If you don't want signed peak you can make this quite a bit more
efficient by dropping in the patch from before.


MB

On Mon, Feb 15, 2010 at 7:29 PM, Matt Barber <brbrofsvl at gmail.com> wrote:
>> 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: peak-sample~.pd
Type: application/octet-stream
Size: 3372 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100216/e89a84d9/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: peak-sample~-help.pd
Type: application/octet-stream
Size: 554 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100216/e89a84d9/attachment-0001.obj>