A project log for n00n - Real Time Music Sensor Streaming Protocol

MIDI is so outdated, welcome to the 20s and the 16-bit world !

yann-guidon-ygdesYann Guidon / YGDES 06/23/2023 at 22:510 Comments

Timestamps have been discussed in the logs 2. More drafting and 9. High-resolution timestamps. They should be reasonalby precise, useful and convenient. For example: time arithmetic is straight-forward, shifting a stream in time is a simple 32-bit addition with saturation.

This is different from many timing systems, such as sample-based timing which is too dependent of sampling rates, and n00n is meant to mix several streams with possibly irregular sampling rates. A fractional Herz system is the easiest common denominator and rounding to the next few points does add very minimal jitter.

65536Hz is also more fine-grained than the usual 44100Hz and 48000Hz sampling rates so the stream can be synchronised to within one sample.

There are two special values :

So there are two ranges of 32787 seconds, that's 546 minutes or a bit more than 9 hours, which should be long enough for long outtakes, rehearsals, you name it. And if it's not enough, it can be doubled because negative timestamps are totally fine, so the recording could be started from (0x8001 : 0000) and proceed up to (0x7FFF:FFFF). If the recording is longer than 18 hours and 12 minutes, the counter overflows to (0x8000 : 0000) to signal an invalid timestamp.

Here are relevant Packet types:

-1 : Tick

It's just a header that is passed along the chain to synchronise all the other clocks downstream. No data payload. Upon reception :

If no tick received within 1 second, send your own tick (8-16Hz ?)

-7 : JUMP

This special packet could be sent to warn about the shift to a different timestamp range, backwards or forward. The local timestamp counter is reset to a new value, but DPLL parameters should not be changed. Could be used to extend the duration of a recording or stream.