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