Audiobus: Use your music apps together.

What is Audiobus?Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.

Download on the App Store

Audiobus is the app that makes the rest of your setup better.

Is there any way to block an app from receiving GLOBAL MIDI?

Basically the title. I have plenty of experience routing controllers with MidiFlow and AUM, but there are still apps out there that receive globally which is a big headache and basically ruins my painstakingly crafted mappings. How can developers not understand that music makers, especially those who want to make use of an app as a real musical instrument (for use in a live/improvisational setting) and not just a production tool, need for this to not be a thing! It's 2018. I'm looking at you, KORG ELECTRIBE WAVE.

The best case scenarios is when we can specify what channels and what hardware and virtual channels an app receives on. MIDI-Learn sometimes falls short of this. But, when you just throw Global Midi onto an app with a ton of assignable parameters, that is the worst case scenario. You're basically assuming a person (A) has a controller with 100+ knobs/pads and (B) isn't using your app alongside anything else. That's just not how iOS music-making works.

Unless I'm missing something... Is there any way to specify for an app (say Korg E.W.) to not receive my hardware's MIDI messages and only what it transmits post-mappings? Is there software that does this? I've tested it out in every way imaginable with AUM routings and MidiFlow, but it seems there's no way to come between an app and the device when it's equipped with global MIDI unless it's built into the software.

Anyone know anything that can help? My only solution is to plug my controllers into a second device and transmit the MIDI via Bluetooth to the original device with the software. That's pretty dumb. :neutral:

Comments

  • Set the receiving app to a numbered midi channel?

  • Turn the volume down on the app u don't want to sound

  • MidiFire / StreamByter may be able to handle this

  • @mistercharlie said:
    Set the receiving app to a numbered midi channel?

    +1

  • Following. Had this issue with Kauldron. You can turn it off in settings but it reverts sometimes. Had to just delete it.

  • @tja said:
    MidiFire / StreamByter may be able to handle this

    MidiFire doesn't help with those apps that listen to connected hardware regardless of one's settings. Sadly.

    Make sure to write emails to the support address to register your desire to have the app's MIDI input only listen to the selected devices.

    Note to self; write follow-ups this week.

  • If I recall correctly AB2 had an option to disable CoreMidi in connected apps?!
    (Maybe this feature is still present in AB3, have not checked that).

    There are apps some that always listen to CoreMidi no matter how or what is routed to them which is a real pita.

  • I still have the abandoned ZedSynth which listens to all midi ports and all channels :(
    In that case there is no solution.....

  • edited December 2018

    @Samu said:
    If I recall correctly AB2 had an option to disable CoreMidi in connected apps?!
    (Maybe this feature is still present in AB3, have not checked that).

    Unfortunately not. There is advice on their site on how to implement this into the software which is useful to developers.

    Looks like there is no solution. Got me thinking, would be cool if MIDI controllers were able to transmit on a virtual channel that is not received in any way other than for the purposes of rerouting. But so far only via Bluetooth (and by ensuring Bluetooth is not enabled in pertaining apps) does this seem possible.

    Kudos to those few who read my post and were able to carefully surmise what I was trying to say...

  • I’m late to the party, but I also spent at least a half day looking for a workaround months back. There just isn’t one. If an app, like iM1 listens globally, you just can’t block it. I didn’t know KEW had this same issue. If so, that really, really sucks for a newer app. What are Korg thinking?

  • Does just using a BT controller work the same as the 2 device setup you came up with?
    If so, you could at least eliminate the need for the 2nd device.

    Also, global core midi, does it receive from all connected controllers automatically, as well as receive all messages from one controller?
    What I am getting at is, can you could use one controller for KEW, and use a 2nd isolated controller to drive the rest of your carefully mapped-out setup?
    (I have the feeling the answer is going to be ‘no’).

  • @CracklePot said:
    Does just using a BT controller work the same as the 2 device setup you came up with?
    If so, you could at least eliminate the need for the 2nd device.

    Also, global core midi, does it receive from all connected controllers automatically, as well as receive all messages from one controller?
    What I am getting at is, can you could use one controller for KEW, and use a 2nd isolated controller to drive the rest of your carefully mapped-out setup?
    (I have the feeling the answer is going to be ‘no’).

    Using a bluetooth controller should work as long as I don't run it through a routing/mapping software like MidiFlow. As soon as I do, KEW receives it automatically as it is then transmitted globally, even if I have it routed into a single app in MidiFlow. It's nuts. :disappointed: I could potentially use it for other apps simultaneously if they have their own bluetooth settings similar to KEW integrated into their settings, but then that controller would be controlling both apps simultaneously unless I'm first sending it to a different device in order to implement conditions, etc via rerouting/mapping. And of course then I'm back to square one and the controller having bluetooth capabilities isn't a solution in this case.

    Basically KEW requires a controller to be completely dedicated to it and to nothing else for the 53 MIDI CCs that it must receive only globally (this includes the Mixer and Master CC parameters that you can map.) The other parameters that you can map are the S1-S8 parameters (32 total) and D1-D8 parameters (64 total), and these can actually overlap since they receive on channels 1-8 and channel 10 respectively. That would be the most real-estate efficient way to do this. But then the 53 Mixer/Master CCs can't be any of those 64 CCs, otherwise they would be controlling an S1-S8/D1-D8 function simultaneously.

    What you'll end up with is 117 CCs mapped, which doesn't leave a lot of room for anything else. Granted you'd still have 96 (128-32) available on Channels 1-8 and 64 (128-64) available on Channel 10, but this available CCs cannot overlap with any of the 53 CCs you have dedicated to the global functions.

    So basically you have 75 (128-53) CCs across any remaining channels left to work with granted you avoid the ones already assigned in channels 1-8 and channel 10, which doesn't leave a lot of room for someone who wants to use their controller for various apps' MIDI implementation.

    And of course this could all be avoided if KEW could be specified to receive only via virtual MIDI inputs, or at the very least could be specified to only receive on a certain channel for Mixer/Master CCs and not globally.

    This is for the "Advanced" MIDI implementation in KEW's settings. There is an "Easy" toggle in the setting which is even more of a headache and would require more hands-on-screen action.

    Also, don't even get me started on using a keyboard with KEW. The only solution there is to change your controller's channel via hardware, otherwise you'll always be playing on its default channel, regardless of routing.

    Whew.

  • @wim said:
    I’m late to the party, but I also spent at least a half day looking for a workaround months back. There just isn’t one. If an app, like iM1 listens globally, you just can’t block it. I didn’t know KEW had this same issue. If so, that really, really sucks for a newer app. What are Korg thinking?

    Thanks for the empathy. Yikes, Korg. Bad, bad, bad.

Sign In or Register to comment.