[PD-dev] iem_t3_lib - sample rate change

[Thomas Grill]

Am 23.08.2006 um 11:30 schrieb IOhannes m zmoelnig:

> Thomas Grill wrote:
>> Hi,
>> 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  
clocking functionality.

greetings,
Thomas

--
Thomas Grill
http://grrrr.org