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
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
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
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.
Frank