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

It would be nice though, to know also on a theoretical level. Which one should be more expensive and (maybe) why.

I was just taking a look at d_ctl.c from source. It looks like snapshot~ is cheapest because it's not trying to get any specific sample from the block. vsnapshot~ gets the logical time on every DSP tick and copies each passing block to memory. Then, upon receiving a bang, it gets the time elapsed since that last DSP tick. Based on that time, it makes an index into the copied block to bring up the exact sample that was flying by when you banged it (at least, as close as possible). So that's a clock call and a block copy every 1.45 ms with normal 64 sample block size, plus the arithmetic necessary to compute the index into the block. By using [block~ 1], you're increasing the number of clock calls, and the arithmetic for finding an index is kind of wasted since the block is only one sample long. Maybe it would be best to avoid [block~] and bang vsnapshot~ with a metro set to 1/44.1 ms. You'd at least be reducing the number of clock_getlogicaltime() calls.

env~ is more or less just summing and squaring each block (very cheap), then calling a powtodb conversion function. You've got it set to process a block of 4096 samples every 2048 samples. So that's taking advantage of the more efficient block processing strategy.

All this being said, the CPU load difference between these setups is basically nothing on my 2.5GHz MacBook Pro. I guess the differences would start to emerge if you compared dozens of instances of each.

Hope that helps... William

On 2010-02-07 10:34, ypatios wrote:

hello!

By using [block~ 1], you're

...

increasing the number of clock calls, and the arithmetic for finding an index is kind of wasted since the block is only one sample long. Maybe it would be best to avoid [block~] and bang vsnapshot~ with a metro set to 1/44.1 ms. You'd at least be reducing the number of clock_getlogicaltime() calls.

Thanks for that. I had no idea that there would be a difference between the two.

one of most programming languages principles is to have a single name for a single functionality. if two things have different names, then they most often have different functionality.

Pd is not so strict, as it allows "aliases". for instance, [f] and [float] are synonymous. the reason for aliases is mainly reducing the number of keystrokes. (sometimes, it's not; e.g. in Gem [color] and [colour] are synonymous as well). there has been plenty of discussion on whether it's a good idea to have aliases or not. anyhow, usually aliases do have a reason (be it keystrokes or spelling or...), and in general if objects are called differently, then they are different. thus [snapshot~] is not [vsnapshot~] and [line~] != [vline~].

finally: you cannot take "any" object that converts signals to messages when you want to measure something. just imagine it the other way round: it's a difference whether you take the [osc~] object or the [sig~] objects, even though both objects take a number and convert it into a signal. [sig~] will probably consume less CPU than [osc~], but additive synthesis might sound a bit boring.

likewise with [snapshot~] and [env~]. if you are interested in sample values, take [snapshot~], if you need the amplitude of a signal, take [env~].

gmasdfrt IOhannes

Hi IOhannes :-)

thanks for the tips! i apologize for being hasty, there was a series of different stuff (not) going on and it felt weird.. :s

cu