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

ypatios ypatios at gmail.com
Sat Feb 6 19:31:01 CET 2010


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100206/4120c8ac/attachment.htm>


More information about the Pd-list mailing list