[PD] OSC limitations in Vanilla

[Martin Peach]

On Mon, Apr 19, 2021 at 6:51 PM Christof Ressi <info at christofressi.com> wrote:
>
> so what i'm really suggesting to "fix" the timestamps in [packOSC] is to use logical time for *advancing time* (and add some offset to put the timestamps into the same calendar as NTP)
>
> This corresponds to 2) in my previous mail. While this sounds simple in theory, in practice you will encounter problems with clock drift sooner or later. Supernova had to introduce an option to use the system time instead of the logical time because some users had experienced issues. For a drastic example, search for "timing drift supernova" in https://www.listarc.bham.ac.uk/lists/sc-dev-2014/search/
>

You probably need some kind of 'resync' messages sent
quasi-periodically, but when?
I have implemented in [packOSC] acquiring the OS's clock time when the
first instance of [packOSC] starts up, by sing a global variable for
the start epoch.
All subsequent timestamps are generated using that offset plus Pd's
DSP clock, so all [packOSC]s in a patch will generate the same timetag
for the same DSP tick.
So the question is, how to do the resync when the drift gets out of hand?
I do think that any fancy timing stuff should be done outside of
[packOSC] and the [timetagoffset( message be used to stay in sync.

Martin