|ypatios||Feb 9, 2010 2:21 am|
|IOhannes m zmoelnig||Feb 9, 2010 2:31 am|
|IOhannes m zmoelnig||Feb 9, 2010 3:02 am||.zip|
|Frank Barknecht||Feb 9, 2010 3:22 am|
|Matt Barber||Feb 9, 2010 6:48 am|
|William Brent||Feb 9, 2010 6:13 pm|
|ypatios||Feb 14, 2010 7:05 pm|
|Frank Barknecht||Feb 19, 2010 1:01 am||.tgz|
|Chris McCormick||Feb 19, 2010 4:08 am|
|Subject:||[PD] peak amp in Pd "almost" vanilla with tabwriteat~ [was: Re: peak amplitude in pd vanilla]|
|From:||Frank Barknecht (fb...@footils.org)|
|Date:||Feb 19, 2010 1:01:09 am|
tabwriteat.tgz - 8k
I made an *almost* Pd vanilla version, that performs really well. It's "almost" because it requires an operation, that currently is an external, but Miller has expressed his intention to include it in one of the next versions here: http://lists.puredata.info/pipermail/pd-list/2009-08/071538.html
The external required in the attachment is called "tabwriteat~" ad it is the signal-equivalent to [tabwrite], i.e. it writes a number into a table at a position specified by a signal. This is immensly useful in many cases and sorely missing from Pd since a long time. Finding the peak of a signal is one possible application. tabwriteat~ is so useful because it add a little bit of recursion to in-block processing as you can store intermediate results into a table and read it again in the next sample of the same block.
For peak-finding the algorithm thenn becomes very simple: Just find the peak between two samples with [max~], store the maximum in a table with [tabwriteat~] and reuse the table's value in the next comparison.
Check out findpeak~.pd in the attachement, which also includes source and a linux binary of tabwriteat~. Hopefully Miller includes it soon under whatever name (poke, poke ...) :)
ypatios hat gesagt: // ypatios wrote:
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)