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