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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list