On Mon, Apr 19, 2021 at 6:51 PM Christof Ressi <[email protected]> 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
