and here a link to a thread with iohannes and lyon:
http://markmail.org/message/7usetdchjlqyk3eu#query:+page:1+mid:7usetdchjlqyk3eu+state:results
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]"?
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? 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)
thanks,
João
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
