How does the cycle parameter on the OSC message get internalized by SuperDirt?

Innards
1

Good morning all,

I've been spending the last few weeks reading the code, doing some tests and basically getting my head around how Tidal is working under the hood.

At the end of the day, the glue between the Supercollider instance and the Tidal instance is osc messages, and it looks like there is an osc message sent for each event on the tidal side.

That is, if I take the pattern from the docs:

d1 $ sound "[bd bd bd, sd cp sd cp]"

And I add a msg.postln to the NetResponders.add block in SuperDirt.sc (approximately line 224), I can see that I receive two osc messages for the same cycle offset:

[ /play2, cps, 0.5625, cycle, 251.0, delta, 0.59259271621704, orbit, 0, s, bd ]
[ /play2, cps, 0.5625, cycle, 251.0, delta, 0.44444417953491, orbit, 0, s, sd ]

I would think that in the SuperCollider code there would be some quantization against this cycle, and I do see that there are two scripts called "sync-to-tidal", but I don't see these being used.

Can someone fill me in on how this is working ? Is there quantization ? I'm pretty sure I'm missing something and I want to be sure I understand it fully as I'm building up the code for my first composition.

thanks!

2

I believe the cycle parameter is actually very rarely used. OSC messages (at least those containing OSC Bundles, which is true for anything Tidal sends to SuperDirt) have timestamps, which I don't believe you're printing out above. Tidal does all the calculating of these when putting together the message, and then Supercollider automatically just does its best to respond at the appropriate time. You don't actually see the code for this in SuperDirt because the basic OSC support in Supercollider already handles execution timing.

3 Likes
3

that makes sense ! The OscFunc's method signature has:

OSCFunc({ |msg, time, tidalAddr|

I assumed the msg would contain the appropriate quantization, but if it's "time", that makes a lot more sense. From what I could tell doing an analysis of the timing, everything seemed pretty bang on, but it's good to have confirmation this is all tidied up on the language side. Gives me confidence to start pushing out sysex and midi messages to my synths.

Thanks!