Do not sync to Pd's logical time

[Spacechild1]

I had been receiving and scheduling OSC bundles and I was wondering, why all my bundles were extremely late.

Turns out that osc 0.3 now uses Pd's logical time as the time base by default. (2b0b28d)

There are serious problems with this approach:

1. When DSP is on, Pd's logical time is based on sample time, which slowly drifts away from NTP time. This can easily lead to clock differences of 100ms or more over the course of 30 minutes.

2. When DSP is on, Pd's logical time does not keep up with the NTP time. For example, if I load a bunch of large soundfiles, this might take a few seconds in realtime while Pd's logical time stays the same. Now [osc/unpackOSC]'s time base is permanently behind, until I reset it with"pddsptime 1". Even the act of turning on DSP can shift the time base!

This can be easily verified by sending OSC bundles to Pd. I tested this with the following SuperCollider snippet:

a = NetAddr("localhost", 4000);

a.sendBundle(1, ['/foo', 1, 2, 3]); // -> the time offset output of [osc/unpackOSC] should be close to 1000

// now load a large patch in Pd while DSP is on

a.sendBundle(1, ['/foo', 1, 2, 3]); // -> the time offset is now always significantly larger than 1000

---

This issue affects both [osc/packOSC] and [osc/unpackOSC].

I would suggest to:

1. disable the "Pd time" feature by default
2. add a big fat warning to the help patch

IMO, the feature is so dangerous and brittle that I would just remove it alltogether. If you want to reduce jitter for bundle scheduling, there are better ways to achieve this, see for example #5 (comment)

[Spacechild1]

Side note: I think the actual solution to the time stamp problem is to calculate it on the Pd side and expose it to externals, see pure-data/pure-data#2803

[danomatika]

Ooof ouch, yeah, I also agree it shouldn't use logical time by default.