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.

Block incoming MIDI clock while keeping start/stop command

edited August 2023 in App Tips and Tricks

Hey there,
I am trying to set up my environment for the first time with "Beat Scholar" running inside Audiobus as an addition for my live DJ Sets.

I have the Traktor DJ software running on macOS with a Pioneer DJM-A9 Mixer handling the audio (connected via USB). On the 2nd USB port of the DJM I have the iPad connected with Audiobus running. The DJM can function as a MIDI master only, not as MIDI slave. The DJM matches its internal BPM counter to the audio stream that comes from Traktor, so it's always a bit "behind".

What I want to achive is:

  • having Audiobus/Beat Scholar match its BPM to the tracks running in Traktor
  • being able to control start/stop in Audiobus/Beat Scholar via MIDI start/stop button on the DJM

What I tried so far & results:
1. If I configure Audiobus to only grab MIDI from the DJM and hand over that MIDI to Beat Scholar, the start/stop command works, but the BPM isn't matched instantly to Traktor on BPM changes (see above)
2. If I configure Audiobus to only function as a peer for Ableton LIVE with Traktor (via WiFi), I get instant beatmatch changes, but am not able to use the MIDI start/stop button on the DJM
3. If I configure Audiobus to react to both those protocols, I am in kind of a deadlock and not able to change BPM at all anymore, as DJM tries to audio-beatmatch to traktor, while Audiobus tries to MIDI match to the DJM, while Traktor tries to LIVE match to Audiobus... the BPM change is just not applied.

I was thinking of 2 possible solutions:
1. Using the "MIDI Learn" Add-On to re-map another button on the DJM for start/stop in Audiobus and have start/stop in Audiobus trigger start/stop in Beat Schloar, without handing over the actual MIDI. I can't re-map the start/stop button on the DJM. Would work, but not optimal
2. Activating both MIDI and LINK in Audiobus, but somehow (how??) only grabbing that MIDI start/stop from the DJM, while blocking the MIDI clock to work around the deadlock. I found that "Midiflow" Add-On but am not sure if that will do the trick, and which of the many sub-apps of Midiflow I would need for my usecase. Midiflow Filter?

TLDR: How can I activate both MIDI and LINK in Audiobus, but only let the MIDI start/stop signal through, while blocking all other incoming MIDI information (or at least the MIDI clock)?

Thanks to you all from an Audiobus newbie

Comments

  • I would recommend you use StreamByter for this.
    It has a set of inbuilt messages that you can modify for your needs
    and there are plenty of experienced users who would know
    which messages to block.

  • wimwim
    edited August 2023

    The Streambyter code to block MIDI beat clock messages only is simple.

    # Block MIDI clock pulse (only)
    F8 = XX +B
    

    However, that will not solve the problem. Audiobus doesn't pass clock messages through. The only way Audiobus processes clock is through its own sync system. You can't set DJM as an input, run the clock though streambyter and pass it on.

    It can probably work if you can find a way to send clock to Streambyter standaone and from there to BeatScholar. I don't have the app so I can't do any testing for you.

    You might have to involve MidiFire with this script running in it to handle the routing.

    [edit] I guess BeatScholar is free with an IAP unlock? I don't know if the free version would be enough to test with, and in any case, I don't have DJM to test with, so probably not worth pursuing - but if you get stuck maybe I can delve deeper.

  • @Dastan : streambyter scripting will work as @wim said but you might need to use MIDIFire (which has streambyter scripting built in) because the streambyter app doesn’t have midi routing. MIDIFire has routing. What you would probably do is have MidiFire take the MIDI from the DJM and use a streambyter script to filter out the beat clock and pass the midi out through its virtual midi port.

    You would then use the MIDI Fire virtual midi output in Audiobus to access the DJM’s midi.

  • I’m fairly sure that MidiFire won’t be needed. Streambyter standalone can be routed to by anything and it publishes an output that can be seen by anything, including AudioBus.

    As long as the apps you want to start and stop can receive from Streambyter directly through Core Midi (not through Audiobus because Audiobus doesn’t route clock directly as I tried somewhat clumsily to explain above), they should work OK.

  • @wim said:
    I’m fairly sure that MidiFire won’t be needed. Streambyter standalone can be routed to by anything and it publishes an output that can be seen by anything, including AudioBus.

    As long as the apps you want to start and stop can receive from Streambyter directly through Core Midi (not through Audiobus because Audiobus doesn’t route clock directly as I tried somewhat clumsily to explain above), they should work OK.

    I mistakenly thought all hosts filter out the clock like AB. I just checked and AUM doesn’t. So you could host streambyter as an AU and filter the midi there. It has the advantage that AUM has AB state-saving. So , you could save the complete setup in an AB document.

    Could midimttr route from the hardware midi in to streambyter standalone?

  • wimwim
    edited August 2023

    Btw … AUM > @espiegel123 said:

    @wim said:
    I’m fairly sure that MidiFire won’t be needed. Streambyter standalone can be routed to by anything and it publishes an output that can be seen by anything, including AudioBus.

    As long as the apps you want to start and stop can receive from Streambyter directly through Core Midi (not through Audiobus because Audiobus doesn’t route clock directly as I tried somewhat clumsily to explain above), they should work OK.

    I mistakenly thought all hosts filter out the clock like AB. I just checked and AUM doesn’t. So you could host streambyter as an AU and filter the midi there. It has the advantage that AUM has AB state-saving. So , you could save the complete setup in an AB document.

    Correct, AUM doesn't filter out clock, but there's one big limitation. It doesn't route clock between AUv3 apps. It can route clock to external destinations but not between plugins. So, you can go from AUM to Streambyter AUv3 but not from Streambyter AUv3 to BeatScholar as an AUv3. You could maybe send it to the standalone app, but then AUM wouldn't be needed anyway.

    Could midimttr route from the hardware midi in to streambyter standalone?

    I don't think that's necessary. Streambyter standalone should pick up the hardware midi without any issue. I think.

  • @wim said:
    Btw … AUM > @espiegel123 said:

    @wim said:
    I’m fairly sure that MidiFire won’t be needed. Streambyter standalone can be routed to by anything and it publishes an output that can be seen by anything, including AudioBus.

    As long as the apps you want to start and stop can receive from Streambyter directly through Core Midi (not through Audiobus because Audiobus doesn’t route clock directly as I tried somewhat clumsily to explain above), they should work OK.

    I mistakenly thought all hosts filter out the clock like AB. I just checked and AUM doesn’t. So you could host streambyter as an AU and filter the midi there. It has the advantage that AUM has AB state-saving. So , you could save the complete setup in an AB document.

    Correct, AUM doesn't filter out clock, but there's one big limitation. It doesn't route clock between AUv3 apps. It can route clock to external destinations but not between plugins. So, you can go from AUM to Streambyter AUv3 but not from Streambyter AUv3 to BeatScholar as an AUv3. You could maybe send it to the standalone app, but then AUM wouldn't be needed anyway.

    Could midimttr route from the hardware midi in to streambyter standalone?

    I don't think that's necessary. Streambyter standalone should pick up the hardware midi without any issue. I think.

    If Streambyter picks up all hardware midi, you end up with the issue that it would pick up any other MIDI controller, too.

    I just checked and AUM lets clock be sent from one streambyter instance to another.

  • wimwim
    edited August 2023

    @espiegel123 said:

    @wim said:
    Btw … AUM > @espiegel123 said:

    @wim said:
    I’m fairly sure that MidiFire won’t be needed. Streambyter standalone can be routed to by anything and it publishes an output that can be seen by anything, including AudioBus.

    As long as the apps you want to start and stop can receive from Streambyter directly through Core Midi (not through Audiobus because Audiobus doesn’t route clock directly as I tried somewhat clumsily to explain above), they should work OK.

    I mistakenly thought all hosts filter out the clock like AB. I just checked and AUM doesn’t. So you could host streambyter as an AU and filter the midi there. It has the advantage that AUM has AB state-saving. So , you could save the complete setup in an AB document.

    Correct, AUM doesn't filter out clock, but there's one big limitation. It doesn't route clock between AUv3 apps. It can route clock to external destinations but not between plugins. So, you can go from AUM to Streambyter AUv3 but not from Streambyter AUv3 to BeatScholar as an AUv3. You could maybe send it to the standalone app, but then AUM wouldn't be needed anyway.

    Could midimttr route from the hardware midi in to streambyter standalone?

    I don't think that's necessary. Streambyter standalone should pick up the hardware midi without any issue. I think.

    If Streambyter picks up all hardware midi, you end up with the issue that it would pick up any other MIDI controller, too.

    So? Streambyter isn’t going to do anything with any other midi. It’s all going to go wherever it would anyway.

    I just checked and AUM lets clock be sent from one streambyter instance to another.

    Yes. I didn’t state that well since it’s been some time since I worked with it. What I should have said is clock can’t drive the tempo of another AUv3. Now that I think about it, I didn’t investigate whether it could start or stop them if they have sequencers. I also didn’t investigate AUv3 apps like Loopy Pro and miRack that have since shown the ability to act in new ways, such as enabling Ableton Link and Link Start/Stop within an AUv3 and using that even to set tempo and start and stop the host that they’re in.

    Anyway, it seems to me like this discussion is running a little bit astray. The OP hasn’t reported back on whether the simpler approach of just using Streambyter standalone is sufficient. And the discussion started about Audiobus rather than AUM, which the OP may not even own.

  • @wim said:

    @espiegel123 said:

    @wim said:
    Btw … AUM > @espiegel123 said:

    @wim said:
    I’m fairly sure that MidiFire won’t be needed. Streambyter standalone can be routed to by anything and it publishes an output that can be seen by anything, including AudioBus.

    As long as the apps you want to start and stop can receive from Streambyter directly through Core Midi (not through Audiobus because Audiobus doesn’t route clock directly as I tried somewhat clumsily to explain above), they should work OK.

    I mistakenly thought all hosts filter out the clock like AB. I just checked and AUM doesn’t. So you could host streambyter as an AU and filter the midi there. It has the advantage that AUM has AB state-saving. So , you could save the complete setup in an AB document.

    Correct, AUM doesn't filter out clock, but there's one big limitation. It doesn't route clock between AUv3 apps. It can route clock to external destinations but not between plugins. So, you can go from AUM to Streambyter AUv3 but not from Streambyter AUv3 to BeatScholar as an AUv3. You could maybe send it to the standalone app, but then AUM wouldn't be needed anyway.

    Could midimttr route from the hardware midi in to streambyter standalone?

    I don't think that's necessary. Streambyter standalone should pick up the hardware midi without any issue. I think.

    If Streambyter picks up all hardware midi, you end up with the issue that it would pick up any other MIDI controller, too.

    So? Streambyter isn’t going to do anything with any other midi. It’s all going to go wherever it would anyway.

    I just checked and AUM lets clock be sent from one streambyter instance to another.

    Yes. I didn’t state that well since it’s been some time since I worked with it. What I should have said is clock can’t drive the tempo of another AUv3. Now that I think about it, I didn’t investigate whether it could start or stop them if they have sequencers. I also didn’t investigate AUv3 apps like Loopy Pro and miRack that have since shown the ability to act in new ways, such as enabling Ableton Link and Link Start/Stop within an AUv3 and using that even to set tempo and start and stop the host that they’re in.

    Anyway, it seems to me like this discussion is running a little bit astray. The OP hasn’t reported back on whether the simpler approach of just using Streambyter standalone is sufficient. And the discussion started about Audiobus rather than AUM, which the OP may not even own.

    It sounds like the issue isn’t that AUM won’t route midi clock events but that maybe AUv3 tend to use host sync rather than midi clock coming through midi input ports. Is that it?

    The reason for mentioning AUM is that I have tested that AUM (or MIDI Fire) can get the filtered stream to Audiobus. And getting the filtered stream to AB was what they wanted. Maybe Streambyter standalone can do it. I didn’t test that (and that may only work if there are no other connected devices).

  • wimwim
    edited August 2023

    @espiegel123 said:
    It sounds like the issue isn’t that AUM won’t route midi clock events but that maybe AUv3 tend to use host sync rather than midi clock coming through midi input ports. Is that it?

    That is what I was trying to say. It’s been more than two years since I investigated. At the time I could find no apps that could sync via internally routed midi clock. There may now apps that can. I can’t say as I haven’t tested.

    The reason for mentioning AUM is that I have tested that AUM (or MIDI Fire) can get the filtered stream to Audiobus. And getting the filtered stream to AB was what they wanted. Maybe Streambyter standalone can do it. I didn’t test that (and that may only work if there are no other connected devices).

    I believe Streambyter can do that without AUM’s help. I don’t see any reason for the added baggage unless for some reason it turns out to be necessary.

    I have no further input until if/when the OP comments on whether things are working out or not.

  • Oh wow, what a load of ideas, thanks for all your insight :)

    @wim said:
    Anyway, it seems to me like this discussion is running a little bit astray. The OP hasn’t reported back on whether the simpler approach of just using Streambyter standalone is sufficient. And the discussion started about Audiobus rather than AUM, which the OP may not even own.

    I will test this in the next 2 days and see how it goes with Streambyter. And you are right, I don't own AUM currently. As my use-case is quite narrow (syncing Beat Scholar to Traktor/DJM), to me it looked like I could use either AUM or AB, so the decision fell on the cheaper app. Maybe that was a mistake but it's hard to field-test something that has no trial phase.

    @wim said:
    Correct, AUM doesn't filter out clock, but there's one big limitation. It doesn't route clock between AUv3 apps. It can route clock to external destinations but not between plugins. So, you can go from AUM to Streambyter AUv3 but not from Streambyter AUv3 to BeatScholar as an AUv3. You could maybe send it to the standalone app, but then AUM wouldn't be needed anyway.

    You are talking about the standalone app of Beat Scholar here, correct? That one sadly doesn't support syncing to anything, thats why I bought AB in the first place

    @espiegel123 said:
    If Streambyter picks up all hardware midi, you end up with the issue that it would pick up any other MIDI controller, too.

    That wouldn't be an issue in my environment. The setup I listed above is all I have running in live scenarios, besides an e-guitar which goes through NI Maschine (which is synced to Traktor via Ableton Link)

Sign In or Register to comment.