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.
BeatMaker 3 - External Midi Clock sync
Hi Forum!
I love Cubasis but sadly it does not sync to an external midi clock (sad face). But when we do jam sessions I need to sync to an external clock. Well, Beatmaker 3 is on sale right now and I was reading lots of good things about BM3 here on the forum. So I would like to buy it but I was not able to find info about BM3´s capabilities regarding MIDI clock sync.
So I am asking you, dear forum community:
a) Can BM3 sync to Audiobus and/or AUM MIDI clock start/stop with tempo (BPM)?
b) I have an iConnect Audio 4+ plugged into the Ipad. Can BM3 sync to a MIDI clock on the iConnect Audio 4+ MIDI IN?
(that does work for me with Korg Gadget for example)
Regards,
xlodx
Comments
There is no clock in/out in BM3.
It will respond to incoming transport messages though, also there is Link so with these two you can make it work. (using together with something that has midi to Link).
Not ideal, so hopefully it will come sooner or later.
Thank you @recccp for your answer.
I found an app called MIDI Link Sync and Link to MIDI. Has someone here made BM3 or Audiobus work with an external midi clock source using a Midi to Link bridge?
@Sebastian : It would be relay nice if Audiobus would be able to sync to external MIDI Clock
Edit: There is already free code for this on Github:
https://github.com/michaeltyson/TheSpectacularSyncEngine
Yep.
Transport from Octatrack starts BM3, MIDI Linc Sync getting clock from OT and sets the clock for BM3.
It's not perfect but for the time being it's ok.
Hopefully BM3 will provide some sort of midi sync options in the future, but I don't think it's high on their list. Rigth now it's not the best out there if you are planning to use your hardware. AUM+ModStep works better for me.
Does it work alright to just match the bpm, with the hardware you're trying to sync to, and it starts and stops with the midi start/stop messages? Does it drift?
Quartz crystal timing is accurate enough to keep a couple devices going at the same pace, to get through a song, as long as both handle their tempos accurately.
If you want proper MIDI Master+Slave sync you have to skip BM3 and use other apps like Genome Midi, Modstep or Music Studio, for example. That's very sad, I know.
I don't really understand why Intua have decided not to support it anymore - it was available in BeatMaker 2 and many musicians are unlikely to sell their hardware grooveboxes and sequencers that they will want to use together with BM3.
@Processaurus:
The developer must build his app to 100% follow some kind of reliable internal clock and follow that slavishly. I have seen many developers giving other threads too high priority (Display updates, storage, UI interaction) and drifting away too fast.
That's exactly what KORG did many years ago with WIST.
There are two issues with your suggestion:
1. Generally it's almost impossible to start two machines manually in sync because an iPad usually has varying latency between your finger hitting the glass and the app actually send audio to the audio output. But I know, you suggested 2)
2. It's rare to see an app supporting MIDI Status messages (START, STOP, CONTINUE) but not Midi Clock. It's possible of course, but only useful if 3) is taken care of:
3. If it drifts or not depends mainly on two factors:
A) the bpm must be adjustable with less than about 0.005% (or 50ppm) precision in order to really sync two machines tight enough for a long song.
And that's why it is better to implement proper MIDI Slave sync including some kind of clock smoothing, especially when audio data has to be stretched in Realtime (Loopy and Loopy HD can do this since years...)
Tight synchronization needs a proper app design and architecture, including a set of rules on how to handle CPU overload without running out of sync (by keeping the audio engine tight, at the cost of frequent UI updates etc.).
Although we have good 3rd party MIDI libraries for iOS development, for my taste still too many audio apps have no MIDI support or can only send but not receive Midi Clock.
Midi Clock is the only way to sync an iPad/iPhone DAW with any desktop DAW.
Ableton Live with its included Ableton Link is an exception, but today many musicians use other DAWs than Live, and many discussions have shown that you won't make them switch DAWs soon
Yes, it works. And that's what I'm doing most of the time.
) out the clock quite well. I'm receiving better clock through bluetooth midi (Yamaha MD BT01) then from my pc for example.
Above mentioned method is used if I need Link for more apps/iDevices.
Also MIDI Linc Sync lets you set offset to compensate the latency, and smooths (not sure if that's the correct term
Reason has Link. And Maschine too, though many will claim thats it’s not a proper DAW. Edit: And BitWig has Link.
I have struggled with MIDI clock implementation myself. I think I have it as tight as possible on iOS now. My learning: you should blame the OS first, rather than the developers. iOS is certainly not a realtime OS and it has a habit of prioritizing many things over its CoreMIDI handling. No matter how the developer has set the priorities. Timer smoothing is always needed on iOS, but this will go at the expense of accuracy when following frequent tempo changes. This in turn will lead to drift too, and since MIDI clock can never resync this drift can never fix itself again.
My advice: use MIDI clock on hardware only, because hw devices tend to have embedded realtime-friendly software stacks. Go with the infinitely superior Link (or something else that sends timestamps) on iOS unless you really can’t avoid MIDI Clock. Hoping for a 100% robust MIDI clock on iOS is a pipe dream.
https://intua.net/forums/discussion/5673/midi-clock#latest
(Insert fanboy squeal)
I have supported a number of developers during implementation of MIDI Sync, especially Midi Slave Sync which is easy to explain but not trivial to implement properly.
Of course iOS is no realtime os but of course it's possible!
Otherwise no desktop DAW would be able to provide a stable in-app clock in any OS after Windows 3.1, when direct hardware timer access was removed for any user-level application.
Super-tight implementations exist since iOS4.2 and on iPad 1 in the shape of FunkBox, MoDrum, Loopy/HD, thor, Genome Midi, Nord Beat, Loopy HD, DM1, LP-5 Loop Sequencer, Yamaha MMS, or later releases like DM2 and Stroke Machine and others that I'm too lazy to look up in my test archive.
Markus Waldboth, the developer of MoDrum, BassLine and LP-5 had put up a tutorial a few years ago (still in the iPhone 3, iPod Touch 3 and iPad 1 times) on how to properly implement rock-solid MIDI Slave Sync in iOS. Those old apps still run properly on later iOS versions. Have you read it?
Not true. See the apps listed above.
Yes.
Yes, but I think most will accept this because tempo changes are rare in music production, besides the slaved DAW will always behave similarly so there's something you can do about it
Not true. There's a reason why this process is called "Chase Syncing" - your app has to catch up (at the speed determined by your smoothing algorithm) until there is no more drift, making sure no incoming Midi Clock pulse is missed.
Try some of the above apps and you'll see.
So if your advice is "don't use the iPad with your Octatrack, Electribes, Roland MCs, Yamaha RS7000 or RM1x, those great new Eurorack hardware sequencers ... ", then I must say:
Why in the world should iOS music app developers not support that?
Because they don't know how?
If that's the case, I guess we should open up a developer thread especially for Midi Clock Sync issues in order to bring more light into the subject and make the world a better one
Link is no replacement for Midi Clock. Please read the Link documentation.
Link is indeed superior in that it can support tight sync over WiFi, dynamic joining and leaving a Link group, and different group members becoming master or slave as desired.
Tempo changes have the same issues as with Midi Sync, the app has to "chase after" the new beat grid just like in Midi Slave Sync.
The good thing is that Ableton has told the developers exactly what requirements to follow, something that Apple has mostly missed to do in their CoreMidi SDK documentation.
Midi Clock is superior if you have to support any hardware groovebox, and if you have to start from within a song or pattern from a predefined, non-zero launch position.
Midi also supports absolute positioning within a timeline, while Link is designed to offer relative positioning inside bars and beats.
As simple as it sounds, being independent from any WiFi link, I would always prefer Midi Clock over Ableton Link when doing a live gig with some hardware.
Wanna come over?
I'll show you that it works even on an old iPad 1
As I said, I have MIDI clock in all my apps. I know how it works and how it is done. It’s stable. But it will always require workarounds on iOS. But obviously I’m talking about Clock without timecodes. Having timestamps makes it much easier to catch up lost time.
No matter what the Link documentation says, it is the superior alternative for syncing on iOS - by a significant margin.
If everyone was happy with Link in all scenarios, then this thread wouldn't exist.
With hardware grooveboxes experiencing a renaissance today, not supporting Midi Sync simply means that the app won't be able to play with these out of the box.
That’s true, for sure.
@brambos
Not sure if it was tweaked since it's introduction, but when midi clock first appeared in your apps and I have tested it with OT it was drifting really bad. +/-15 bpm sometimes.
Tried it standalone, in AB3, in AUM and the result was consistent. AUM clock out was introduced around that time as well and with same hardware and settings it was drifting +/-0.5 bpm.
I'm not sure if it's something on my part, so if it helps I can run few more tests.
I find that very hard to believe. Which app was that? And was that clock master or clock slave?
Both Ruismakers as master.
@AudioGus thank you for digging this - it sounds realy promising
That was the reason for my initial post. In our band an Electribe sends a MIDI Master clock for all others to sync with.
Maybe if someone comes up with a Link <--> Midi box (a dedicated piece of hardware in shape of a small black box
)
We tried to use the iPad (with cubasis) as master but there was a lot of MIDI clock jitter. Then we tried Korg Gadget as MIDI clock slave and it worked well. So we thought that maybe having a MIDI clock master with jitter is a more problematic then just one device with jitter while reviving. a stable clock generated by a hardware sequencer.
That started my quest for a iOS DAW capable of reciving MIDI clock (Gadget is nice but is a closed system).
@brambos
Just rerun the test. It is better now. Most of the time +/-0.5 sometime up to +/-1.5, barely showing the actual bpm set.
AUM Clock in comparison rarely moves from the set bpm, (when switching apps usually) and max +/-0.2.
My Air2 was acting weird so it's recently reseted. Also I think the previous test was done on iOS10+, now the latest.
What an app displays as BPM (and how often it updates this display) doesn't necessarily reflect the exact BPM it is detecting. I could round the BPM in my display to the nearest whole integer and only update every two seconds and you would get the perception of stability. Most important question is: do you actually hear jitter or does it sound stable?
In my tests it performed very well. I could hammer it with pretty radical tempo changes and it would always bounce back in time. But there are so many variables when it comes to MIDI between software and hardware worlds...
I think someone has already said it, but it is possible to sync 100% accurately to MIDI clock because each received clock tick corresponds to a fixed amount of time since transport started, so counting the ticks gives 100% accurate time.
It's almost impossible to implement MIDI clock + start/stop + spp correctly though by Googling or reading random posts... the only really good and comprehensive source is the official MIDI spec (600 pages or so
)... it goes into every imaginable detail and emergency and how to handle them 
Thanks a lot! Great to hear.
@xlodx
I have also thought about building such a hardware box already - that's maybe one of the few sensible applications for an old Raspberry Pi board
I'd like to start making a list of sequencers and apps that can slave to external Midi Clock reliably.
Everyone who has good experience with such an app please list it here.
Please only add apps that you have made sure they work well as a Midi Clock Slave, without skipping beats or otherwise wiggly behaviour, because not every app that lists "Sync to incoming Midi Clock" also works well enough to use reliably.
Also make sure that in your tests, you have used a stable Midi Clock source. You can use LP-5, "Midi Link Sync" or Arpist as little helper apps.
I'll make a start here:
FunkBox
MoDrum
BassLine
Loopy HD
thor
Genome Midi
Nord Beat
DM1
DM2
LP-5 Loop Sequencer
Yamaha Mobile Music Sequencer
Stroke Machine
StepPolyArp
Only if the duration of a quarter note remains constant. If tempo changes, so does the interval between clock pulses. Without having timestamps or timecodes it is impossible to calculate an accurate time if the incoming clock pulses are subject to jitter (or an aggressive smoothing algorithm), because the changing interval between pulses could be caused by tempo changes or by jitter/smoothing. The app can't tell.
But that shouldn't lead to drift. You know that each 24 incoming clock ticks, your timeline should advance by one quarter note. No amount of jitter would cause the timelines to run out of sync, or am I a bit dense right now?
EDIT: OK I think I got the message, people have already agreed that it is always possible to keep timelines in sync "in the long run", but not locally.
I think in the video below is a good description how to get a stable midi slave clock
https://youtube.com/watch?v=n3BGFAw1g2g
There is a link in the video description to a github.
@brambos : The example in the video shows a fast way to detect clock changes (at ~7:00).
@rs2000 : I can aprove Korg Gadget as rock solid MIDI clock slave.
Indeed. I always resync a few times per bar, but if someone gradually changes the tempo 20bpm over a period of 6 seconds it’s virtually impossible to stay 100% in sync all the time because the algorithm is constantly behind due to smoothing.
And when it comes to smoothing, you also have to decide if you want to optimize for small, subtle fluctuations or for big, sudden steps. Both require different smoothing parameters.
The best thing to do is probably to offer a slider "Smoothing for incoming MIDI clock: 0...100 ms" or something, so for stable MIDI clocks, that could be set to 0... but yeah, I know why I only implemented MIDI Sync master in Xequence