Switch between apps using MIDI controller

299 views
Skip to first unread message

iOS Musician Blog Author

unread,
Sep 24, 2012, 11:32:13 AM9/24/12
to open-music-app...@googlegroups.com
This RheyneMusic guy uses multiple iPads and iPhones in his jam sessions, and was thinking of ways to do use multiple apps at the same time but on only 1 iPad... came up with OMAC fast app switching + MIDI in. Thought it would be cool if you could switch apps with your midi controller....

multitasking gestures sometimes press buttons or turn knobs and double tapping home would be inefficient and distracting in a live setting like Rheyne

what do you guys think?

Gabriel Gatzsche (Audanika - SoundPrism)

unread,
Sep 24, 2012, 12:05:53 PM9/24/12
to open-music-app...@googlegroups.com
Hi, 
I think this is a great idea. Do you think that there will be a central app that runs in the foreground and receives the switching commands or should every OMAC compliant app to be able todo the MIDI-triggered-switching?

  Gabriel

iOS Musician Blog

unread,
Sep 24, 2012, 1:09:21 PM9/24/12
to open-music-app...@googlegroups.com
I was thinking that each app would add it.

maybe it could work like this:
user could setup a MIDI command (like in loopy hd), that would activate an OMAC fast switch command, maybe even the OMAC fast switching could automatically detect apps that are connected via Virtual MIDI/Core MIDI Clock Sync. the midi command could be Next Virtually Connected App and Previous Virtually Connected App

iOS Musician Blog

unread,
Sep 24, 2012, 1:11:58 PM9/24/12
to open-music-app...@googlegroups.com
or a central app, either way i guess... a central app could be more user friendly because they wouldn't have to do those settings in each app...


On Monday, September 24, 2012 11:05:56 AM UTC-5, Gabriel Gatzsche (Audanika) wrote:

Nic G (Audeonic Apps)

unread,
Sep 24, 2012, 1:26:36 PM9/24/12
to open-music-app...@googlegroups.com
I wouldn't bet that our Apple friends would disallow any app that ran in the background and switched foreground apps as its raison d'etre. (Yes, that's lots of negatives.)

Also, the user would have to download the central app and the central app would have to be kept up-to-date.

All bias aside, it seems to me that a better way would be to extend the omac registry and class for this. Any app that uses the class can choose to honour some sort of sysex message to open app urls. The structure for pushing app updates to apps that implement omac fast switching is already there. Seems a waste to reinvent something.

Maybe it would encourage some others to participate? (you know who you are!)

Regards, Nic.

Gabriel Gatzsche

unread,
Sep 24, 2012, 3:36:31 PM9/24/12
to open-music-app...@googlegroups.com
yes, i think also that having an app in the background do the switching could be problematic.

extending the OMAC registry is one possibility, but I'm not sure if sys ex is appropriate here. I'd guess that users want to use simple midi CCs to trigger switching, not Sys-Ex commands. In that case we need a way to map midi CCs to launch URLs. To create the mapping automatically, it is required to negotiate the mappings between the installed or running apps.

@Sean: What do mean with "next" and "previous" connected App? In my point of view Virtual Midi connections can be made in arbitrary ways, thus there is no previous and next app, or?

Nic G (Audeonic Apps)

unread,
Sep 24, 2012, 3:50:29 PM9/24/12
to open-music-app...@googlegroups.com
Sure. sysex was just an initial thought to prevent global hijacks of CCs by all apps implementing this. Might get messy.

However, let me come clean here in that I had been asked by a separate customer to add this feature as a port module to one of my apps already and am using the omac registry class to populate a dropdown of apps to be matched against a user selectable CC. Generally since this app often runs in the background I suppose this could be seen as a hybrid between the central app idea and distributed omac logic.

Of course the two can co-exist if need be.

In the central app model, the previous/next app could make sense but not in the distributed model as Gabriel points out.

Regards, Nic.


iOS Musician Blog

unread,
Sep 24, 2012, 5:22:19 PM9/24/12
to open-music-app...@googlegroups.com
i was just thinking out loud with my non-developer brain - i don't really know what i'm talking about here, that was just an example i thought for of how it could work...

"next and previous virtually connected app" was just the way I was thinking of implementing it (may not be the best way, i don't really know): if there was an <analogy> imaginary multitasking tray for apps that that are doing something virtual midi-ish/clock sync-ish with another app</analogy> when such an app is noticed it would be put in the immaginary multitasking tray and apps could be <analogy> switched in between with left/right 4 finger gestures </analogy> ..... but realistically they would have some MIDI event trigger the next / previous app in "the tray"

// I'm studdying computer science in school right now so maybe in 2 years I'll be of more help haha

David Warman

unread,
Sep 25, 2012, 2:01:52 AM9/25/12
to open-music-app...@googlegroups.com
Alternatively, something like MidiBridge ccould switch. We (Lone Wolf, 1991) did this with our MIDITap. The Apps just have to obey patch change messages. MB already does the routing, filtering, and transposition etc just as our Taps did. Add sending patch change commands on all connections as part of the MB current configuration, andf have MB itself accept patch change commands to switch configurations. Works like a champ - ELP, INXS, and several others used this kind of facility live with great effect.

- David Warman
--
- David Warman

Gabriel Gatzsche (Audanika - SoundPrism)

unread,
Sep 25, 2012, 8:55:44 AM9/25/12
to open-music-app...@googlegroups.com
Sounds interesting. Could you provide a little demo video which demonstrates this?

David Warman

unread,
Sep 25, 2012, 2:50:25 PM9/25/12
to open-music-app...@googlegroups.com
I'll give it a try, though it will be a small demo (I only have a 2 tap / 8 devices network live anymore). What you'll see is me sending a single patch change from my keyboard which will change the MidiTap configuration, which will in turn send patch changes out to all synthesizer channels configured for such. The routing will also be changed. I'll follow up with a functional diagram mapping the system onto an iOS realization.

- David Warman


--
- David Warman

iOS Musician Blog

unread,
Sep 25, 2012, 3:33:20 PM9/25/12
to open-music-app...@googlegroups.com
I'm excited :) really hope this gets implemented

Gabriel Gatzsche (Audanika - SoundPrism)

unread,
Sep 25, 2012, 4:13:56 PM9/25/12
to open-music-app...@googlegroups.com
Great! 

Fabio Di Mauro

unread,
Sep 26, 2012, 3:40:46 AM9/26/12
to open-music-app...@googlegroups.com
Questa e dal gruppo del Virtual Midi...

---------------------
Fabio Di Mauro / @sinapsya
---------------------
Graphic Depth / Studio di Grafica Pubblicitaria.
@graphicdepth
---------------------

iOS Musician Blog

unread,
Sep 27, 2012, 3:28:32 PM9/27/12
to open-music-app...@googlegroups.com
if you upload it to YouTube/Vimeo/whatever I'd be happy to post it on the blog

Nic G (Audeonic Apps)

unread,
Sep 28, 2012, 8:38:09 AM9/28/12
to open-music-app...@googlegroups.com
I have just done a little experimenting with this and with a certain app mentioned in this thread already. I was able to set things up so that I could switch to a different app using an Akai SynthStation 25. I programmed each of the 4 SS25 buttons to switch to an app of my choosing. I was able to flip from 'certain app' to the destination app like a dream, but...

An app cannot cause a switch to another app whilst in the background. Understandable, I guess. This means the central switcher app model isn't going to fly.

Therefore, the only way this could work bi-directionally is if the current app in the foreground also honours the MIDI events to switch. These MIDI events have to be consistent across apps for this to work.

Let's say someone extends the omac registry class to support MIDI controlled fast-switching, then there must be a global MIDI event to app mapping included in the registry which all participants have to agree on (or just dictated, haha) *but* each app developer also has to hook a call to the omac switcher into their MIDI engine which would require more work. More work, than currently is needed to be an omac fast-switch participant.

Given the take-up of omac fast switching is relatively small, my guess is that getting this sort of collaboration is going to have even lower take-up, although I would love to be proven wrong.

If I were to be able to secure commitment from a reasonable number of app developers that they would participate in MIDI controlled app switching, then I would consider extending the omac registry class and registry to do this.

So... if you're an app developer and would pledge to join in this if it were made available, please post an "I'm in" message to this post to which you will of course be held. ;-)

Regards, Nic.


iOS Musician Blog

unread,
Sep 28, 2012, 11:21:49 AM9/28/12
to open-music-app...@googlegroups.com
i'll throw up a post now

Amos

unread,
Sep 28, 2012, 3:31:30 PM9/28/12
to open-music-app...@googlegroups.com
All: would it make sense to agree on a MIDI NRPN number, perhaps, which all compatible apps could use for these fast-switching type commands?  I am thinking the method would be something like, send the agreed-upon NRPN number, then NRPN "increment" and "decrement" messages could be used to switch to "next app" and "previous app."

just a quick thought...

iOS Musician Blog

unread,
Sep 28, 2012, 6:02:55 PM9/28/12
to open-music-app...@googlegroups.com
just threw up a post: http://www.iosmusician.com/2012/09/switch-apps-midi-controller.html

@Nic G: are you saying that each app would have it's own MIDI message for switching? could there be a way to pick (MIDI learn) the midi message for each app?

Nic G (Audeonic Apps)

unread,
Sep 28, 2012, 7:04:34 PM9/28/12
to open-music-app...@googlegroups.com
Each app would need respond to the same NRPN message by passing MIDI messages through the omac registry class which would then switch to the app as designated by a particular NRPN value. The next/previous can't happen, because each app cannot know what next/previous actually means. The class has to encapsulate the individual app details that correspond to the NRPN message payload.

The way I would see it working is that each app that registers in the omac registry is allocated an app identifier which corresponds to the NRPN value. When the omac registry class gets the omac switching NRPN it looks up the app's URL in the registry and if that app is installed will switch to/launch it. ie. The omac registry class will do the work of looking up and switching for the participating apps.

It effectively extends the omac registry class that is currently (freely) available for fast-switching to also handle the MIDI sourced switching. When a new app joins, a new registry update is pushed out just as it works now, so new apps that join the scheme will be recognised by all the other existing apps that implement it already.

The end user either has to program their equipment to generate that (published) NRPN byte sequence to switch to a particular app, or there could well be an app switching module in MidiBridge (already done as proof of concept) that will translate any incoming user specified MIDI message into a (user selectable) app specific switching NRPN.

The idea being that you could program MidiBridge (or some other app) to convert say the buttons on an SS25 (these generate controller events) to the desired NRPN. As long as the other app is also being fed events from MidiBridge (say), then when another app is in the foreground, MidiBridge receives the SS25 controller event, and than converts this to the NRPN that the foreground app gets and then switches by using the omac registry class. The foreground app doesn't need to do anything except pass MIDI message to the omac registry class which will switch if it's the right message and the destination app is installed.

Not sure how well I have explained that. I suppose it is a tad technical nuts and bolts. The end result is that a user will be able to switch between any participating app by either sending the correct NRPN sequence themselves or using an app like MidiBridge to send it for them if their equipment won't generate arbitrary NRPNs but will generate other events that this app will convert for them and pass on.

However, the usefulness of this would entirely depend upon the number of devs who implement it.

Regards, Nic.


Michael Tyson

unread,
Sep 29, 2012, 3:48:36 PM9/29/12
to open-music-app...@googlegroups.com
Hello,

I just saw Sean's post and thought I'd chime in - we'll be doing this in Audiobus. The app switching is already in there, and we'll be adding MIDI control for that, not in the initial version, but in a subsequent update.

Here's how it works:

All Audiobus-compatible apps are going to need to register a URL which Audiobus uses to fast switch and detect apps. We keep those URLs in a central repository which is automatically downloaded and kept up-to-date by the Audiobus app.

It's not possible for an app in the background to open URLs (therefore activating an app), so what we do is fire a message off to all Audiobus-compatible apps on the device, and the one in the foreground responds and opens the URL, switching to the app on behalf of Audiobus.

I've not built the MIDI control system yet, but Loopy's implementation is very modular and will fit in nicely, once we're ready to add it. I imagine having bindable controls for next/previous app, as well as the ability to add bindings for each individual app, pretty much the way Loopy lets you add bindings for various actions.

Cheers,
Michael


-- 
Michael Tyson | Audiobus
Live, app-to-app audio streaming is coming soon.

Don't want to miss our launch? Then sign up here: http://audiob.us



iOS Musician Blog

unread,
Sep 29, 2012, 6:02:56 PM9/29/12
to open-music-app...@googlegroups.com
awesome!
Reply all
Reply to author
Forward
0 new messages