The MUS Standards (0.0.1)

A collection of standards for interchange of semantic music data.

software
library
music

The two most important formats in this project are MUSi (Musical Instrument) and MUSx (Musical Excerpt), both which go hand in hand.

This library was developed for Overtone but may be used for any purposes!

MUSi (Musical Instrument)

A simple sample library, similar to SoundFont, that can generate audio from music using a format for arbitrary semantic music exchange (MUSx).

Each instruments carries:

The MUSx (Musical Excerpt) format

An excerpt of musical data that will be played by a MUSi (Musical Instrument) or another MUS-compliant plugin.

This format contains a bunch of notes in a sorted buffer, such that they can be seeked efficiently using binary search.

Each note has eight inherent parameters:

It additionally contains "notation" — time-bound and note-bound markers, each which add additional information to be interpreted by the MUSi. These markers are also arbitrary. They may look something like this:

std::staccato, std::chord_stagger, std::artificial_harmonics.

Playback

When you play a song in Overtone, the play head scans the notes from left to right and emits note events in real time. This is how MUSi plays excerpts, and also how it works if you're recording an excerpt using a MIDI controller.

But the instruments don't need to react "in real time" to events, since they do get a view into the currently-playing excerpt and are able to look ahead into the future.

This might be useful for certain instruments — the ability to generate sounds for blocks of music instead of in a note-by-note basis.

Standard Markers

For the benefit of the community, here is a relation of standard markers your instruments should follow. This doesn't mean every instrument should do something for every marker, but if you're making an instrument that provides any of these functionalities, you should consider using one of these names to tag it.

This is the standard used by Overtone plugins made by me!

A short aside on naming convention

The names included were chosen to be as general and applicable as possible, while still remaining understandable. Unlike a program like MuseScore Studio, which has a focus on the aesthetics of notation (and thus has many redundant ways of notating the same concept), we prioritise high interchangeability instead of specificity.

Then, it's up to the GUI that's editing a .musx file to render the notation appropriately according to the user choice and the current instrument. For example, a classical composer might prefer to read pitch_slide as "Portamento", while an EDM composer might prefer "Slide".

Lastly, it's convention to "namespace" strings to the standard that defined them, such that you know exactly what piece of technical information someone is refering to. So, if a marker here is called vibrato it'll be referred to as std:vibrato, as opposed to some third party's marker that would be called thirdparty:vibrato and could potentially work differently;

Note markers

Markers that modify or add effects to a single note or a set of notes.

Tip

All markers that affect "a single note" can be applied to multiple notes at once, but some markers only make sense when applied to several notes, like legato.

Articulations

Pitch

Dynamics

Ornaments

Voice markers

Markers that affect the song itself, at least for a specific voice.

Timeline markers

Markers that are affect or are bound to the timeline.

These markers are seen by MUSI during playback, but most instruments aren't supposed to react to the tempo anyways. Instead, these are to be interpreted and played back by the MUSI's host.

Location

Song pace