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 <brbrof...@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 >
peak-sample~.pd
Description: Binary data
peak-sample~-help.pd
Description: Binary data
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list