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.
AUM: Option to send MIDI clock permanently (do not start and stop with transport)
@j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.
Comments
If you have miRack Here's a bit of a kludge that might work but also might introduce instability ...
The first Clocked module runs with AUM transport. The second one runs all the time. The switch takes care of which module is sent to output.
Yeah, I know. There should be an option for that.
One easy solution to allow slaved devices to stabilize is to use one bar pre-roll.
The problem with the pre-roll is that you still have no clock before pressing start. I love jamming with my hardware synths, and in some configurations I need to be able to start and stop individual devices - including AUM transport. This is not possible with pre-roll. So I would highly appreciate hardware friendly MIDI clocking in AUM (ideally together with MIDI clock sync input).
Just curious, even if clock is transmitted always, how do you start in beat sync?
That's what the MIDI start/stop/pause/continue messages and additional information like the song position that can get transmitted via MIDI are made for. And in a jam, I sometimes do it by ear - specially when jamming with others.
And that's the problem. Some hardware sequencers support it but hardly any app I know does support SPP so I guess that's more like a theoretical scenario.
If you're able to start in time then by all means, go for it!
On hardware that supports it (Korg Volcas for example) I actually often use simple clock pulses instead of MIDI clock. That has the advantage that it is easy to start / stop and staying with the beat.
Yeah, MIDI clock 24 pulses per quarter notes is not easy to manually trigger in sync with the beat! I'd even say impossible, unless it's a very very slow tempo
AUM does send SPP, as per my interpretation of the standard it's sent on start if not starting from 0, and not sent for continue (un-pause). I don't see how SPP would allow you to start a device in sync with the beat, unless the receiving device keeps track of the current beat position while it's receiving clock?
There are many possible combinations of sending MIDI status messages and SPP.
One way Roland have done it in their workstation sequencers is to sync to bar/pattern boundaries by sending a STOP, SPP, CONTINUE sequence (all between two clock ticks!) to make sure the receiver starts in time at the correct position.
Interesting! I bet there are a few clock receiving devices/softwares that won't handle that well..
Definitely. Long time ago I worked at improving MIDI clock sync with the developer of Genome MIDI Sequencer and tested with many hardware sequencers and what was available on the Appstore and the only common denominator was clock and the status messages START, STOP and CONTINUE.
Some apps today have at least nailed this very well (standouts being Audiobus, Loopy, BM3, Grooverider and now Drambo too) but most others work better with LINK - certainly because its spec doesn't have so many options and the LINK clock has high precision and priority.
MIDI clock is just as stable when done correctly but it often isn't 😉
The big advantage of LINK is that anyone can join a synced session anytime.
But why not just send some occasional (bar/pattern) SPP without STOP and CONTINUE? That would allow the receiver to easily keep track of the current beat position.
Also, the Link-style individual stop/start in sync with the beat can totally be implemented in each receiver, even if the sender just sends a steady clock. Like this: a receiver of MIDI clock could have an option to ignore start messages, but still keep tracking the clock. The user could then press play on the receiver, and it could wait for a configured sync boundary and start playing in sync with the beat.
There are other advantages of Link. There is built-in latency compensation, it's easy to sync to the audio stream, it tells the exact position in beats instead of having to count ticks, etc.
Because by definition in the MIDI standard, sending SPP will only have a "set cue point" effect without forcing the receiver to jump to that position. A STOP and CONTINUE sequence will make the receiver continue from the location given by the SPP, hence the STOP => SPP => CONTINUE sequence like described above.
Hmmm. Just tracking the clock will only work if the clock stream starts with playback. Also, it's unlikely that a (flawed) receiver that might skip a clock tick here and there will reliably count clock pulses otherwise 😊
What can be done without SPP though is a quick sequence of STOP and START at the end of a pattern. This would require equal pattern lengths in the sender and receiver though.
Yep, a good SDK is worth a lot (although I have to say that what @Michael has provided for MIDI clock sync is nothing short of fantastic as well 😉)
That's not my interpretation. MIDI "System Real-time messages" include Clock (tick), Start, Stop, and Continue.
Song Positition Pointer is mostly used in conjunction with this, but in theory all it does is cueing play position for the next time playback is started (regardless of how it's started).
I agree MTC is a whole other protocol, used for syncing time code (for video/audio, not music/beat/tempo related).
Then there's MMC, which is yet another protocol, used for remote control of transport (play, rewind, stop, pause, rec, etc).
>
It would track clock and start, continue, and possibly spp as well. If it can't keep track of time with this, then it's flawed in any case. But my point was that it could skip starting its own playback on reception of Start message, to get the Link-style "jump into playback on beat sync" behaviour.
Oh yes, that's a good idea!