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.
How to deal with MIDI/Device latency?
Is there a way to deal with device latency in LP I have not discovered yet?
Here's the scenario:
1) External physical synth connected via midi as well as audio
2) I play something on the synth and record it via MIDI loop(s)
3) The loop plays back via midi out from ipad just fine...
4) I then want to "print" the audio to a new channel/color's audio loop, so I record the audio loop. That works, BUT there's obviously now "flamming" going on because (I'm assuming because the audio loops are playing back slightly out of sync between the audio and midi playback)
5) On most DAW's there's usually something like device latency correcting, etc. I'm not seeing that in LP. Maybe it just hasn't been looked into because obviously before there was midi it was not as important.
@Michael IS it there someplace, and if not, is that something that you may consider in the future?
I /think/ there may be a work around using some kind of complex follow action that turns off the midi loops once the audio finishes recording it's loop... But that's kinda beyond my understanding at the moment...
Thanks!
Comments
Is the situation that after recording, you have both the audio and midi loops playing at the same time?
Yup. Out of sync, and obviously the out of sync'ness right now at least is based on the devices latency setting. But like in Live, it's possible to do a "hardware device latency correction" so that they can be "nudged" so they play back in time.
Can you post a link to screen recorded demonstration? There should not be significant latency. I wonder if there is something else going on.
What buffer size are you using?
There is always enough latency to cause flamming. That has always been the case with Loopy and is completely expected if you ask me.
The real question is why someone would be playing back the midi/audio at the same time as the recorded audio. @MonkeyDrummer is it your intent to play them back both at the same time? If so I'm really curious why.
Or, is it just that when you finish recording, there's that space of time where they're both playing until you mute the source? If so, then the better answer is to set follow actions that stop/mute the source as soon as the recording finishes. That can work perfectly smoothly so that the audio loop takes over smoothly with no noticeable transition. I do that all the time.
@wim : I expect phasing, not flams. This is what I typically experience. there is one flam in the video at the first transition other than that there is phasing but no flamming.
https://youtube.com/shorts/eiy93_foyXg?si=PxHS4e6AuKfTuhyu
What is a flam but a slow phase?
And What phasing but really fast flamming?
We can go with phasing...
But still... I'm getting there's no way to correct for it in LP now...
You know me Wim... Nothing I do is normal.
Basically the idea is to play in live drum part on the Nord Drum 3P, take advantage of MIDI quantizing (this is technically the ONLY reason I waited for the midi looping) to build up a beat... Kick, then snare then hats, then mids then some more tops, etc...
Then bounce that to an audio loop.
Yes, I have no interest in having them actually play at the same time.. But they are gonna... So I figured I could minimize or eliminate the flamming/phasing (phlamming?
) until I deactivate the midi loop(s)...
Like I said originally, I'm pretty sure the solution will be to have a follow action on the audio-loops to kill the midi loop(s)... Just need to figure that out.
AUM can do some pretty decent latency correction...
OK, very, very fast flams. Phasing or flanging is the better term.
Not for what you're trying to do though since it can't do that type of recording and instant playback.
I'm still curious if the real issue is that you really do want to run both the source and recorded material at the same time or if you're just dealing with stopping or muting the playback of the source once you've recorded it. The answer to how to deal each is quite different, though both can be dealt with.
The solution is to stop the midi loop when the audio loop starts playing back.
If you do want to play both the source and the recorded material at the same time for some reason, there is a way to offset loops by a predetermined amount. Not the same as automatic recording latency adjustment though.
@MonkeyDrummer : I just checked in AUM and you will get the same sort of phasing if you record hammerhead (or the like) and play the recorded loop back at the same time as hammerhead.
This sort of phasing is to be expected.
The same is true in every DAW I've used on iOS, though I probably haven't tried every one I own.
Fwiw, the reason it matters is that flams (things that sound like double-hits/drum flams) happen when the time offset is much larger than these sort of phasing artifacts.
@MonkeyDrummer : phase artifacts are unavoidable even with latency compensation as there is inherent clock drift which is why you here some variation in the artifacts even when the offsets are less than 1 ms
In theory though, if it's a case of recording needing to happen a minimum of one buffer after playing from an internally hosted midi generator, and that was always the case, it's conceivable that @Michael could trim that one-buffer cycle off of the recorded loop.
I'm not going to argue the case, as it's only speculative on my part.
Some tiny amount of phasing would obviously occur unless everything was exactly sample accurate at all parts of the audio path. But it would be less.
That aside, volume will be doubled when playing identical audio from two channels at once, so it's hard for me to imagine a practical use case for doing so in the first place.
In a situation like this Loopy does take buffers into consideration when recording (as well as input device latency when recording hardware inputs).
You will find that changing the buffer size won’t affect cases like I showed in the video. With a buffer of 32, it will sound the same as with a buffer of 512.
(There is some buffer related latency in midi coming from Loopy AU in some cases that we will look into, but that doesn’t apply here.)
@espiegel123's slight phasing like shown in the video sounds like perfectly in sync for me, but since you said "flams", your delay must be much more noticeable.
@MonkeyDrummer
How is your synth connected via MIDI and audio?
How do you monitor audio? Is Bluetooth involved?
@Michael Would it make sense to auto-measure MIDI-to-audio round trip time using a percussive synth patch, to cover such scenarios?
Sending a MIDI loop to the synth for "printing" audio might then re-adjust the recorded loop boundaries.
I don’t believe so – as @wim mentioned, I don’t think it makes much sense to want to play both the recorded loop and the original instrument at the same time, because the best case scenario is that you’re going to get a doubled volume level.
I’m reasonably convinced that one should either not loop the source material and just have it playing from the source, or if one insists on recording it to an audio loop and then playing that, one should mute the source as soon as the loop is recorded so you don’t get a double signal (eg. via a follow action).
@Michael I can understand @MonkeyDrummer's desire to "convert" a MIDI loop playing an external synth into an audio loop that is still well-aligned with the other loops in a project, so he doesn't depend on the hardware synth anymore and he can free it for recoding more instruments/tracks/loops.
My guess is that something in his audio/MIDI chain is introducing the unexpected latency.
Absolutely, totally valid use case: but the answer is to mute the source once recorded to avoid doubling, not to focus on perfect alignment which, best case scenario, still causes doubling. There’s already a supported feature set to facilitate this use case, with several solutions including a follow action to mute the source.
Unless I’m missing something, that is.
Longer term it might be nice to add a “bounce to audio” feature for midi clips which does an offline render then replaces the midi clip with an audio one.
@Michael I'll better let @MonkeyDrummer respond, maybe I got it wrong but to me it sounded like the recorded loop was audibly out of sync with the existing loops in the project, even after muting the hardware synth source.
Beautiful! Yet this would need latency correction as well, and I suspect that there might be an unknown amount of latency introduced by the hardware chain that would need to be measured first.
The recorded loop posted in this thread is mine and is not out of sync…as I said there is no flamming within the loop and the phasing is not latency. AUM behaves just the same. The solution as discussed from the beginning is to mute the midi loop.
We haven’t heard a sample from monkeyDrummer.
(Btw, offline rendering is planned but you still might have phasing)