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.
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)
mfga.sdr IOhannes