[PD] precision of vline~ and/or pd messaging

[Claude Heiland-Allen]

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 ;)