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