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 <[email protected]> > 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 > > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
