Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revisionLast revisionBoth sides next revision | ||
playground:ios_core_midi_connections_explained [2019/05/13 11:08] – ↷ Page moved from sandbox:ios_core_midi_connections_explained to playground:ios_core_midi_connections_explained wim | playground:ios_core_midi_connections_explained [2019/05/13 13:19] – [Common Misconceptions] 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, | It can be confusing understanding how to connect apps via MIDI in iOS. This article attempts to explain the concepts, common misconceptions, | ||
- | | + | <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. | ||
+ | </ | ||
(Work in progress) | (Work in progress) | ||
Line 17: | 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. | + | The most important concept to understand when connecting apps is that of virtual MIDI ports. |
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 23: | 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 |
- **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 39: | Line 41: | ||
===== Common Misconceptions ===== | ===== Common Misconceptions ===== | ||
- | Certain things about Core MIDI are unintuitive | + | 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 ** | ||
==== “From” and “To” connection confusion ==== | ==== “From” and “To” connection confusion ==== |