Re: [PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
On 2010-02-07 10:34, ypatios wrote: > hello! > > By using [block~ 1], you're >> increasing the number of clock calls, and the arithmetic for finding >> an index is kind of wasted since the block is only one sample long. >> Maybe it would be best to avoid [block~] and bang vsnapshot~ with a >> metro set to 1/44.1 ms. You'd at least be reducing the number of >> clock_getlogicaltime() calls. >> > Thanks for that. I had no idea that there would be a difference between the > two. > one of most programming languages principles is to have a single name for a single functionality. if two things have different names, then they most often have different functionality. Pd is not so strict, as it allows "aliases". for instance, [f] and [float] are synonymous. the reason for aliases is mainly reducing the number of keystrokes. (sometimes, it's not; e.g. in Gem [color] and [colour] are synonymous as well). there has been plenty of discussion on whether it's a good idea to have aliases or not. anyhow, usually aliases do have a reason (be it keystrokes or spelling or...), and in general if objects are called differently, then they are different. thus [snapshot~] is not [vsnapshot~] and [line~] != [vline~]. finally: you cannot take "any" object that converts signals to messages when you want to measure something. just imagine it the other way round: it's a difference whether you take the [osc~] object or the [sig~] objects, even though both objects take a number and convert it into a signal. [sig~] will probably consume less CPU than [osc~], but additive synthesis might sound a bit boring. likewise with [snapshot~] and [env~]. if you are interested in sample values, take [snapshot~], if you need the amplitude of a signal, take [env~]. gmasdfrt 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
Re: [PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
Hallo, ypatios hat gesagt: // ypatios wrote: > Also, you should know that the result of [env~] is something akin to a > > low-pass filter; the "speed limiting" from the original patch might be > > done more efficiently by squaring the signal and sending it through a > > (probably aggressive) low-pass filter before sending it to vsnapshot > > -- in that case it's possible that regular old snapshot with a larger > > [block~] size might work just as well, since you'll be sending a > > signal that doesn't change as quickly. You also need to take into > > > I want to get the peak of the signal which means that any kind of filtering > or other manipulation before (or after except rate limiting) vsnapshot~ is > not a good idea. vsnapshot~ will almost never give you the peak. It just reports the single sample that happened when you bang'd it, which very likely is not a peak sample - peaks usually are rare. In fact, as vsnapshot~ only gives you one single sample you don't even have other samples to compare it to. So in any case you have to collect some more samples to find out if there is a peak inside, either some local peaks or a global peak over all your samples. 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. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
hello Also, you should know that the result of [env~] is something akin to a > low-pass filter; the "speed limiting" from the original patch might be > done more efficiently by squaring the signal and sending it through a > (probably aggressive) low-pass filter before sending it to vsnapshot > -- in that case it's possible that regular old snapshot with a larger > [block~] size might work just as well, since you'll be sending a > signal that doesn't change as quickly. You also need to take into > I want to get the peak of the signal which means that any kind of filtering or other manipulation before (or after except rate limiting) vsnapshot~ is not a good idea. However, a lp filter seems to be a nice way to get peak-to-peak triggering (but only the triggering, not the actual values). I am currenty trying to implement that, using the already existing env~ to determine when the signal is falling at which point the last max magnitude is send to the vu, after some rate limiting, peak "holding" etc.. It seems to work but still needs optimization. account that doing message-level computations every sample might be > fairly inefficient in general, and this is not something that [env~] > I guess you have to trigger vsnapshot~ at sample rate to make sure you don't miss any value. I can't think of any other way. After all, there is no computation going on,other than reading groups of magnitudes and storing the greatest of them. > is usually doing. Further, updating a vu gui every sample will > probably be almost ridiculously inefficient -- try comparing the two > setups with and without the vu connected (it may be that you have > already taken care of this in the "speed limiting" and are not > actually updating it every sample after all). > That's right :) (It's amazing how cpu-consuming wish can be. And that with GUI objects that look so simple. I wonder how other audio software manages to run say a dozen "vu" indicators or fine-looking spectrum plotting tools, all at fairly high refresh rates with acceptable cpu losses. Maybe a topic for another thread that i don't really want to start at the moment .. :P ) alabala -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
> >> It would be nice though, to know also on a theoretical level. Which one >> should be more expensive and (maybe) why. > > I was just taking a look at d_ctl.c from source. It looks like > snapshot~ is cheapest because it's not trying to get any specific > sample from the block. vsnapshot~ gets the logical time on every DSP > tick and copies each passing block to memory. Then, upon receiving a > bang, it gets the time elapsed since that last DSP tick. Based on > that time, it makes an index into the copied block to bring up the > exact sample that was flying by when you banged it (at least, as close > as possible). So that's a clock call and a block copy every 1.45 ms > with normal 64 sample block size, plus the arithmetic necessary to > compute the index into the block. By using [block~ 1], you're > increasing the number of clock calls, and the arithmetic for finding > an index is kind of wasted since the block is only one sample long. > Maybe it would be best to avoid [block~] and bang vsnapshot~ with a > metro set to 1/44.1 ms. You'd at least be reducing the number of > clock_getlogicaltime() calls. > > env~ is more or less just summing and squaring each block (very > cheap), then calling a powtodb conversion function. You've got it set > to process a block of 4096 samples every 2048 samples. So that's > taking advantage of the more efficient block processing strategy. > Also, you should know that the result of [env~] is something akin to a low-pass filter; the "speed limiting" from the original patch might be done more efficiently by squaring the signal and sending it through a (probably aggressive) low-pass filter before sending it to vsnapshot -- in that case it's possible that regular old snapshot with a larger [block~] size might work just as well, since you'll be sending a signal that doesn't change as quickly. You also need to take into account that doing message-level computations every sample might be fairly inefficient in general, and this is not something that [env~] is usually doing. Further, updating a vu gui every sample will probably be almost ridiculously inefficient -- try comparing the two setups with and without the vu connected (it may be that you have already taken care of this in the "speed limiting" and are not actually updating it every sample after all). Either way, it's always good to test efficiency with and without the guis, since the gui operations add an extra layer. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
hello! By using [block~ 1], you're > increasing the number of clock calls, and the arithmetic for finding > an index is kind of wasted since the block is only one sample long. > Maybe it would be best to avoid [block~] and bang vsnapshot~ with a > metro set to 1/44.1 ms. You'd at least be reducing the number of > clock_getlogicaltime() calls. > Thanks for that. I had no idea that there would be a difference between the two. All this being said, the CPU load difference between these setups is > basically nothing on my 2.5GHz MacBook Pro. I guess the differences > would start to emerge if you compared dozens of instances of each. > Yeah, in my tests i got notable differences from about 512 to 1024 instances. > > Hope that helps... > Not only did it help, it made my day. I hope the time you spend peaking in the code will be useful to you and others. Thank you -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
> It would be nice though, to know also on a theoretical level. Which one > should be more expensive and (maybe) why. I was just taking a look at d_ctl.c from source. It looks like snapshot~ is cheapest because it's not trying to get any specific sample from the block. vsnapshot~ gets the logical time on every DSP tick and copies each passing block to memory. Then, upon receiving a bang, it gets the time elapsed since that last DSP tick. Based on that time, it makes an index into the copied block to bring up the exact sample that was flying by when you banged it (at least, as close as possible). So that's a clock call and a block copy every 1.45 ms with normal 64 sample block size, plus the arithmetic necessary to compute the index into the block. By using [block~ 1], you're increasing the number of clock calls, and the arithmetic for finding an index is kind of wasted since the block is only one sample long. Maybe it would be best to avoid [block~] and bang vsnapshot~ with a metro set to 1/44.1 ms. You'd at least be reducing the number of clock_getlogicaltime() calls. env~ is more or less just summing and squaring each block (very cheap), then calling a powtodb conversion function. You've got it set to process a block of 4096 samples every 2048 samples. So that's taking advantage of the more efficient block processing strategy. All this being said, the CPU load difference between these setups is basically nothing on my 2.5GHz MacBook Pro. I guess the differences would start to emerge if you compared dozens of instances of each. Hope that helps... William ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
sorry, i need to correct my self: signal > | > | [bang~ ] [block~ 1] > | / > [vsnapshot~ ] > | > (some speed limiting with care taken not to lose highest amplitude..) > | > vu right input for peak > ) > should be: signal | | [bang~ ] [block~ 1] | / [vsnapshot~ ] | [abs ] | [rmstodb ] | (some speed limiting with care taken not to lose highest amplitude..) | [- 100] | vu right input for peak ) -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
hello :-) They seem to reach the list. At least I received this and your previous > mail. > Thanks for that! What I still don't understand: Why do you want to compare those? > [vsnapshot~] and [env~] do completely different things. > Im trying to find a good way to monitor a signal. Since they both take signals and output messages that makes them candidates. The fact is that i use both env~ and vsnapshot~ anyway in a "channel strip" abstraction to feed the inputs of a [vu ] with the rms and peak level respectively. However, i need another instance of one of them to determine whether there is a (non-constant-zero)signal present at all. And i'm trying to find out which one should i duplicate. I did the cpu test and it shows that env~ is lighter. However, a snapshot~ triggered every 1024 samples (same rate as env~) is even lighter, which makes sense, since snapshot does no computing. I just thought that vsnapshot~ triggered at samplerate would be lighter than an env~, which seems to be a false assumption. Thanks for the tip :-). It would be nice though, to know also on a theoretical level. Which one should be more expensive and (maybe) why. (...) Anyways, while writing this email, it came to me that i don't really need an extra object(!) Instead of switching between pre and post fader mode in audio level, i do that in message level so i can use one of the two existing objects to determine if an active signal is present. The question remaining is: Is there a better way to feed a [vu ] in pd vanilla? ( just in case someone missed it: signal | [env ~ 4096] | [-100] | vu left input for rms and signal | | [bang~ ] [block~ 1] | / [vsnapshot~ ] | (some speed limiting with care taken not to lose highest amplitude..) | vu right input for peak ) ciao -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
Hi They seem to reach the list. At least I received this and your previous mail. I can't tell reliably which of those is consuming more cpu in which situation. From what I understood, 'doing something' with a signal vector of a certain size (64 samples, for instance) is cheaper than 'doing the same thing' with the same number of floats (64, for the same instance). However, you can measure it yourself in order to get some empirical basis for my above assumption. Implement each as an abstraction, instantiate that abstraction a number of times and check your cpu load. What I still don't understand: Why do you want to compare those? [vsnapshot~] and [env~] do completely different things. Roman On Sat, 2010-02-06 at 14:27 +0100, ypatios wrote: > Do my emails fail to reach the list or are my questions that > irrelevant? > it feels kind of spooky out here.. > > alabala > -- > ypatios > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
Do my emails fail to reach the list or are my questions that irrelevant? it feels kind of spooky out here.. alabala -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
hello, and more precisely: env~ 1024 vs vsnapshot~ (triggered at samplerate) i guess, since env~ does rms computing of a window of values it should be more expensive than vsnapshot~, even at this hight rate the later is triggered. as for the env~ window length, i understand that it is irrelevant to the cpu cycles needed. but i am not sure. maybe i am missing something. thanks for any help :-) -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
