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

João Pais jmmmpais at googlemail.com
Wed Jan 25 10:30:32 CET 2012


Hi Claude,

so you're saying that vline~ "or other clock-aware objects" [which, btw?]  
is precise in itself, so the problem should come from E Lyon's objects,  
which aren't, because of sig->mess conversion? (which is funny, because  
apparently they were made to correct this, at least in max/msp)

It seems then that the best solution would be to avoid the "fancy stuff"  
and use a plain simple metro?
(In case you have nothing better to do, could you check if Lyon's code is  
really as block-precise as it says?)

Thanks,

João

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



More information about the Pd-list mailing list