Differences

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

--- 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 12:47] – [Types of connections] 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.
-  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 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)
@@ Line 17: / Line 19: @@
 === App to App ===
 == 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.
@@ Line 23: / Line 25: @@
 == 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 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 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//.