My fault, you're right. I'm happily wrong about this one.
Cheers, Brandon
On Dec 22, 2010 9:52 AM, "Roman Haefeli" reduzent@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
messages
message domain
MIDI [midiin]/[ctlin] etc., networking [netreceive] etc., serial [comport], etc.) usually don't have more exact timing than the block size.
Roman