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 ;)
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
