fbpx
Skip to main content

MIDI-CI: Handling Multiple Initiators and Responders

Andrew Mee

Read More

Developer Design Options for Devices based on MIDI-CI v1.2

by Andrew Mee and Mike Kent

MIDI-CI defines how a device can use a bidirectional connection to discover details of another device. In some cases a device might be connected to more than 1 other device which also uses MIDI-CI. 

This article discusses device design strategies for handling MIDI-CI functions when the current connections are more than one to one. For this purpose we present two terms which are not defined by MIDI-CI but used only to explain design strategies in this article.

  • Session: A binding between 2 devices created by ongoing communication of MIDI-CI Transactions. Generally established while using a Profile, a PE Resource, or a Process Inquiry.
  • MIDI-CI Instance: Inside a MIDI device, a set of information stored about another connected MIDI-CI device, with the MUID of the connected device as the core property.

A Session often requires a MIDI-CI Instance in the Initiator and sometimes in the Responder.

MIDI-CI defines that a Transaction is an inquiry sent by one MIDI Device and a reply returned by a second MIDI Device. Single Transactions do not establish any kind of Session. Therefore, and in most cases, the following Transactions do not require a MIDI-CI Instance in a device.

  • Discovery
  • Profile Inquiry
  • Inquiry: Property Exchange Capability
  • Inquiry: Process Inquiry Capability

Some MIDI-CI mechanisms rely on an ongoing set of Transactions. These mechanisms probably require a device to consider those mechanisms as establishing a kind of Session between two devices. One or both devices might require an internal MIDI-CI Instance. Such mechanisms are:

  • When 2 Devices agree to use Process Inquiry, the Initiator usually creates a MIDI-CI Instance. The Responder may not need a MIDI-CI Instance.
  • When two Devices agree to use a Profile, the Initiator usually creates a MIDI-CI Instance. The Responder may not need a MIDI-CI Instance.
  • When 2 Devices agree to use a Property Exchange Resource, the Initiator usually creates a MIDI-CI Instance. The Responder usually only needs a MIDI-CI Instance if it agrees to serve subscriptions.

Do Not Create a MIDI-CI Instance Unless Necessary

Note: Devices should send the associated reply to these inquiries, even if the Device cannot create a new MIDI-CI Instance:

  • Discovery -> Reply to Discovery
  • Profile Inquiry -> Reply to Profile Inquiry
  • Inquiry: Property Exchange Capabilities -> Reply to Property Exchange Capabilities
  • Inquiry: Process Inquiry Capabilities -> Reply to Process Inquiry Capabilities
  • Inability to create a new MIDI-CI Instance should not cause sending a NAK.  (There may be other reasons to reply with a NAK.)

Sending a reply to these inquiries only requires the Responder to store information about the inquiry, including the MUID address of the Initiator, until the Responder has sent a reply.

Example Implementation Scenarios for Devices with Limited Resources

Some devices have limitations of memory and processing power. Typically, hardware devices have more limitations than software applications running on a computer. Following are 2 examples of potential issues, each with several proposed solutions.
Some of the solutions provided are for normal MIDI-CI mechanisms, but some are provided to deal with error cases such as a device which becomes disconnected without sending an Invalidate MUID message.

Example 1: Responder Device Restricted to Supporting Single MUID

In this example, a limited hardware device which acts only as a Responder is connected to a computer with the potential for multiple MIDI-CI Initiators. The Responder only has enough memory to store a single MIDI-CI Instance.

There are potential issues which could occur:

  • If the Responder creates a MIDI-CI Instance for the first Initiator which requests a connection, that could “lock” the Responder against other MIDI-CI Instances. The Responder might NAK other Initiators. The Responder may not be able to determine that a different Initiator is preferred.
  • If an Initiator “goes away” without sending invalidate MUID, Responder is unable to see that Initiator no longer exists. i.e. no clean-up
  • Responder has limited methods to verify Initiator still exists.

Responder Solution 1: Device Does Not Create a MIDI-CI Instance to Store Initiator MUID/Info

A simple MIDI-CI Device (with restricted memory), acting as a Responder, probably does not need to store the Initiator MUID and associated information. Instead, Responder might:

  • Respond to request from the Initiator using the Source MUID from the request as the Destination MUID in the reply. Then forget the MUID of Initiator.
  • Only Send out Notifications using the Broadcast MUID. e.g. Profile Enable Message.

Responders using this method do not need to track active status of Initiators. No MIDI-CI Instance has been created so no “clean-up” needed.

Note: This solution is not applicable in a few cases (because in these cases the Responder probably needs to create a MIDI-CI Instance):

  • The Responder wants to accept Property Exchange Subscriptions requests.
  • An active Profile requires the Responder to send notifications to an Initiator using a non-Broadcast address.
  • The Responder is expected to make a Profile Details Inquiry of the Initiator more than once after a Profile is enabled.
  • More than 512 bytes of Sysex data is needed to be sent on any given MIDI-CI message.

However, many Responders will work well without any of the mechanisms listed above.

Responder Solution 2: Device Only Stores Minimal Initiator Information When Absolutely Needed

Responder should only store the data which is absolutely needed for each MIDI-CI Instance.
There is a lot of data provided in MIDI-CI messages, much can be “thrown away”. Some examples of data which might not need to be stored:

  • Manufacturer, Family, Model Id’s, and Version are often not needed. 
  • Devices that are only working with Profiles do not need to store PE data.
  • Max Sysex only important if you are going to use messages greater than 512 bytes

A clean-up mechanism to remove inactive MIDI-CI Instances should be considered when this solution is used.

Example Device: The MIDI Association developed a prototype to test and demonstrate Property Exchange. The device has a total memory of only 96Kb.
The device only creates a MIDI-CI Instance when a Subscription is requested. When a change occurs, the device looks through the list of MIDI-CI Instances to find current subscription(s), and sends out the Property Exchange Subscription notification.
If Property Exchange Subscription Notification is sent and no Reply to Subscription Message is received, a clean-up process is initiated for that MIDI-CI Instance.

This method keeps memory use to a minimum. This prototype can manage 25 unique Subscriptions in fixed memory, using less than 256 bytes.

Responder Methods of “Clean-up”:

  • Do Not Create MIDI-CI Instance – no need for clean-up (suitable for many devices but not in all situations, see Responder Solution 1)
  • Use MIDI-CI Messages sent directly to Initiator (not Broadcast) and check for Reply. If there is no reply then it can be considered inactive and removed from memory.
  • Resend Discovery. If an existing Initiator does not respond it can be considered inactive and removed from memory.
  • Receive Invalidate MUID message containing Initiator MUID.

Example 2: Initiator Device Discovers many Responders available for Communication

In this example, a limited hardware device which acts as an Initiator is connected to a computer with the potential for multiple MIDI-CI Responders. The Initiator has limited memory for MIDI-CI Instances.

There are potential issues which could occur after the Discovery Transaction:

  • The Responder may already have a MIDI-CI Instance for another Initiator (this may include inactive Initiators) and may NAK a new Session. 
  • The Initiator may have “choice paralysis”, as such the Initiator may have difficulty automatically deciding which Initiator  is best for the user.
  • The Initiator may be unaware if a Responder disappears in the future.

Solution: Initiator and Responder Implementations

Responder

  • Should support multiple Initiators. As Responder is on a computer, memory for multiple MIDI-CI Instances is not an issue.

Initiator

  • Offer a choice to the user for selecting which Responder to communicate with.
  • Use Clean-up methods (below) to remove inactive Responders.

Initiator Methods of “Clean-up”:

  • If the device receives an Invalidate MUID message containing Responder MUID, then remove the MIDI-CI Instance.
  • Resend Discovery to confirm that the Responder is still active. If a prior existing Responder no longer replies, the Responder can be considered inactive and removed from memory.
  • A Session and MIDI-CI Instance are usually needed to work with a Responder for one of 3 “P”s: Profile Configuration, Property Exchange, or Process Inquiry. Send a Profile Inquiry, PE Capabilities, or Process Inquiry Capabilities message periodically as a “Ping” to confirm that the Responder is still active.

Note: There is usually no need to create a MIDI-CI Instance for any device which does not support one of the 3 “P”s.