Guidelines for use of OSC

This book's child pages are for experienced OSC users and developers to write guidelines about practices they recommend for use of OSC.

Guidelines for designing OSC Address Spaces

(All of the following are Matt Wright's personal opinions; "your mileage may vary".)

The best guideline is to look at OSC Schemas that other people have done and to base your Schema on something that already exists, if possible.

Another big one is to use the hierarchical address space to group together features that "go together."

If there are multiple copies of something (synthesis voices, rows of buttons, etc.), consider how your choice of numbering scheme will interact with OSC's pattern-matching features:

It's much easier to say /voices/[7-9] than /voices/{8,9,10}, so that's why they should all have the same numbers of digits.

Base ten might not be the best, because both /voices/*3 and /voices/3* are easy, so maybe you'd rather think about 8 groups of 8 than 10 groups of 10.

Generally, there's a tradeoff between longer and more self-documenting names versus shorter, more cryptic, and more efficient names. Since OSC Strings are padded to a multiple of 4 bytes in length (including the null termination character), keep in mind that, for example, "/foo", "/food", "/foods", and "/foodsh" will all use the same number of bytes when represented in OSC.