I'm thinking about to start a project for inter-app MIDI (later Audio) on Android. But it makes less sense if nobody is using this mechanism in it's app.
Here in Jules forum we are a lot of developers and a lot of developers use Juce. I think we have enough power to create/use a new standard for Android like AudioBus on iOS or Jack on Linux and may be Jules can migrate this later in it's framework?
Not sure how to start, I'm not an android geek and have to read a lot.
Will be nice to discuss a bit and what you are thinking about. May be ideas?
@Jules: what do you think - what does you todo list think, is there a place to add this?
Sounds like a good extension for juce's android support. In a few weeks I can help to do some of the MIDI stuff - it's better than a juce2kshoji-bridge (which I'm currently use).
Yes, that is basically what it is, but in order for the audio engine portion of the app to get the appropriate RT audio permissions, they have created a special service that effectively launches an independent process, which loads a shared library from your app containing the audio engine. They have provided a message passing interface between your main application and this loaded process to use for comms. It also requires an application to jump through some hoops by defining a Service within the app as well. Despite all that, they seem to have solved the big latency issue, and provided an interesting way to make apps that can be midi instruments or effect plugins, routed via the JACK mechanism.
Because of all the android specific machinations and requirements on the java runtime side of things to bind it together, doing a close binding with Juce will be difficult.
I don't know what their plan is to make it available on other platforms, but clearly they are deriving from GPL'd work so perhaps Google will follow eventually with a more widespread implementation. Don't count on it though.
