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

[Matt Barber]

>
>> 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.
>


Also, you should know that the result of [env~] is something akin to a
low-pass filter; the "speed limiting" from the original patch might be
done more efficiently by squaring the signal and sending it through a
(probably aggressive) low-pass filter before sending it to vsnapshot
-- in that case it's possible that regular old snapshot with a larger
[block~] size might work just as well, since you'll be sending a
signal that doesn't change as quickly.  You also need to take into
account that doing message-level computations every sample might be
fairly inefficient in general, and this is not something that [env~]
is usually doing.  Further, updating a vu gui every sample will
probably be almost ridiculously inefficient -- try comparing the two
setups with and without the vu connected (it may be that you have
already taken care of this in the "speed limiting" and are not
actually updating it every sample after all).  Either way, it's always
good to test efficiency with and without the guis, since the gui
operations add an extra layer.

Matt