On 24/01/12 21:50, João Pais wrote:
maybe the messaging isn't precisely aligned with the audio. For this patch I'm using E Lyon's samm~ and click2bang~
I'm not familiar with those externals, nor in inspecting the output of a patch (which is on the large size) instead of the patch. But some general points:
Timing of message->signal is 100% accurate with vline~ or other clock-aware objects, because all the message processing for a given dsp block happens before the dsp block is calculated. vline~ and other objects can use the timestamp of the messages (which is in the future compared to the dsp processing) and schedule their dsp computations appropriately. If you use metro, delay, vline~ all your timing will be in sync.
Timing of signal->message is problematic, for the same reason: the earliest a message can be sent is after the whole dsp block is calculated, so if you need to send a message mid-way through a dsp block you'd need a time machine to go back in time(*) before the dsp block was started to be computed and then trigger a message with a future (during the dsp block) timestamp.
The best you can do is a 1-block delay for signal->message, so perhaps click2bang~ should be modified to tell you where in the block the click(s) occurred so you can compensate, assuming any delay/latency is acceptable. Or you could implement an abstraction to do something like this using [tabsend~] and [bang~]. Or you could run your patch at 192kHz where 125ms is a multiple of the default block size, or you could use a block size of 1.
Claude
(*) If affordable time travel will be invented I'd have not sent this email ;)