Hi,
On Wed, Jan 25, 2012 at 10:38:06AM +0100, João Pais wrote:
and here a link to a thread with iohannes and lyon: http://markmail.org/message/7usetdchjlqyk3eu#query:+page:1+mid:7usetdchjlqyk...
Actually it's Frank and Eric. :) The thread still sums up what's important here: It's not necessary to use Eric's objects in Pd. They may be useful in Max/MSP and they provide some nice functionality besides accuracy, but the accuracy you get with vline~ and Pd's clock objects (metro, delay, etc.) already is subsample-exact, so it's fine for many cases and as good as what you get with [samm~] and relatives. Just use [metro].
oops.
so, your wording in the final sentence should be something like "so it's
fine for many cases and MORE PRECISE as what you get with [samm~] and relatives. Just use [metro]"?
I don't think, it's "more precise", I think, Eric's objects are just an alternative approach to get the same precision as you get with vline~. IIRC Eric wasn't aware of vline~ when he wrote his objects.
just to ask beforehand: between the bang starting the event and vline~
there are a couple of patches: getting the counter nr, segment references, quantisation etc, all in message level (with vanilla and extra objects). But if the initial bang is "block-precise" (wherever in the audio block it should be), all message objects should behave fine?which are "Pd's clock objects" you described above, all objects in the
"time" section of pd-van?
Yes, but of course people can write externals that use Pd's internal clock just as metro, delay or pipe do. Contrasting these you may have a non-clock message, for example if you click a [bang( message. This will actually not be activated at the exact time that you click it, but always on a block boundary.
will also pd-ext objects behave in the same way, provided that it's not their function to include more delays? I'll rephrase the question, if between bang and vline~ I put an external
doing a multiplication or something, will it delay the message? (I guess
the answer is no, but want to be sure)
The usual message transformation objects don't change the timing of the original message. Pd is deterministic, so you can assume that all the message calculations etc. that you do happen "at the same time".
Timing problems occur only when you leave or enter this message realm, for example when converting messages to (and from) audio signals, because audio signals in Pd are block based. The gory details are in Miller's TTEM-book: http://crca.ucsd.edu/~msp/techniques/latest/book-html/node40.html
Especially note the subchapters: "Control streams" http://crca.ucsd.edu/~msp/techniques/latest/book-html/node43.html and "Converting controls to signals" http://crca.ucsd.edu/~msp/techniques/latest/book-html/node52.html and help patch: C04.control.to.signal.pd
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__