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 StoreAudiobus is the app that makes the rest of your setup better.
Comments
Yes, I definitely would like to fix this. Maybe you can contact me at [email protected]? Then, we'll figure everything out (I'll need a crash log from your device).
Ha! No not yet.
Hi @JohannesD hope you're enjoying your vacation. I bought the Conditions IAP in order to remap keys/CCs to trigger my midi bindings in LOOPY HD, however I'm not finding a way to successfully trigger them. The midi input options all switched off as per usual midiflow set up is not finding a way a through, even though my condition setups are resulting in the correct end midi notes/CCs tested on other end synths.
i.e I have a condition that when my cc59 knob value is over 63(0-127) the notes on my keyboard switch from being midi channel 1 and turn into notes on midi channel 16. These new notes correlate to existing bindings in Loopy. But without 'ticking' any of the midi input options in Loopy, these being Sunrizer, iRigMidi adapter(keyboard) and a network session I can't see how I get Midiflows data into Loopy.
I saw some screenshots you had using midiflow with Loopy. Do you have any hints/tips?
I can wait until you return from hols....unless there's a quick answer?
Thanks
Are you have issues just putting Loopy in an output slot in MidiFlow? Or is your final out more complex than that? If the latter, you could create a custom Virtual MIDI Out pirt in MidiFlow and route through that ...
Hey David, thanks for the suggestion. Creating the Virtual Midi Out port in Midiflow sounds like it could be worth investigating. I'll report back over the weekend. Cheers.
@dwarman You sir are the dog's dangly bits!
Creating a Virtual port that became visible in Loopy was exactly what I needed.
Thanks a lot Sir Midi!
Ha, Loopy update addressing this a few hrs later.
Unfortunately i havent been able to do anything with midiflow. Could just be that the apps i want to use with it just dont play well. Hard to tell.
Hi. Haven't had time yet, but I will. I'll try on my iPad mini and iPhone too.
In the meantime - can I ask another question.
I want to interupt a sequence of the same note (drum hits) being sent from App A and replace with a different set of hits on the same note from App B - is that possible. What function would I need.
So I want to have, say a standard 4 beat hit on s kick drum from app A. Then when I hit the roll or fill on App B I want that to completely kill the standard 4 beat sequence from App A. (All concerning the same note, say C2).
I'll like to set this up for a whole drum kit (say 8 drums / notes) so I could send in different rolls and fills on the different instruments, live, and override the sequence.
So not a straight remapping. Probably a muting of one channel when another is triggered or something? But the note wouldn't occur at the same time. Tricky.
... It's tricky because my 'roll' pad just sends lots of note on and offs. I'm sure I could get the sequence channel to listen for notes on the roll channel and mute when it does, but I can't figure out how I'd tell the original sequence to unmute again. It won't be able to know when the drum roll has finished because the last 'note off' is no different to all the other 'note offs' in the drum roll.
[I basically want to emulate the 'trigger' button in the new Elastic Drums update.].
I'm trying to use this to remap some midi notes from my drum module before it goes into Gadget. Is there any way for MidiFlow to prevent Gadget from seeing the original un-remapped notes? I know the problem really lies with Gadget's omni mode listening to every input on every channel, but is there any way for MidiFlow to grab and kill incoming notes from a certain port before Gadget sees it?
Yep. It's a real bummer.
From another app - yes (you have to address the Gadget virtual midi port, so just don't do that until you are ready).
From hardware - I don't think so. It seems to grab anything from core midi immediately - on any channel. Very annoying.
Only mad thing I could think of is sending it into an iPhone first, converting the notes (8 drums?) to midi ccs or maybe just 8 high notes, then into the iPad where Gadgets drum module won't now recognise it, then do your remapping stuff, then finally convert into notes that gadget recognises.
Oh man, I hope I didn't upset @dwarman ....that's a compliment in the UK!
@spookyzoo - no, just a chuckle. I am a Brit, y'know ...
Anyone wanna start a band called The Dangly Bits?
Well. I finally got the logic working to have MidiFlow kill a repeating sequence of drum notes when I trigger a 'roll' of the same note from a different pad.
But the problem now is latency. Because I'm using the condition 'key released' I think it's continually doing a full round robin check of every key on the keyboard to see if it's released. Or something thats choking it up anyway.
If I delete that condition it all runs smoothly. But the 'key released' condition slows everything right down unfortunately.
MidiFlow working nicely other than that though. I guess I'll need to find some different logic.
Basically I want to get it to map notes if a particular key (pad actually) is NOT down. The whole condition logic seems to be geared to things having to be true, and there's no way just to invert it to become 'do this if something is NOT true' - eg if notes are 'not' playing on this channel or whatever.
Sorry for my absence, I'm back in Germany now.
@Matt_Fletcher_2000
Could you make a recording of what you're trying to do? I'm not sure if I understand it correctly.
Hm, there should not be a latency like that. However, conditions are processed asynchronously. So, when a message comes in and there is a condition that switches another routing off, the next messages might still be processed by that second routing within a time frame of a couple of milliseconds. This has performance reasons and usually only causes problems if you what to switch a note routings on and off via notes (or controllers via a controller). This might be the case in your case.
I don't know what you mean. In the condition screen, you can specify when a condition is true or false. In case of a key as incoming controller, you can select between "Released" and "Pressed" (the info below the corresponding buttons says "Specify which state of the controller should set this condition to 'true').
thanks @JohannesD
After further work on it - yes - everything is possible in terms of MidiFlow having the conditions I need.
I nearly have it working, it's just some weird glitch somewhere that means it takes about 2 seconds for the note mapping to kick in once the condition becomes true (ie I release a note). However when I press the note it immediately stops the remapping. It doesn't feel like simple latency actually. You can see that notes just stop getting sent altogether for about 2 seconds, then it all kicks in again.
Also it might be dependant on the particular apps I'm using, I'm thinking, because if I just apply the patch/logic to StepPolyArp alone I don't get this weird break in notes being sent. It happens when I'm firing a combination of notes from Yamaha Synth and Drum app too.
Anyway, that's for your help and your offer of more help. I'll keep on trying and if I'm still stuck I might send a video.
By the way, the original problem with the list view causing a crash seems to have disappeared entirely now. So that's good.
Your help on this forum is much appreciated!
Ok, I'd be interested in a video anyway because your use case is interesting. It might also help other users to understand what you can do with Midiflow's conditions.
Concerning the latency: I wonder if there is a MIDI loop in your system, this might cause a delay like that. Just switch on monitoring to see what's going on.
I think I know what it is now.
Yahama seems to be sending an "all notes off" (cc123 - 000) five or so times at the exact time where the condition becomes true.
So this blows everything out for a few seconds, then the note mapping happens.
But I have no idea why setting a condition (note released) in MidiFlow would cause Yamaha's virtual midi port to do that.
You can see that the c123 messages are coming out of the Yamaha app though, before it hits the MidiFlow modifier.
@JohannesD Would MidiFlow be sending anything to yamaha's port at this point? I thought it would just be listening to data coming out of the Yamaha app since that's the way the chain goes.
Hm, I don't know what is happening... However, I have realized a similar issue with Sampletank.
Midiflow uses an iOS API to create MIDI routings in cases where that API supports the desired routing. Otherwise, Midiflow does the routing itself. A condition activates and deactivates a routing. So, in case of a iOS API routing, Midiflow tells the system to switch it on or off. Now, other apps can listen to changes of the routings in iOS and react to it. Sampletank for example mutes all its sounds – in order to prevent hanging notes, I guess. However, this is a real pity because Midiflow would handle that a lot better (routing retention). I contacted Sampletank but didn't get through to the devs.
Maybe yamaha does something like that as well.
I've thought about making a switch in Midiflow that would always force it to use its internal routing instead of the iOS API. But it's not easy to present it in a way that makes sense for the user.
@JohannesD - thanks!
Ah. It sounds like exactly that problem with the Yamaha app then.
You can hear it happen when I turn the condition on or off from inside MidiFlow. I think Yamaha likes to send 'all note off' messages just to be on the safe side.
So, are there any conditions in MidiFlow that don't use the iOS api? For example I'm using key on and release, at the moment. But I could perhaps use two different velocity values on a note instead.
@JohannesD - actually I re-read your mail and so i realise that it's the routing itself that's the problem. The fact that it goes through the iOS API.
It definitely is this I think... you can hear at other times that there is a 'lag' at the point you connect to the Yamaha app which you don't get with other apps - it seems to kill everything and then come to life.
Any clever way to force the Yamaha app to use MidiFlow's own routing?
Exactly!
Hm, can you try to create a custom MIDI port in Midiflow and select it in the Yamaha app? Custom MIDI ports use Midiflow's internal routing, so this should solve the problem then.
@JohannesD - cool. Thanks, i'll try that then.
Yamaha has this weird thing where you get to choose to switch it's virtual midi port on or off (but if you turn it off then Midiflow can't see or interact with it at all).
If I hook Yamaha to MidiFlow's custom Midi port in the Yamaha app - then in MidiFlow do I then have the MidiFlow custom port at the top (where Yahama would be otherwise) and my destination app (gadget) at the bottom?
Is that how it works?
So it goes:
Yamaha > MidiFlowPort [inside the Yamaha app]
MidiFlowPort > conditions/remapping > Gadget [inside the MidiFlow interface]
That right?
Yes, sounds right.
Aha, so this must be why iGrandPiano's volume knob goes all the way to zero with any routing change. No Midiflow involved in this.
IK are pretty skilled at finding ways to annoy musicians.
Cheap shot, I know.
Not a cheap shot when it's accurate. IK is my nemesis and thwarts my every move. (shakes fist)
I have contacted IK now about the issue again. Anyone else should do this as well, also for Yamaha. Otherwise, nothing will change. Feel free to use the information I gave above. I think, clearing the notes is not the duty of a synth app. Instead, (only!) the app that creates/removes the routings should do this.