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

IOhannes m zmoelnig zmoelnig at iem.at
Tue Feb 9 10:53:21 CET 2010


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100209/bde49b99/attachment.bin>


More information about the Pd-list mailing list