playground:ios_core_midi_connections_explained

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
playground:ios_core_midi_connections_explained [2019/05/13 11:20] – [iOS Core MIDI Connections Explained] wimplayground:ios_core_midi_connections_explained [2019/05/13 13:26] (current) wim
Line 2: Line 2:
 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. 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 indent 95%>+<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. 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> </WRAP>
Line 19: Line 19:
 === App to App === === App to App ===
 == Ports and Virtual Ports == == Ports and Virtual Ports ==
-The most important concept to understand when connecting apps is that of virtual MIDI ports. These the ways 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.+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. 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.
Line 25: Line 25:
 == App Source vs. Destination == == App Source vs. Destination ==
 Ignoring hardware, BlueTooth, and the Network Session for now, there are multiple ways apps can receive MIDI from other apps. 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 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.+  - **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 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//.   - **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//.
Line 41: Line 41:
  
 ===== Common Misconceptions ===== ===== Common Misconceptions =====
-Certain things about Core MIDI are unintuitive (to some people). Getting past these also helps to reduce problems.+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.
  
-==== “From” and “To” connection confusion ==== 
 ==== Host and App Inconsistencies ==== ==== Host and App Inconsistencies ====
 ==== MIDI Clock vs. Link ==== ==== MIDI Clock vs. Link ====
  • playground/ios_core_midi_connections_explained.1557710438.txt.gz
  • Last modified: 2019/05/13 11:20
  • by wim