playground:ios_core_midi_connections_explained

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== iOS Core MIDI Connections Explained ======
It can be confusing understanding how to connect apps via MIDI in iOS. This article attempts to explain the concepts, common misconceptions, and troubleshooting techniques. The article is mainly focused on connections //between// apps, but also has a section about MIDI concepts within some common hosts.

<WRAP box>
NOTE: This article is mainly concerned with Host and IAA apps. The rise of AUv3 apps has thankfully simplified MIDI routing a lot within hosts so not as much needs to be said.
</WRAP>

(Work in progress)
===== Concepts =====
Core MIDI is Apple’s name for its  MIDI routing mechanism. Understanding certain concepts about Core MIDI can go a long way toward understanding how to connect things.

==== Types of connections ====
There are multiple types of connections to consider, each with their own concepts.
  * App to App
  * Hardware
  * Network Session
  * BlueTooth

=== App to App ===
== Ports and Virtual Ports ==
The most important concept to understand when connecting apps is that of virtual MIDI ports. This is how apps identify MIDI end points. Virtual ports that send MIDI out are //source// ports, those that receive MIDI are //destination// ports. Some apps name source or destination ports differently, most don’t.

Hardware, BlueTooth, and the Network session are ports as well. They can be senders, receivers, or both, depending on the hardware or apps using them.

== App Source vs. Destination ==
Ignoring hardware, BlueTooth, and the Network Session for now, there are multiple ways apps can receive MIDI from other apps.
  - **Select which app(s) to listen to**\\ In the MIDI settings of apps that work this way, there should be a list of apps currently advertising themselves, from which you can select one or more apps to listen to. Some apps allow multiple selections, some don’t. Some show only currently running apps, and some remember apps whether they’re running or not.
  - **Listen for any incoming MIDI directed to them**\\ These apps generally advertise their “destination” virtual ports so that apps can select to send to them. To connect this way, go to the sending app MIDI settings and select the app you want to send to.
  - **Listen to all MIDI Input**\\ This one is bad. The app listens for any MIDI input that isn’t directed to a particular receiving app. Since hardware controllers have no way of selecting to which app they send, MIDI from //any// hardware will be picked up by such apps. Some make it even worse by not even providing a MIDI channel selector. Korg Module is an infamous example of this. It will pick up any and all hardware MIDI input and //there’s nothing that can be done to overcome this//.
  - **Combinations of the above**\\ Yes, sometimes apps can do it more than one way. For instance, in AUM, one can select an external app to listen to, or one can select “AUM Destination” to listen to. More on this later.

Apps can //send// MIDI to other apps in a few ways too.
  - **Select which apps to send MIDI to**\\ In the MIDI settings for there should be a list of app ports to send to. These apps are advertising their virtual destination ports. Some sender apps will allow multiple destination selections, some will not.
  - **Send all MIDI out on the app’s own virtual MIDI port**\\ Such apps may not have a MIDI output setting at all. Instead, they will show up in the available MIDI inputs list of apps that work that way (see #1 above).

=== Hardware ===
=== BlueTooth ===
=== Network Session ===
==== MIDI Clock ====


===== Common Misconceptions =====
Certain things about Core MIDI are unintuitive to some people. Getting past these also helps to reduce problems.

**Each app should be pointed to the other**

It seems natural when connecting two apps to set the second as the output in the first app, and the first as the input in the second app. **//But this is wrong//**. Remember about virtual ports? Let’s say App A has a virtual port called “App A MIDI” and App B has one called “App B MIDI”. If App A is sending to App B MIDI port, then generally App B will not need any setting at all. But, if it does, it needs to be set to listen to **//its own//** virtual MIDI port, which is actually named App B MIDI. On the other hand, if App A just sends out MIDI over its own virtual MIDI port, then App B should be set to listen to the port named App A.

So, the basic rule of thumb is: **//If you have to make settings in both apps, make sure the port is the the same in both apps.//** For example, if sending to Gadget from AUM, set AUM’s output to Gadget, and Gadget’s input to Gadget. Or, if sending KB-1 to AUM, you might set KB-1 to Virtual Output (KB-1’s own Virtual Midi port). In this case, you would set AUM to listen to KB-1.

** Misconception #2 **

** All apps work the same **

There is little to no consistency between MIDI implementation from app to app. Some apps publish a virtual port, others don’t. Some send and receive, some send or receive only. Only some respond to MIDI clock and/or other messages. Some have fixed cc number assignments to controls, and others have the ability to map any cc to each control through MIDI learn. Each app is a one-off situation that must be discovered.

==== Host and App Inconsistencies ====
==== MIDI Clock vs. Link ====

===== Common Issues and Troubleshooting =====

===== MIDI Within Specific Hosts =====
==== AudioBus ====
==== AUM ====
==== Ape Matrix ====
==== Auria Pro ====
==== Cubasis ====
==== NanoStudio 2 ====

===== Workarounds =====