This means that if no s parameter is given by a pattern, no OSC message will be sent. In the above example, the first parameter called 's' doesn't have a default, indicated by the keyword Nothing. Each argument is given as a 'tuple', containing the name of the parameter, and its default value. Then you list the message arguments, in order. To define the OSC structure, you start with OSC, followed by the OSC 'address pattern', in this case '/play'. The argument list approach is most common. Either as an argument list, or as name-value pairs. There are two ways to structure the OSC messages that Tidal sends. It's worth first spending a bit of time familiarising yourself with the OSC spec. Next, define the structure of the OSC message. You have to explicitly include these in the argument list of your osc format (see later for an example). Pre MessageStamp: as with BundleStamp above, but the timestamp is added to the OSC message itself, filling in the two integer fields 'sec' and 'usec'. This is more work for the target, but is potentially more accurate than the above, as potential network/processing jitter can be avoided. Tidal doesn't attempt to send them out with 'correct' timing, instead the target is expected schedule them accurately. The bundled messages will be sent out once per frame in batches, but ahead of time (according to the oLatency configuration value). Pre BundleStamp: sends each OSC message wrapped in an OSC 'bundle' with a bundle timestamp.

This is the simplest approach, that will work well in most cases. Live: causes Tidal to schedule messages so that they are sent out at the 'right' time, minus the oLatency value. The scheduling method for oSchedule can be one of:

Open sound control windows