The Protocol
Overview
-
Protocol is open (allocation & extension)
Handling of streamed data (control, modulation, audio, video)
Handling of arbitrary data (binary blocks; manufacturer defined)
High resolution parameters
Time stamping (optional)
Multiple simultaneous timing references in different categories
Continuous fine pitch control (down to LFO range)
Simultaneous multiple data transfers
Implicit priority to real-time messages
Data querying system
Full translation of MIDI for perfect compatibility
Message format key points
-
Non-channel based addressing system (48-bit ID with automatic duplicate resolving)
Multiple-destination message format (1 to X)
Variable data word length (16-bit default to 128-bit)
Standardized data types (negotiated)
Message string formatting for implicit time relation
Multi-dimensional orthogonal addressing format easing the relation between rich product implementation and code efficiency.
MIDI compliance by design - one to one conversion principle
With a little help from my CHAI
The application code is never in charge of parsing and generating raw CopperLan message strings; the CHAI acts as an abstraction layer; interaction with CopperLan is only done through function calls.Structure
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)
Flow
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.
Addressing
The multi-leveled addressing of messages
Thousands of devices There are no channels sensu stricto in CopperLan. Devices have a 48-bit unique ID.
|
|
|
Modifiers & Selectors
Modifiers and Selectors are the messages for setting parameters.
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.)
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).
An index field, enriching the message, points to the nth unit of a given type.
|
|
Recording
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.
Timing
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).
MIDI
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.
