[PD-dev] iem_t3_lib - sample rate change
gr at grrrr.org
Wed Aug 23 13:09:27 CEST 2006
Am 23.08.2006 um 11:30 schrieb IOhannes m zmoelnig:
> Thomas Grill wrote:
>> i wasn't sure if the blocking really has an impact on the t3
>> messages, but you might be right. With the patch i only wanted to
>> mirror driver-related changes.
>> I had to discard the first solution, because the objects don't
>> have signal inlets or outlets, so they won't get signal vectors to
>> take sr and n from.
> well yes, but that is easy to fix.
sure, but it's your decision to give to objects a signal inlet, which
i didn't want to take.
>>> PS: i think that all (and more) of the functionality of
>>> iem_t3_lib can be done with the builtin [vline~] object.
>> probably, but one has to go to the signal domain then, taking much
>> more cpu.
> you only get the sample accuracy of iem_t3 when you swap to signal
> domain (with [t3_sig~] and [t3_line~]); that's the whole point of
> the library: to let messages happen at a certain moment in the
> signal~ scheduler. this is, what [vline~] also provides.
> as long as you are using iem_t3_lib only(!) in message domain, you
> will gain exactly no precision. (in message domain we are dealing
> with idealized time anyhow)
what you get is a kind of time-stamped metro which can have message-
based applications too.
I have to say that i won't use the t3-objects themselves, just looked
into them - but i'll use some mechanics of them for some more general
More information about the Pd-dev