unpackOSC handles timestamps, but also outputs each message immediately, making the delay time available through the right outlet.

This naïve approach to timestamps will work only if there is ever only one pending message. If the sender spits out 5 OSC messages with different future timestamps, only the last message will be available in [list store].

So that's the wrong approach.

[pipe] could help, but you have to be certain that every incoming message will match the [pipe] object's predefined format, which can't be guaranteed. (So there is a need for an arbitrary-format [pipe]. Does such a thing exist?)

Or, has anyone else tackled this problem? I could do it by adding the delta to a current-time counter and scheduling each message in my tick-scheduler abstraction, more complexity than I'd have expected for a relatively basic function.

hjh

@ddw_music said:

there is a need for an arbitrary-format [pipe]. Does such a thing exist?

maybe [text sequence]

unpackOSC handles timestamps, but also outputs each message immediately

Ports and networking introduce jitter: the stream out of [netreceive] jitters. This is where timestamps come in handy:
Buffering, and comparing timestamps to a steady (and delayed) clock eliminates jitter.

@lacuna said:

@ddw_music said:

maybe [text sequence]

Could work -- would have to manage the order carefully (which my tick-scheduler does internally).

unpackOSC handles timestamps, but also outputs each message immediately

Ports and networking introduce jitter: the stream out of [netreceive] jitters.

This I understand -- it occurs to me that the OSC handler object could take care of the delay internally, without requiring the user to mess with it.

hjh

As a test case to illustrate what I mean, I'll use SC to generate five messages with randomly shuffled timestamp offsets.

n = NetAddr("127.0.0.1", 57120);

OSCdef(\x, { |msg, time| [time, msg].postln }, '/test');

(
((1..5).scramble * 0.1).do { |offset, i|
    n.sendBundle(offset, ['/test', i, offset])
};
)

[ 1487.2653768999, [ /test, 0, 0.10000000149012 ] ]
[ 1487.4653768998, [ /test, 1, 0.30000001192093 ] ]
[ 1487.6653769, [ /test, 2, 0.5 ] ]
[ 1487.3653768999, [ /test, 3, 0.20000000298023 ] ]
[ 1487.5653768999, [ /test, 4, 0.40000000596046 ] ]

The [text sequence] approach I believe would be to add into the [text] repository, subtracting the incoming message time from the last time in the repository and using that as a delta. But in this case, some of the deltas would be negative.

"When is this ever going to happen?" You can't be sure it won't. You could have one thread sending immediate messages (offset = 0) and another thread sending timestamped messages. An immediate message quickly following a timestamped message could have a negative delta.

So you have to be able to handle it.

A priority-queue-based scheduler can do this.

print: 2178.25 /test 0 0.1
print: 2478.18 /test 1 0.4
print: 2378.15 /test 2 0.3
print: 2578.14 /test 3 0.5
print: 2278.13 /test 4 0.2
sched_out: 2178.25 /test 0 0.1
sched_out: 2278.13 /test 4 0.2
sched_out: 2378.15 /test 2 0.3
sched_out: 2478.18 /test 1 0.4
sched_out: 2578.14 /test 3 0.5

The messages are received in index order (0, 1, 2, 3, 4) but come out of the scheduler in time order, with the correct time deltas.

(Also, continually adding to a text repository for [text sequence] would grow but never shrink. [tick-scheduler] does use [text] internally, but reuses rows after they have been output, so memory consumption should be minimal.)

hjh