[PD] precision of vline~ and/or pd messaging
fbar at footils.org
Thu Jan 26 09:20:47 CET 2012
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:
>> 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].
> 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:
Especially note the subchapters:
"Converting controls to signals"
and help patch: C04.control.to.signal.pd
Frank Barknecht Do You RjDj.me? _ ______footils.org__
More information about the Pd-list