[PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?

ypatios ypatios at gmail.com
Tue Feb 9 04:13:13 CET 2010


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

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  )


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100209/549960cf/attachment.htm>

More information about the Pd-list mailing list