Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Block incoming MIDI clock while keeping start/stop command
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.
The Streambyter code to block MIDI beat clock messages only is simple.
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.
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?
Btw … AUM > @espiegel123 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.
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.
So? Streambyter isn’t going to do anything with any other midi. It’s all going to go wherever it would anyway.
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).
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.
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
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.
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
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)