Model

Most systems in the domain use a fairly uniform data model. The main differences are in levels of support, so not all systems support, for example, nested objects, or tracks independent of channel paths. Most mainstream uses can be accomodated by supporting a subset of the features described here.

The mains constituents of the model are:

• Song - This encompasses all the other objects. Despite the name, there is nothing to exclude non-musical projects such as audio mixing, soundtrack work, sound design, etc. Applications with difference terminology sometimes refer to this as a Session, Project, or Composition.

• Channels - Paths. Need associations with Routing and I/O.

• Tracks (non-timeline related object groupings)

• Parts (timeline objects, preferably supporting recursive composition. Sometimes referred to as Regions)

• Events (the basic constituents contained within a Part)

The exact API is implementation specific, but the system supports a set of object types, object properties, and method types:

    OBJECT_TRACK,
    OBJECT_AUDIO_TRACK,
    OBJECT_MIDI_TRACK,
    OBJECT_CHAN,
    OBJECT_PART,
    OBJECT_AUDIO_PART,
    OBJECT_MIDI_PART,
    OBJECT_EVENT,
    OBJECT_MIDI_EVENT,
    OBJECT_RAW,
    OBJECT_STRING,
    OBJECT_ROUTE,
    OBJECT_FILE,
    OBJECT_LIST,
    OBJECT_SONG,
    OBJECT_TRANSPORT,
    OBJECT_AUTOMATION

    NAME
    STIME
    LENGTH
    HEIGHT
    INSET
    END
    MUTE
    ARM
    SOLO
    SDEF

    PLAYBACK_LEVEL,
    PLAYBACK_PAN,
    PLAYBACK_DELAY_MU,

    PLUGIN_SELECT,
    PLUGIN_BYPASS,

    CHAN_LEVEL,
    CHAN_PAN,

    TRANSPORT_PLAY,
    TRANSPORT_STOP,
    TRANSPORT_REW,
    TRANSPORT_FF,
    TRANSPORT_REC,
    TRANSPORT_LOCATE,
    TRANSPORT_CYCLE
    TRANSPORT_LOCATOR

    AUTOMATION_PT

    TEMPO
    HISTORY

    AYYI_NEW
    AYYI_DEL
    AYYI_GET
    AYYI_SET
    AYYI_LOAD
    AYYI_SAVE
    AYYI_SPLIT

media types:
    AUDIO
    MIDI

The system is deliberately flexible and allows for the addition of new types. The implementation decides what combination of types are valid for each class, eg supporting the Tempo property for a Part isn’t normally allowed, but could conceivably be useful. Responsibility for compatibility is left to the ‘edges’.

So objects do not publish their interface at runtime. Runtime introspection is only available by trying an operation and seeing if it fails.

In addition, some other formats are standardised, such as time positions, gain formats etc.

Time format used is currently either uint32_t samples, or struct {beats, sub-beats, ticks}

It is not envisaged that application code will want to directly use the above low-level type enumerations. Library code should abstract this to conform to the normal conventions of the chosen platform.