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 Device addressing system (64-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.

  • 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

    alt

    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.

    alt
  • 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.

Web Links

Facebook Google+

Visit our forum

Give us your feedback and share your knowledge with the community

Forum

Get the Newsletter Stay informed !

captcha