Hi,
this does not react on blocksize changes either, and the samplerate changes it reacts on are only changes to the playback (soundcard!) samplerate (e.g. when you change the samplerate via the menu (or pd- messages) which is not the thing you usually do)
the blocking of the canvas will be completely ignored by this patch. however, in your first patch (the "wrong" one) you also took [block~] into account. what is the reason to discard this solution?
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.
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.
greetings, Thomas
-- Thomas Grill http://grrrr.org