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.

Modstep CC + Shoom

Quick question... I'm using Modstep midi cc to automate some of the controls in Shoom. I've got it set up and working. shoom shows up in Modstep and my control changes are working in Shoomas I'd hoped. Only, although Modstep shows up as a source in Shoom... the control changes sent by Modstep don't work unless I have Virtual In CC IN selected. If I choose Modstep CC IN as the source, it doesn't work.

I'm a novice to Modstep and although it's working, I'm wondering if I've set something up wrong. Seems like I should be selecting Modstep as the source instead of Virtual In.

Comments

  • Doesn't matter I guess. midi cc in Shoom works as expected. Just doesn't seem like it's need to be via Virtual IN when Modstep shows up as a source. Tried 3 other apps without a virtual option and they routed as expected. Maybe it's a minor bug in Shoom.

  • Do you have AUM? Check out its help, Midi Routing section, starting with "Make sure you don´t create double connections". If you configure app A to send to B, then you shouldn´t also configure app B to receive from A.

    Actually, I believe that happened in the video of the recent Navichord update thread, and later in the video the guy was surprised that Arpeggist also sent to N. (I think, not 100 % sure here).

    Anyway, in Modstep just tick CC for Shoom out in Midi and turn Midi on for the track, and Shoom will respond to the curves you draw.

  • edited March 2017

    @bleep said:
    Do you have AUM? Check out its help, Midi Routing section, starting with "Make sure you don´t create double connections". If you configure app A to send to B, then you shouldn´t also configure app B to receive from A.

    Actually, I believe that happened in the video of the recent Navichord update thread, and later in the video the guy was surprised that Arpeggist also sent to N. (I think, not 100 % sure here).

    Anyway, in Modstep just tick CC for Shoom out in Midi and turn Midi on for the track, and Shoom will respond to the curves you draw.

    Actually, that's not the way it's working. I've set Modstep to send to Shoom. But, Shoom doesn't respond unless I select Virtual IN (CC IN) in Shoom's midi settings. With this setting, Shoom responds. I can also send from Modstep on 4 different tracks via separate channels to control each of Shoom's 3 synths and a 4th for the session master controls. All works as expected, but ONLY if I select Virtual In for the source, not the listed source Modstep CC IN.

    If I send from Modstep, but not select a source at all in Shoom as you suggest, I get no response from Shoom with my Modstep-sent midi cc curves.

    ps. and yes, I have AUM

  • My Shoom is always set to Virtual in, that´s why I didn´t have to do anything there. Modstep is only shown in the list if it is running, so Virtual In would be a more stable default configuration. If you use virtual in for apps that listens to it, then you only need to configure that the sender has that app as destination.

  • @skiphunt said:
    the control changes sent by Modstep don't work unless I have Virtual In CC IN selected. If I choose Modstep CC IN as the source, it doesn't work.

    This is the correct behavior. While your assumed setup would seem to be the logical approach (I want CC in ModStep to go out to “Shoom” and in Shoom to come in from “ModStep”), it’s not how Core MIDI on iOS works.

    You have to think of things in a much more literal sense on iOS and understand that names are referring to ports (inputs and outputs, which are not the same) and not the apps per se.

    For a second let’s not talk about Shoom, but something else like iVCS….

    When you send CC from ModStep to iVCS3 by setting the MIDI out on the track in ModStep to iVCS3, you are directly sending it out of ModStep to an input port called “iVCS3”. However, to get iVCS3 (the app) to respond to CC from ModStep (the app), you don’t set it to receive CC from the “ModStep” port, rather you set it to receive CC from the port called “iVCS3”, since that is where the CC is being sent. Yes, it seems bizarre to select that port since it seems like you’re making a feedback loop out of iVCS3 back into iVCS3, but you have to understand that that is not the output of the iVCS3 app, but rather, an input port named “iVCS3.”

    Some apps try to avoid this user confusion by calling this port the “Virtual In” port (i.e. Shoom, but also Xynthesizer, Tweaky Beat, etc.), but that can be just as confusing since it’s not intuitive what’s feeding that input since other apps refer to that port by the port’s published name (Shoom) not something called “Virtual In”. In operation it’s the same principle: to send MIDI to Shoom from ModStep you would set the track to “Shoom” in ModStep and then in Shoom you would set MIDI in from the “Virtual Input.”

    To really show this is how it works case, try this:
    In ModStep set the track’s output to “ModStep”. Now in Shoom set the CC in from “ModStep” and you’ll see that it works.* You're sending CCs to the output port called "ModStep" and Shoom is receiving CCs from the "ModStep" port.

    *NOTE - this does seem to show a bug in ModStep: it only seems to output on Ch1 of it’s own named “ModStep” port, so in this experiment it will work for Synth 1 in Shoom only (unless you've changed Shoom's default settings). I checked this with iVCS and MIDI Scope and the output is always on Ch 1 of the "ModStep" output port regardless of what the track channel setting is.

    So why do other apps work without setting “Virtual In”? I’m guessing that they are hard wired to always accept input on their own named input port. This can seem to make the user experience easier, but it’s not the most flexible and can lead to confusion about how all of this really works.

    Basically, Core MIDI on iOS is a bit of a cluster#_{%. While everyone is using the same underlying framework, the implementation and user interface are up to the developer and so every app is different to a greater or lesser degree. I believe this is what Audiobus 3 is hoping to rectify.

  • Still waiting for midi note on/off support like the dev promised a while ago. This synth is catching dust since im not able to create midi tracks for shoom inside my daw.

  • @Proto said:
    Still waiting for midi note on/off support like the dev promised a while ago. This synth is catching dust since im not able to create midi tracks for shoom inside my daw.

    Agreed. Still love me some Shoom though... And getting some aural movement from midi cc automation via Modstep is a cool morsel to play with until Shoom hopefully gets the promised midi note in. :)

  • edited March 2017

    @aplourde said:

    @skiphunt said:
    the control changes sent by Modstep don't work unless I have Virtual In CC IN selected. If I choose Modstep CC IN as the source, it doesn't work.

    This is the correct behavior. While your assumed setup would seem to be the logical approach (I want CC in ModStep to go out to “Shoom” and in Shoom to come in from “ModStep”), it’s not how Core MIDI on iOS works.

    You have to think of things in a much more literal sense on iOS and understand that names are referring to ports (inputs and outputs, which are not the same) and not the apps per se.

    For a second let’s not talk about Shoom, but something else like iVCS….

    When you send CC from ModStep to iVCS3 by setting the MIDI out on the track in ModStep to iVCS3, you are directly sending it out of ModStep to an input port called “iVCS3”. However, to get iVCS3 (the app) to respond to CC from ModStep (the app), you don’t set it to receive CC from the “ModStep” port, rather you set it to receive CC from the port called “iVCS3”, since that is where the CC is being sent. Yes, it seems bizarre to select that port since it seems like you’re making a feedback loop out of iVCS3 back into iVCS3, but you have to understand that that is not the output of the iVCS3 app, but rather, an input port named “iVCS3.”

    Some apps try to avoid this user confusion by calling this port the “Virtual In” port (i.e. Shoom, but also Xynthesizer, Tweaky Beat, etc.), but that can be just as confusing since it’s not intuitive what’s feeding that input since other apps refer to that port by the port’s published name (Shoom) not something called “Virtual In”. In operation it’s the same principle: to send MIDI to Shoom from ModStep you would set the track to “Shoom” in ModStep and then in Shoom you would set MIDI in from the “Virtual Input.”

    To really show this is how it works case, try this:
    In ModStep set the track’s output to “ModStep”. Now in Shoom set the CC in from “ModStep” and you’ll see that it works.* You're sending CCs to the output port called "ModStep" and Shoom is receiving CCs from the "ModStep" port.

    *NOTE - this does seem to show a bug in ModStep: it only seems to output on Ch1 of it’s own named “ModStep” port, so in this experiment it will work for Synth 1 in Shoom only (unless you've changed Shoom's default settings). I checked this with iVCS and MIDI Scope and the output is always on Ch 1 of the "ModStep" output port regardless of what the track channel setting is.

    So why do other apps work without setting “Virtual In”? I’m guessing that they are hard wired to always accept input on their own named input port. This can seem to make the user experience easier, but it’s not the most flexible and can lead to confusion about how all of this really works.

    Basically, Core MIDI on iOS is a bit of a cluster#_{%. While everyone is using the same underlying framework, the implementation and user interface are up to the developer and so every app is different to a greater or lesser degree. I believe this is what Audiobus 3 is hoping to rectify.

    Yes!!! This is exactly what I was after. Makes perfect since. I was simply trying to better understand how midi routing works, and the naming conventions used between modstep and Shoom didn't make logical sense to me. But your explanation clears it up nicely. Thank you for taking the time. :)

  • Hello to Yuri. We need midi support for Shoom.

Sign In or Register to comment.