Re: [PD] peak amplitude in pd vanilla (was: [env~] vs [vsnapshot~]: which one is more cpu consuming?)
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
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@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
-
Matt Barber