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