The Protocol

Message structure of the CopperLan protocol

The messaging structure is based on a typical opcode/data format with some improvements: the overall message is made of mutiple opcode/data pairs; the message length is variable and is known beforehand by a length declaration. This simplifies the parsing and merging of messages.

Variable geometry allows the creation of agglutinating commands (e.g. modifying a setting together with a note event message). This provides an implicit timing relation to all information within a single message.

Moreover, messages have a set of predefined variations; these are used to adjust/extend the meaning of a basic message (e.g. a preset call message can become a preload message; eventually followed by a single broadcast triggering for all to apply)

Aspects of the protocol regarding the message flow

• Directed messages are multi-addressed (to maintain the MIDI layering capability, and allow multiple destination feedback)
• At the transport level, the CopperLan protocol contains messages that never translate outside the VNM, these being reserved for the network management.
  A special encoding scheme avoids wasting possible messages from the application level of the protocol as seen by the host CPU.
• Non-real time messages work on a handshake basis. This automatically gives priority to real-time messages when the flow density increases.
  Additionally there is an error-correction scheme and an acknowledge mechanism.

The multi-leveled addressing of messages

Thousands of devices There are no channels sensu stricto in CopperLan. Devices have a 64-bit unique ID. Devices are declaring themselves to the network and their abstract numbers are hidden behind plain names for the user to see A device/sub-device organization allows a tree-based architecture which is intuitive to navigate and edit

Modifiers & Selectors Modifiers and Selectors are the messages for setting parameters. Modifiers are also used for real-time performance and modulation. There are 65536 Modifiers There are 65536 Selectors While Modifiers deal with the expression of a magnitude (level, angle, percentage, etc.), Selectors are used for non-consecutive values (waveform selection, mode switch, etc.) MIDI controllers are included into these Modifiers and Selectors, simplifying the interoperability of hybrid setups. Indexing The allocation of Modifiers is done according to a matrix; this avoids reserving ranges of controllers when more than one target of a given type is required (e.g. numerous wave generators in additive synthesis). Such matrix leads to an elegant orthogonal organization of parameters. An index field, enriching the message, points to the nth unit of a given type. Indexing allows up to 65534 additional units for each Modifier and Selector, leading to a grand total close to 233 different parameters for each target device or sub-device.

Messages are multi-addressed, simplifying the recording

Recording capability is achieved according to a revolutionary principle: the recording targets now have a target ID along with a recording flag. This simplifies and expands the typical approach.

Thanks to the multiple addressing in messages, it is possible to direct data to one or more recording devices by defining the destination track(s).
This also prevents self-recording.

Thousand clocks spread in 4 families

• Simultaneous timing references go beyond the usual single global clock reference.
• Multiple types of timing references are used for different purposes.
• Timing references can be attached to any cyclic event source or target (e.g. linking an arpeggiator to an LFO between two unrelated devices).

CopperLan's compliance to MIDI

Knowing that CopperLan should coexist with MIDI, the need for a smooth integration was part of the initial requirements.

CopperLan has been carefully crafted to be technically compliant with MIDI.

The CopperLan protocol is defined so that every MIDI message can exist as a particular variation of a richer CopperLan message, offering a reliable one-to-one conversion.