Re: [PD] peak amplitude in pd vanilla (was: [env~] vs [vsnapshot~]: which one is more cpu consuming?)
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 ] | [rfft~] | [/~ ] | [+~ 1] | ___ and the best: ___ [sig~ 1] [block~ ] | [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 ( 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 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
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 dirac-delta~.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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) thanks again alabala -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] peak amplitude in pd vanilla (was: [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?)
> Note that [metro] has a lower limit of 1 ms, so you need to make your own > metro-abstraction. Ah - I had no idea that this was true. I suggested using a metro with a rate of 1/44.1 ms as an alternative to [block~ 1], but I guess there's no way around it... It seems like the best thing to have for this case would be an extern that just reports the level of the peak sample in each block. Time resolution would be limited to the 64 sample block size, but there's probably not much need for this to be faster, right? And you could always reblock if you need more. Maybe you're looking for a purely vanilla solution to this, but if not, the extern would be quick to make if someone hasn't made it already. Let me know and I'd be happy to do it. William ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] peak amplitude in pd vanilla (was: [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?)
> > As I understand it (and hopefully i am not completely wrong..) you don't > have to 'store' a list and 'then' read again it to find the max magnitude. > It's as simple as the following: > > (some signal) > *I* > *I* [pd me...@samplerate] > *I*/ > [vsnapshot~ ] > | > [abs ] > | > [moses ]X[t f ] > | > [f ] > I think I may have misunderstood your task earlier. In any case, you'll probably still do what you want more efficiently at the signal level: --- [inlet~] [block~ 1] | [abs~] [delread~ $0-compare 0] | / |/ [max~] |\ | \ | [delwrite~ $0-compare 1] | [outlet~] --- The [delread~] should be a one-sample delay, so you're just comparing the previous maximum with the current sample and outputting the larger of the two. Then on the outside you can poll that with snapshot~ periodically just like you did your float object above. If you need to reset it, I think you can just have the [delread~] feed into a [*~] with a [line~] that jumps from 1 to 0 and back to 1. Use [switch~ 1] instead of [block~ 1] if you want to be able to test the cpu load from that patch. I hope this works. I don't think that [env~] does what you want it to at all. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] peak amplitude in pd vanilla (was: [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?)
Hallo, ypatios hat gesagt: // ypatios wrote: > As I understand it (and hopefully i am not completely wrong..) you don't > have to 'store' a list and 'then' read again it to find the max magnitude. > It's as simple as the following: > > (some signal) > *I* > *I* [pd me...@samplerate] Note that [metro] has a lower limit of 1 ms, so you need to make your own metro-abstraction. > *I*/ > [vsnapshot~ ] > | > [abs ] > | > [moses ]X[t f ] > | > [f ] > > So in the last [f ] you have the max magnitude stored and you can bang it to > the [vu ] inlet say at a fix rate (which is the simplest way, it just > requires a [metro ] banging [f ] and resetting [moses ]) > > I don't understand how using an array to store samples and then analyse it > is more efficient than that. It seems to me you have to read 2 times: one to > write the array in the fist place and one more to analyse it. Yes, but I assume that banging vsnapshot~ every sample is more expensive than just banging [tabwrite~] every 64 samples or less often. And table-access is cheap. However I did some tests now and it seems that the difference is not that big. I couldn't find a clear winner, so probably either solution can work for you. I didn't test the table-analysing externals from iem_tab, though, but did it "manually" using a counter and [max]x[f] Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] peak amplitude in pd vanilla (was: [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?)
On 2010-02-09 11:21, ypatios wrote: > Hallo Frank :-), thanks for your reply > > (i updated the subject since the discussion moved on..) > > While you could bang vsnapshot~ at samplerate and keep track of samples in a >> list or so, this is a waste of resources. Something like tabsend~ or >> tabwrite~ >> probably is much better: Just write a number of samples into a table and >> then >> analyse that for peaks. There are some externals for that or do it >> manually. >> > > As I understand it (and hopefully i am not completely wrong..) you don't > have to 'store' a list and 'then' read again it to find the max magnitude. > It's as simple as the following: i haven't tested it, but you might be way more efficient when using [tabsend~] to write to an array and analyse it as frank suggested. ah, and iemlib's [pvu~] has a rudimentary peak-detector built in, if you can live with externals. fgm,adr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] peak amplitude in pd vanilla (was: [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?)
Hallo Frank :-), thanks for your reply (i updated the subject since the discussion moved on..) While you could bang vsnapshot~ at samplerate and keep track of samples in a > list or so, this is a waste of resources. Something like tabsend~ or > tabwrite~ > probably is much better: Just write a number of samples into a table and > then > analyse that for peaks. There are some externals for that or do it > manually. > As I understand it (and hopefully i am not completely wrong..) you don't have to 'store' a list and 'then' read again it to find the max magnitude. It's as simple as the following: (some signal) *I* *I* [pd me...@samplerate] *I*/ [vsnapshot~ ] | [abs ] | [moses ]X[t f ] | [f ] So in the last [f ] you have the max magnitude stored and you can bang it to the [vu ] inlet say at a fix rate (which is the simplest way, it just requires a [metro ] banging [f ] and resetting [moses ]) I don't understand how using an array to store samples and then analyse it is more efficient than that. It seems to me you have to read 2 times: one to write the array in the fist place and one more to analyse it. a simple comparison: read-analyse vs. read-write-read-analyse Please correct me if i am missing something and post an example with the use of an array if you can. alabala -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
