[PD] timing

[Dietrich Pank]

thank you guys for your answers!

I think I understand the basic theory.
Experience is something else... e.g.
line~ and metro doesn't work sample correct even in block~ size 1
vline~ doesn't work in block~ sizes <64

And even thresholds fastest response is 64, less block size doesn't increase
it's quality. I'm baffled because I understood this object as gateway from
audio back to event (sample count/analysis to trigger)...

Anyway. I'm too focused I'm afraid. There will be a lot other possibilities.

thank you for clarifications so far!

best
Dietrich



2010/12/22 Roman Haefeli <reduzent at gmail.com>

> On Wed, 2010-12-22 at 09:01 -0500, brandon zeeb wrote:
> > If Pd's default block size is 64 samples, and "events" are only
> > processed at the beginning of a block cycle.
>
> 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
>
>
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101223/0539244a/attachment.htm>