<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Both of you are right.</p>
    <p>The basis for OSC timetags are of course the (NTP) system time,
      because that's usually the only shared time source between
      different apps.</p>
    <p>However, if you schedule several events in a DSP tick, you don't
      want to get the current ystem time for each event, because this
      will cause unnecessary jitter.</p>
    <p>What you can do instead is get the system time *once* per DSP
      tick and use that as the basis for scheduling/dispatching events
      within the tick. This is more or less what Supercollider does,
      BTW.</p>
    <p>However, since Pd DSP tick computation itself can be very jittery
      for large hardware buffer sizes, this is not sufficient. There are
      basically two solutions, afaict:</p>
    <p>a) use some dejittering/smoothing algorithm. Scsynth, for
      exampple, uses a DLL to filter the system time.<br>
    </p>
    <p>b) only get the system time for the very first DSP tick and for
      all subsequent DSP ticks increment by the *logical* block
      duration. This allows for sample accurate *relative* timing, but
      the absolute timing can suffer from clock drift. This is the
      default behavior of Supernova and some people actually experience
      problems in longer performances.<br>
    </p>
    <p>---</p>
    <p>Generally, time synchronization between apps is a fundamental
      (unsolved) problem in computer music. See the following discussion
      for a starter:
      <a class="moz-txt-link-freetext" href="https://github.com/supercollider/supercollider/issues/2939">https://github.com/supercollider/supercollider/issues/2939</a>.</p>
    <p>Christof<br>
    </p>
    <div class="moz-cite-prefix">On 18.04.2021 22:32, IOhannes m zmölnig
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:28e5e8b9-64b4-ef5e-4f3b-f27cc175efc2@iem.at">On 4/18/21
      17:06, Martin Peach wrote:
      <br>
      <blockquote type="cite">On Sun, Apr 18, 2021 at 6:06 AM IOhannes m
        zmölnig <a class="moz-txt-link-rfc2396E" href="mailto:zmoelnig@iem.at"><zmoelnig@iem.at></a> wrote:
        <br>
        <blockquote type="cite">
          <br>
          I don't really like the timestamp implementation in mrpeach
          (as it uses real time, rather than logical time), but better
          this than nothing...
          <br>
        </blockquote>
        <br>
        Logical time timestamps would only be accurate inside of the Pd
        <br>
        instance.
        <br>
      </blockquote>
      <br>
      i tend to disagree.
      <br>
      there are basically two use-cases for timetags:
      <br>
      - reducing jitter when synthesising events on the receiver
      <br>
        e.g. i want to trigger a drum-synth exactly every 100ms
      <br>
      - reducing jitter when analysing events from the sender
      <br>
        e.g. i want to measure the period between two mocap frames
      <br>
      <br>
      neither of these use-cases warrant system time.
      <br>
      <br>
      here's a real world example:
      <br>
      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.
      <br>
      <br>
      if i codify this jitter in the timestamps, then any law abiding
      receive will have to do their best to reproduce this jitter.
      <br>
      <br>
      what is the value in that?
      <br>
      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.
      <br>
      <br>
      <blockquote type="cite">but it would not conform to
        <br>
        any OSC specification.
        <br>
        <br>
      </blockquote>
      <br>
      i checked and double checked the specs but could not find anything
      about this.
      <br>
      where do you get the idea that the OSC specs mandate wall clock
      time?
      <br>
      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)
      <br>
      <br>
      > It could be added as an option
      <br>
      <br>
      a flag or similar would be great.
      <br>
      there probably are use-cases where real time makes sense, why not
      be able to cater for both.
      <br>
      <br>
      f,dst
      <br>
      IOhannes
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
    </blockquote>
  </body>
</html>