This is a guide aimed at providing some understanding about MidiBridge (and CoreMIDI) and how to use that knowledge to your advantage to interconnect apps, hardware and network sessions. Once the basics are covered, some step-by-step recipes for connecting up less obvious situations are provided.

Don't forget to turn on the 'Run in Background' option in the MidiBridge Preferences panel. This is off by default (and purposefully as we want the user to consciously be aware that they are allowing MidiBridge to keep on runnin' in the background)

The above applies to MidiBridge 1.3 and earlier. As of version 1.4, background processing is on by default (with a 15 minute idle timeout). The idle timeout value can be changed in the Options tab of the Preferences page. Setting it to 0 minutes turns backgrounding off completely.

First a little about CoreMIDI - port advertising

When an app runs it can register virtual ports in CoreMIDI that can be seen by other apps and on which other apps can send or receive events. There are two types of virtual ports (also known as endpoints) - sources and destinations. An app doesn't have to advertise its own virtual ports. It may choose to use the virtual ports of other apps instead. Here's something to remember:

Just because an app doesn't advertise any ports of its own doesn't mean that it can't be controlled via MidiBridge!

It just won't show up in:

The Interface Tab - Sources to the left of you, destinations to the right

This is the main tab in MidiBridge and from where you create connections between sources (inputs) and destinations (outputs). These ports are usually (but not always) in pairs and are one of the following type:

• A physical device port, like Midi Mobilizer I, SynthStation25...
• A CoreMIDI physical device port, like Midi Mobilizer II, iRig MIDI...
• The CoreMIDI network port (send/receive over wifi)
• MidiBridge's own virtual input/output ports that it advertises
• Virtual input/output ports advertised by other apps

MidiBridge can route events from any of these types to any other type, but the routing must be between a source and a destination from MidiBridge's point of view.

To connect source A to destinations B and C, you touch input/source port A on the left and then touch B and C on the right and green lines will be drawn between them to show they are connected. Touch port A again to tell MidiBridge you're done interconnecting to that port.

Here's a screenshot of MidiBridge with just about every type of port, connection and option set:

The above screenshot shows the following:

• A CoreMIDI network session is active (CoreMIDI Net in is yellow and the badge '1' on the Interfaces tab button is shown)
• Arctic Keys is up and running (Arctic Keys virtual ports shown)
• Midi Mobilizer I is present and a filter on its input is active (Midi Mobilizer ports shown and 'On' badge over filter button displayed on input port)
• MidiBridge's own virtual ports have been created and any events received from another app on the port MidiBridge will be passed to MidiBridge's own output (that other apps could be listening to) and the Midi Mobilizer's output. (Green lines going from MidiBridge to MidiBridge & Midi Mobilizer)
• Both MidiBridge and Arctic Keys ports are virtual ports (V-Cable symbol in port)
• Events received from the Midi Mobilizer's input will be sent to Arctic Keys and the Network session. (Grey lines running from Midi Mobilizer in to CoreMIDI net out and Arctic Keys out - they're grey, because currently the MidiBridge input port is selected for connection)
• You can fast switch straight to Arctic Keys by double tapping either its input or output port (Green double arrow in port)
• The Fast-switchable Applications Panel (As of version 1.4, this panel has been renamed from 'Compatible Applications') tells you that both Arctic Keys and MidiVision are installed on this device, but Loopy, NLog and ThumbJam are not (can't afford them). Touching Arctic Keys on the App Panel will fast-switch to Arctic Keys (since we know that is running). Touching MidiVision on the App Panel will launch MidiVision (not currently running, but installed). Touching any of the other apps in the App Panel (the unticked ones) will redirect you to the App Store to see if this app is of any interest to you. IMPORTANT: The Fast-switchable Applications panel is for fast-switching compatibility only. It is not an indicator of an app's MIDI connectivity.
• The App Panel can be dragged around the screen using the top bar of the panel. It can be dismissed by either pressing the 'X' at the top of the panel or touching the 'Applications' tab that has a badge marked 'X'.

To summarise:

An input from MidiBridge's view is a source of MIDI events from other apps, physical devices or the CoreMIDI network.

An output from MidiBridge's view is a destination that MIDI events can be sent to and can be other apps, physical interfaces or the CoreMIDI network.

Connecting different kinds of apps

Apps can either generate MIDI events, receive MIDI events or do both.

Apps fall into one or more of the following categories:

1. The app advertises its own virtual destination and accepts input from it. Examples: Animoog and Sunrizer.
2. The app advertises its own virtual source and writes events to it. Examples: Genome
3. The app doesn't advertise anything, but will read from all sources in the system, Example: SampleTank, GarageBand, Sunrizer XS
4. The app doesn't advertise anything, but will write to all destinations in the system. Example: SoundPrism Pro
5. The app only supports CoreMIDI networking (don't know of a current example, but early versions of Genome were like this and possibly NanoStudio)
6. The app advertises both a source and destination and reads/writes to those. Examples: Arctic Keys, NLog

Categories 1,2 and 6 are easy. You just connect your desired source/destination to the app's virtual port in MidiBridge and away you go. You may need to tweak something in the other app to tell it you want it to accept/send MIDI on its virtual ports (and tell it to continue working in the background).

Category 3 apps will not show up as a separate port in MidiBridge, but will read from MidiBridge's virtual output. To control these types of apps, just connect your desired source to the MidiBridge destination.

Category 4 apps are the reverse of category 3. They don't show up in MidiBridge but to use them as sources, you connect MidiBridge's virtual source(input) to the destination you want the events to go to.

Finally, category 5 apps require a little trick to make them work. In MidiBridge prefs, enter the word 'localhost' (without quotes) in the CoreMIDI Network Destination field and press the Connect button. You can also choose 'Connect Automatically' to re-start the connection when MidiBridge launches. Essentially you are hi-jacking the CoreMIDI network to run like a virtual port. To send events to the app that supports CoreMIDI network, you connect a source to the CoreMIDI net destination. Vice-versa for receiving events into MidiBridge from a category 5 app.

Application start/connect order

Now you know how to interconnect different types of apps, what about the order in which you launch the apps? It all depends upon when each app refreshes its view of the CoreMIDI world.

MidiBridge for example refreshes its view when it starts, when it is returned from the background, when a physical device is connected/removed, when a virtual port appears/disappears and when a CoreMIDI network session starts/stops. Basically all the time. What's more is that it will automatically re-establish any prior connections that you had set for that port. So far, so good.

Other apps may not refresh their view so much (some just at launch or need the user to manually refresh), so these are the rules of thumb when setting up your connections:

1. Launch MidiBridge first, so that its virtual ports are available if need be.
2. Launch category 3 apps (SampleTank, Sunrizer XS) so that they add MidiBridge's virtual destination to the list of ports they'll receive events on.
3. Launch category 4 apps (SoundPrism Pro) so that they add MidiBridge's virtual source to the list of ports they'll send events to.
4. Launch any other apps that advertise their own inputs or outputs.
5. Return to MidiBridge and make the connections (if you need to)

Unfortunately the world isn't perfect and sometimes even these rules are not enough. If it doesn't work, you may need to switch to certain apps as well to re-invogorate their engines. It's not exact and some trial and error may be involved.

Giving NanoStudio a virtual input
Sorry, as of Nanostudio 1.33, this trick no longer works. We have been in touch with Blip Interactive and hopefully will be able to work something out.

With a little trickery it is possible to use MidiBridge to give NanoStudio a virtual input so that it can be fed MIDI events from other apps. Please note that NanoStudio works in the foreground so any app that is to be used for driving it must be in the background. Note also, that the order of these steps is crucial to work around the way in which NanoStudio manages CoreMIDI.

1. First either reboot your device or terminate all MIDI related apps including MidiBridge and NanoStudio using the task manager. Also, unplug all physical MIDI devices.

2. Start NanoStudio first, as it resets the CoreMIDI networking facility in iOS which breaks any other CoreMIDI Network sessions. Setup your patch for Eden/TRG. Press the Home button and now launch MidiBridge.

3. In MidiBridge connect 'MidiBridge' on the left to 'CoreMIDI Net out' on the right and remove any other connections. Switch to the Preferences pane in MidiBridge and:
   • Ensure 'Run in Background' is 'on'
   • Enter the word 'localhost' (no quotes) in the 'CoreMIDI Destination Host/IP Address' field.
   • Press the 'Connect' button
   If all is well, there should be a little '2' over the Interfaces tab button and the CoreMIDI Net interfaces should be highlighted in yellow.

4. Optional If you want to also use a physical MIDI interface to control something, then do the following (if not, skip to next step):
   • Fast-switch to NanoStudio from MidiBridge's Applications panel.
   • Double-tap the Home button and switch back to MidiBridge
   • Now connect your physical MIDI interface and route it to MidiBridge on the right (if you also want to control NanoStudio externally) or to the other app which is controlling NanoStudio or even to FreEWI if you're mapping channels and the like. Remember that NanoStudio will not pick up the physical interface - which is what we want.

   The above steps don't really appear to do much, but they are crucial in cementing the fabric to make NanoStudio only respond to the (now looped back) network port without picking up the physical interface.

5. Now launch the app you wish to drive NanoStudio with. If it is OMAC fast-switchable then you can launch it from the Applications pane in MidiBridge. Configure the app to send MIDI events to 'MidiBridge' and start the app playing.

6. Double-tap the home button (or fast-switch if the app has OMAC fast-switching capability) and switch back to NanoStudio which should now spring into life!

If your favorite app isn't on the list, then please let the developer know. Full details on what they need to do are at the google group 'Open Music App Collaboration' in the 'Introducing OMAC Registry' thread here.

Video Help

The amazing people at iDesignSound, MusicApps.com.br and Tim Behrens have all made videos showing MidiBridge in action. Here are the links, and thanks to those above for making the movies.

iDesignSound
MidiBridge & SynthStation25 Allows Control of any CoreMIDI iPhone App!

iDesignSound
MidiBridge + Akai SynthStation25 = Wireless MIDI Controller Keyboard!

MusicApps.com.br
Resurrecting your MIDI Mobilizer I with MidiBridge app

MusicApps.com.br
Controlling SampleTank for iOS with SoundPrism Pro using MidiBridge

Tim Behrens
Geo Synthesizer controlling SampleTank via Midi Bridge - Part 1

Tim Behrens
Geo Synthesizer controlling SampleTank via Midi Bridge - Part 2