[PD] OSC limitations in Vanilla

IOhannes m zmölnig zmoelnig at iem.at
Sun Apr 18 22:32:34 CEST 2021


On 4/18/21 17:06, Martin Peach wrote:
> On Sun, Apr 18, 2021 at 6:06 AM IOhannes m zmölnig <zmoelnig at iem.at> wrote:
>>
>> I don't really like the timestamp implementation in mrpeach (as it uses real time, rather than logical time), but better this than nothing...
> 
> Logical time timestamps would only be accurate inside of the Pd
> instance.

i tend to disagree.
there are basically two use-cases for timetags:
- reducing jitter when synthesising events on the receiver
   e.g. i want to trigger a drum-synth exactly every 100ms
- reducing jitter when analysing events from the sender
   e.g. i want to measure the period between two mocap frames

neither of these use-cases warrant system time.

here's a real world example:
if i use Pd to send events to my drum-synth, and i want these events to 
be exactly 100ms apart so I'm driving it with a [metro 100], the real 
time of these ticks will be very jittery (depending on all sorts of 
things, starting with the audio buffer of Pd), up to dozens of ms.

if i codify this jitter in the timestamps, then any law abiding receive 
will have to do their best to reproduce this jitter.

what is the value in that?
the only way to schedule two events at exact times I see is to use some 
"ideal" time - in Pd this is the logical time.

> but it would not conform to
> any OSC specification.
> 

i checked and double checked the specs but could not find anything about 
this.
where do you get the idea that the OSC specs mandate wall clock time?
OSC-1.0 speaks about "NTP format" (but this is just the structure of the 
64 bits data chunk) and "the number of seconds since midnight on January 
1, 1900" (but it doesn't say whether this is supposed to be wallclock or 
idealized)

 > It could be added as an option

a flag or similar would be great.
there probably are use-cases where real time makes sense, why not be 
able to cater for both.

f,dst
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210418/183d778f/attachment.sig>


More information about the Pd-list mailing list