[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