[PD] peak amp in Pd "almost" vanilla with tabwriteat~ [was: Re: peak amplitude in pd vanilla]

Frank Barknecht fbar at footils.org
Fri Feb 19 10:01:32 CET 2010


Hallo,

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 ...) :)

Ciao
-- 
Frank

ypatios hat gesagt: // ypatios 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)
> 
> 
> thanks again
> 
> alabala
> 
> -- 
> ypatios

> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tabwriteat.tgz
Type: application/x-gtar
Size: 5939 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100219/7233058e/attachment.tgz>


More information about the Pd-list mailing list