[PD] timing

brandon zeeb zeeb.brandon at gmail.com
Thu Dec 23 01:04:00 CET 2010


My fault, you're right.  I'm happily wrong about this one.

Cheers,
Brandon

On Dec 22, 2010 9:52 AM, "Roman Haefeli" <reduzent at gmail.com> wrote:

On Wed, 2010-12-22 at 09:01 -0500, brandon zeeb wrote:
> If Pd's default block size is 64 samples, a...
Not true. Events a.k.a messages are 'virtually' [1] processed at any
time (literally any time, which includes any time between samples. The
only restriction is the resolution of the 32bit floating point number
format used by Pd).

This can be easily shown with this little patch:

[metro 3.1415]
|
[t b b]
|    |
[timer]
|
[3.1415\ <- number box

You can change the metro to any value and [timer] will report back
exactly that value. AFAIK, this exact timing occurs as long we're
considering the message-only domain.

However, there are some objectclasses which accept messages at the
inlets and produce signals at the outlets, e.g. [sig~]. Many (almost
all?) of them only evaluate the messages _at_ block boundaries and thus
the resulting signal can only be changed at block boundaries. This
effect makes the messages look like they only happen at block
boundaries, although they actually happen at any time.

There are other objects that work in both, message and signal domain,
which don't suffer from that problem: [vline~] and [vsnapshot~]. Both
take the exact timing of the message into account.


[1]: I say 'virtually', because Pd actually really computes one or
several events only once per block, though is this done transparently
when looking from the outside.


Summary:

* [metro] and [del] are as accurate as you can wish them to be.

* Always use [vline~] when timing-exact conversion from message to
signal matters

* most tilde-classes with message inlets ignore the timing of the
messages

* You don't need lower block sizes for having exact timing in the
message domain

* Messages triggered from  external sources (GUIs [bng]/[hslider] etc.,
MIDI [midiin]/[ctlin] etc., networking [netreceive] etc., serial
[comport], etc.) usually don't have more exact timing than the block
size.

Roman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101222/26f85ede/attachment-0001.htm>


More information about the Pd-list mailing list