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
Thanks man
@anzbert
The Novation Launchpads also have note mode with the ableton „in key, 4th“ layout option. The following custom firmware has it included as well, maybee you find some inspiration in the code.. 😊
https://github.com/mat1jaczyyy/lpp-performance-cfw
Regarding the velocity (non-mpe mode): Some iPad apps use the y-axis of keys or pads to define the velocity: if one presses the pad in the lower region small amount of velocity is applied, in the upper region of the pad higher velocitys are applied.. could be an option in your app. a perfect implementation would allow me to define the velocity range as well (for example 30-90).
Yes, Linux is good, but your comment turns out ironic in this context because we're talking about an app that's "USB Midi Pad Controller App for Android, iPad and iPhone." No build for Linux.
Also, Micro$ owns Github, so there's that, too.
wow, the mpe implementation of this app is very well done! just tested it with Uvi Falcon (running inside Ableton).
@Samplix yes that velocity implementation could work. Especially when you have only one or two rows and the pads are fairly tall. Thx for the tip!
I guess it could be built for Linux as well. And since it's open source, anyone could go and do that. It's a good point.
I just hadn't really thought about it yet, since my main focus was devices with primary touch screen input.
My comment about Apple, Micro$ and Linux was meant to be a generic rant, not a feature request. It just gets on my nerves to see how much money is wasted and electronic waste created. Sorry for going OT.
Hi everyone, been reading this forum for a couple of months, but this is my first post.
I bought this app for Android and really like it a lot. I've played vital in Ableton with my phone and it's really cool. Especially being able to put something other than pitch on the x-axis is an awesome option.
It's a pity, that you can't just connect an iPad to a PC with a cable and use that as a controller. Have been trying around with wireless solutions, but that wasn't very stable.
I bought a relatively cheap Android 11 Tablet (this: https://www.amazon.de/dp/B0B9H19BQW/ref=pe_27091401_487027711_TE_SCE_dp_1) and was hoping, I could use that, unfortunately I can't download the app, because the Playstore informs me it's not available for my device (same for muselead actually which I also use as a controller. On top of that, I can't activate midi over usb (developer options are on, but there is no midi option under usb default setting).
@anzbert or anybody who has an idea. Can I do anything to get your app running on my tablet? Thanks in advance.
Hey man. Unfortunately Android manufacturers can apparently choose not to include Midi functionality in their OS build. It's not the first time I am seeing this. My app checks if your device supports 'android.media.midi' before letting you install it, to avoid disappointments. If you can't even find the option to activate a USB midi connection, in the notifications or in the developer settings, it's not a very encouraging sign.
Especially the cheap device manufacturers seem to be bad at giving you a feature-complete device. I mean Midi should be standard in Android since version 6! It's one of the downsides of android unfortunately.
Otherwise android would be so much better, for midi at least, with it's ability to present itself as a generic USB midi device. (Which iPads can't do, as you said)
I hope you can find a USB midi option somewhere in this device. Good luck!
Edit:typos.
Thanks for the quick reply, what a pity. By the way, I tried a search on the Playstore for mpe controller and midi controller, but your app didn't show up. I don't know much about SEO etc, but maybe more keywords would help to get more exposure. I've tried quite a couple of controllers on Android and so far I liked yours the best.
Yeah, you can see I am not an SEO pro as well haha. Beat Pads was a terribly generic name choice and it just disappears in the shop among all the other similarly named apps. Even when searching for the name directly you can't find it.
It's slightly better in the apple store, since that one is not as cluttered with trash as google play. Probably because it's much more expensive to have an app on the apple shop.
@catherder Hey the update is live now and the app should install on Android Nougat 7.0 now as well. Thx for triggering this change in the Flutter Midi Eco system. Yay for reducing Ewaste!!
Language! There won’t be any forking my my dependencies while I’m in charge.
Seriously, I’d be interested in checking out your app to see what’s needed to compile it on various target devices. I even bought some of those “other” products to play around with doing some coding and learning something new.
I think I’ll find my GitHub credentials dusted off and play along. Just don’t expect me to fork anybody anytime soon.
Hey forking (😜) and compiling for Linux should be easy peasy. Just add another platform target and compile away. See here:
https://stackoverflow.com/questions/66214066/how-do-i-add-platforms-to-an-existing-flutter-app-project
Windows on the other hand will not work right now, because the underlying dependency FlutterMidiCommand does not support windows (yet).
Edit: MacOS should work, but then again there is no MacOS touchscreen device anyway.
It was a happy surprise to see Google Play update your app on my phone and immediately list my old tablets as compatible this morning. The S2 has just installed it. Big thanks to you for fixing this so fast.
The update with the Scale-4th mode, like on the push and launchpad, is finally live now
And the velocity by y-axis update should also be fairly easy to do. I'll attack that next when I have time again!
Enjoy!! And thanks again for the suggestion
Ooh, looking forward to checking it out.
Bought for iOS, too in the meantime and like it with the Bleass-Synths a lot.
Thank you!
Thank you @anzbert for this update with the Scale-4th mode (Ableton Push 2's "In Key, 4th" Mode)! It works perfect for me!
For those not familiar with this layout I will attach my personal chord cheat sheet.
I'm VERY excited to see an intelligently designed new MPE grid-controller app; have purchased/used many from Cantor to GeoSynthesizer, GeoShred, Mode of Expression, Velocity Keyboard, and others. Lots of good features on this app already, and great to see Open Source and responsiveness/interest of the dev in community input for possible upgrades to the app!
Re. velocity implementation, the old apps Mugician and Cantor (the latter strictly a microtonal-capable MPE grid controller by Rob Fielding -now abandonware but code made open source) and early versions of Jordan Rudess/Wizdom Music's GeoSynthesizer (for which Rob Fielding's work was also used; Jordan is also a keyboard player for Dream Theatre) used increases/decreases in the size of finger pads on the screen to correlate with increases/decreases in velocity. This was very musical and expressive.
Re. Suggestions for improving the app, there are a few functions from Cantor and GeoSynthesizer I would love to have in Andreas's app.
Mono /String /Poly /Legato -in GeoSynthesizer you can choose between these modes on the control panel while performing.
Mono lets you hold a lower note with your left finger and trill with your right finger, that is to say you can hold your left finger down constantly, and then when your left finger presses and releases it returns to the lower note automatically just like when you are doing pull-offs on a guitar or other stringed instrument.
String -is like Mono but it only trills within a given row.
Poly is just polyphony -playing multiple notes at the same time. In string mode for "shredding" this is not always needed.
Legato I believe rounds the attack so that "shredding" sounds more natural.
With all of these choices available at a touch / while performing, the "shredding" experience far beyond just hitting notes and sliding becomes an absolute delight and is one reason Dream Theater's Jordan Ruddess was able to boast that he could play GeoSynth faster than he could his keyboards.
Lock Pitch button (for quick change from pitchbend to non-pitchbend modes during performance)
Cantor and GeoSynth had a slider bar adjustable during performance for SNAP SPEED (-adjusts how long in milliseconds it takes for a random just-slided note to return perfectly tuned). They would tune the note to whatever new note your finger was resting on -Beat Pads' functions don't seem to work in this (superior, I think) manner.
-the range could be set from
NEVER (which sometimes is VERY expressive with flutes, saxaphones etc. slowly moving around the pitch but never exactly on it -incredibly expressive- to
INSTANT (just like no pitch bend at all), and (importantly)
ANY/ALL POINTS IN BETWEEEN.
The ability to set the whole spectrum in between is really absolutely incredible. Linnstrument (sadly), leaves this out and just has a few pre-set settings \suggested, BTW, by Jordan Rudess of Dream Theatre. The settings are "good" -maybe even optimal for many cases use, but sometimes you're looking for something very particular for a given instrument that one of just 3 presents isn't going to deliver for you. The SNAP setting on Cantor delivered anything/everything you could want.
Infinite Scale/Chord choices... In Settings have one octave of a keyboard with notes labeled. The notes you select will be on the grid, the notes you omit will not. Fast and easy to customize any chord/scale you want. That's not to say that the many scale choices already available in this app listed by name are not appreciated but oftentimes a musician will want something more than preset lists contain. This should not replace the list already there but be an additional option. In the list you could have "set scale on keyboard selector" or something....
It would be cool would be the ability to assign chosen color per note. This helps to visualize the scale degrees we are looking for a little better than just having preset linear color sequence as currently available in the app. In Settings you could have one octave of a keyboard with notes labeled to set this. Press any key and have a color wheel pop up with 12 colors to choose from.
One feature most grid-controller apps lack is assignable chord pads. The app that does this most logically is ChordMaps2 though there are others. A no-longer available app called Musa let you, after choosing a scale, assign chord choices for each scale degree of the chord along with having a standard keyboard-like note pad (which auto trimed itself to only notes in the scale).
Too bad AUV3 isn't possible due to limitations of Flutter; I wonder these days if ChatGPT5 couldn't recode the whole app into Swift in 2 or 3 minutes time -incredible what you can do these days without doing hardly anything...
I had a couple of questions first time using the app -Is it possible in MPE to have X axis do pitchbending and Y axis to slide from note to note? Doesn't seem to do that with Y Axis set to "Slide." More later/ have to go for now!
Some fantastic ideas here!
Hey @UrbanNinja ,
Thanks for all those suggestions. You definitely seem like you've been down the MPE rabbit hole! I don't even know the apps that you've mentioned. So maybe I have some homework to do.
I also have a long list of potential features that I woulkd like to see. On the top of it at the moment is having multiple Presets and a way to quickly swap between them. I find it tedious now that I always have to reconfigure parts of the grid between playing different instruments. I think different presets and quick swap buttons would already solve some of your issues too.
Chords and individually configurable Pads would also be awesome. I still would like to keep the app simple enough, instead of trying to make it do everything imaginable. I wouldn't want it to be bloated because of feature creep.
At the same time, I am seriously struggling with time commitment here. I still work a full time job as a nurse and so far, I haven't found any open source helpers. I made this app last year in about 3 months, while learning Flutter and Dart from zero after work. I felt a little burned out afterwards and left it for over half a year without touching the code. Now I feel fresh enough again to add a feature here or there and fix some bugs. I just submitted an update today with a new velocity feature and a Menu redesign.
Any way you look at it, it's a labour of love, like so many open source projects. Ideologically, I want to keep it free/cheap. The app store proceedings don't even cover the yearly developer account fees at this point, and all the time I am putting into this is just for my personal fun
And luckily it still is fun 
haha
I am putting all your suggestions on my "to consider" list and I will do some research into those control methods. But The presets/profiles are currently at the top of my list. As soon as I get a chunk of time again!
And yes, I wouldn't mind a bit of AI help here as well haha. I think I can somehow get a free trial for github co-pilot. Should check it out. I am also learning some Swift and SwiftUI at the moment. So maybe I can find a way for AUv3?! Thats a big maybe though. Maybe I will make a second app, using just Swift and AUv3 instead. Lots of ideas !!
To your last question, at the moment sliding from note to note and MPE are completely exclusive options. I think I will rework the wording in the MPE menu in a future release. 'Slide' in MPE terms refers to CC74 and that usually controls a change in Timbre. The slide input mode in my app refers to the ability to move across different pads and trigger them as you go. Did you also write me an email about that? The question sounds familiar. I hope I made it clear. I'll look into these other control modes, where you can play a note and temporarily slide to a different note. Definitely sounds intriguing.
Ok thats all I've got for now
Thanks; BTW, I absolutely love your youtube tutorials man (assuming you are the same Gavinski) -thanks so much for them!!!
Grateful to be in the "to consider" list for now; thanks for your hard work. Nurses are some of the hardest working people on the planet and it is beyond amazing that you have time for anything else this complex with that on your plate as a profession. Hats off to you!
Yea, the latest AI (e.g. ChatGPT4 etc) is amazing; anyone with no knowledge of code can actually get it to produce complete code for an app just by telling it clearly what they want the app to do, to look like, etc. It does make some mistakes here and there and is not perfect, but it's jaw-dropping amazing already. Github co-pilot might indeed be able to code from verbal descriptions of what you want the app to do alone since it is using ChatGPT4 as of just six days ago now (March 22 ) according to this:
https://www.theverge.com/2023/3/22/23651456/github-copilot-x-gpt-4-code-chat-voice-support
My daughter and son-in-law, both professional/degreed software engineers are among many professional coders in thinking the latest AI may make a lot of coding jobs as obsolete as grocery store checkout careers were made by automated checkout. Crazy times!
@anzbert
IFretless apps used the accelerometer to detect changes in velocity. Personally, I preferred that method over the finger area sensing thing, which is better suited to afterpressure IMO.
Area sensing requires realtime changes in playing technique, whereas when using the accelerometer you don’t really have to think about it.
Also, sensing touch area can be skewed by variation in size between fingers (eg thumb vs pinky). If you only react to proportional change in touch area you can get better standardised response, but obviously only once the note has started playing, hence the better match to afterpressure. I don’t know the current rules, but developers have in the past run into problems with Apple over inappropriate use of the touch area sensing feature of the API, so you may need to look into that.
Ok thanks for the hint. I might try using the accelerometer and see how it works for me. Maybe I can add that as another option, as everyone seems to have different prefered ways of imputing velocity.
Edit: my personal preference is to just to use a narrow random velocity range, just to make the notes sound a little more human.
I tend to build a bit of randomness into synth patches for the same reason.
anybody have a video of this in action?
A random range of velocity achieves a better illusion of humanizing in certain contexts but always more artificial and confining than the musician's ability to organically raise and lower volume/velocity as inspiration dictates second by second. Where this is not built in to an algorithm it can still be achieved e.g. by a volume pedal after the instrument, so all is not necessarily lost without it.
Yea, historically a security issue led Apple to prohibit its use for a time; my understanding was this is not a problem now per se, but I'm not sure. Overnight all my favorite MIDI controllers on the planet morphed from exquisite to a dull and lifeless "better than nothing." Accelerometer sensing would later improve things above that dire condition, but only a bit IMO (more on that below).
Only with absolute pressure area; taking the area at say 15 milliseconds equal to "moderate loud" you can get great velocity increases or decreases no matter what finger or combination of fingers with increased or decreased pressure -I feel this way not theoretically but emotionally as a function of my own deep love affair with the way Cantor and early incarnations of GeoSynthesizer felt and functioned in actual use. Glorious! I would personally reach for those with ipad touch area sensing over Linnstrument (which is great) "for the feel" any day. Accelerometer sensing is better than nothing, but functions better on a lap than a table, or requiring some mitigation on a table like a foam pad underneath. Still exponentially better than nothing(!) but nothing has ever felt the same to me as finger pad increase/decrease algorithms; some nights I still cry on my pillow over the loss...
I didn't/don't experience this issue at all; it is very natural performing and getting volume variations with minute variations in finger pad pressure so subtle it is basically effortless for all practical purposes, not to mention exhilarating/beautiful; you really don't think about it whatsoever at all in actual use. Either implementation is exponentially better than having no realtime velocity control. I love the ifretless apps too (they can be used as just a MIDI controller and like GeoShred and Velocity (latter by same dev as ifretless) have AUM) and used them along with Cantor, Geosyth, ect. since the moment they came out, but think the experience of accelerometer driven volume changes a far second as versus those tiny variations of finger pressure of yesteryear to the point of "no contest" as to excitement of performing with it. With touch radius sensing you don't just get velocity rises and falls, you get precision within the rising and falling curves themselves, like the difference between the top of an arc and the fractal or concrete visage of the top of a mountain range -or so it felt in use to me. Just one fanatical fan's 2 cents...
I think the way Woodtroller handles it is pretty good - divide each note into 3 different zones, the bottom for velocity, the others for aftertouch and expression. But that is much harder to implement in a grid than in a key style setup. Without 3d touch some compromises will always be needed.
@UrbanNinja you seem to feel quite strongly about velocity input. Very poetic 😆. I mean this in the best possible way. I just had a quick look at flutter input detection, and I am not sure if I can even read out the touch area easily. That could be a problem in implementing this easily.
I think it was still an acceptable choice to use flutter Instead of swift, because of the Crossplatform support. Especially because android is starved for decent music production apps compared to iOS. I think I still would go with swift next time around, since it looks like an amazing language, that has a lot of safety features and beautiful syntax that I've seen in Rust before. Really like Rust