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
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list