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.
Comments
@j_liljedahl : in case you missed this thread, there is a bug with regards to the length of recordings made when the loop quantum is greater than 0. At 44.1kHz, recordings are too long. How much too long seems to be a function of the number of bars of the recording and at any BPM, the error is constant as a % of a single measure. People are reporting that when the sample rate is 48 kHz that the loops are slightly too short.
One thing i really love with the latest updates from Lumbeat’s drum apps is the ability to export perfect loops as audio or midi.
Interesting. What buffer size are you using? I used the same setup (though iSO 13.5) but my loops are all off. I also was using Audioshare to see the length i terms of beats.
Glad to hear you’re getting perfect loops @ReflectiveHaze
There must be a setting I’m missing...or could it be related to os version perhaps?
Drag the out point while in Trim/Fade mode and it will snap to a perfect loop point. Save and problem solved. I had a number of loops slightly over. Did a quick trim in AS and then checked them both in Auditor. Results were consistent. The original loop was slightly long. Trimmed loop was right on. I am on 44.1 devices across the board FWIW.
Have the same problem when recording in AUM using sample rate 44100 Hz. Tried different buffer sizes and bit depths. But when I switch to 48000 Hz - everything is fine and loops are just perfect.
Using iPad Pro and OS 13.5.1.
How many measures had you set the quantum to?
Sure there is a workaround. It would be even better if one didn't have to use a workaround. I am guessing that once Jonatan knows about this that he'll be able to address it.
I upgraded to iPadOS 13.7 in the hope it would help, but sadly I'm still getting imperfect loops when recording AUM channels.
I find AUM to be the most fun and creative way to produce on iPad. would love to be able to get some clean loops so I can arrange/mix these stems on my laptop
Try these settings. Never had a problem with loops.
@jolico: if you read up-thread, you'll see that there is abi not related to the buffer or sample rate. The longer the loop is, the more extra time there is. On short loops it is inconsequential , but in longer loops it has to be trimmed.
Not for me.
I record short loops, long loops and entire tracks.
They all start and stop exactly where they should.
After doing some tests, it is related to sample rate. At 48k, a 64 bar recording is precisely the right length. At 44.1 kHz, the recording is slightly too long. The amount by which it is off is related to the number of measures. Tests done on iPad 6 with iOS 13.7
@j_liljedahl : it seems like the record end time has some calculation that assumes 48k sample rate.
I can't reproduce this. Tried recording a 24 bar recording, sync quantum 1 bar, at both 44.1k and 48k. It loops perfectly. iPad Pro 1st gen running iOS 14.2 beta, but I'm quite sure it worked fine also on iOS 13.
PS. The calculation uses the actual sample rate, no assumptions.
Try setting the sync quantum higher. My steps:
This is 100% reproducible.
At 44.1k, 8 beats at 44 k yields a loop 16.006 seconds long 32.013 beats at 120 BPM) at 48k, loop is precisely 32 beats and 32 seconds
This might seem like a small discrepancy but if you leave those slightly long loops going they will drift noticeably.
OPEN AUDIOBUS
OPEN LOOPY IN OUTPUT
OPEN AUM
OPEN CHANNEL IN AUM
OPEN OUTPUT OF AUM AND SELECT LOOPY
PUT SOURCE IN INPUT OF AUM INTO LOOPY OUTPUT (Group the Loop and other Loop apps applicable)
LOOPING
ALSO- IF YOU HAVE AN INTERFACE- PUT BLOCS WAVE IN THE INPUT SLOT OF AUM. BLOCS WILL RECORD INCOMING AUDIO IN PERFECT TIME.
Btw, I just checked and the sync quantum isn’t relevant. I know that this length difference seems trivial but the result is sometimes picking up the beginning of new loop cycle that results in a click (which doesn’t happen at 48k) and that if you loop it for a long time (as in a jam), the loop will become noticeably out of sync.
16 measure loop at 120bpm In AUM ends up 32.000 seconds (64.000 beats) at 48k and 32.012 secs (64.025 beats) at 44.1k.
At 44.1k, a 64 measure recording will have a length that is 256.102 beats 2:08.051 secs
At 48k, 64-measure recording is 256.0 beats: 2:08.00 secs
If you change the tempo to 110 bpm. Number of beats at 44.1k is 256.103
At 240 bpm, the number of beats is 256.102 when 44.1k
Measurement mode and buffer sizes don’t matter
@j_liljedahl : do you get a different result?
Running iOS 13.7 on an iPad 6. The results were the same under iOS 12.x
I tried a sync quant of 16 and recorded one cycle:
44.1 kHz resulted in a file of 1 411 197 frames, which is 1411197/44100 = 31.9999319728 seconds.
Expected number of frames would be 1 411 200, so it's missing 3 samples there. Not as big difference as you got, and I don't hear it when looping.
48 kHz gave exactly the expected 1 536 000 frames.
I'll look into if I can improve this, but I have a vague memory that it wasn't entirely easy, and it might be because there is slight jitter from the clock coming from Ableton Link (which is used all the time even if it's not currently enabled and syncing).
There is something odd here. We are getting different file lengths when using identical params.
At 44.1k, 120 bpm, sync quant 16, my files are always 32.012 seconds long and 1,411,765 sample frames. I get the same result independent of whether or not Ableton link is enabled.
So, my files are more than 500 frames longer than yours with the same parameters.
When this was first reported, someone else was getting the same numbers as I was. And someone else was getting expected numbers.
This is strange.
While I was developing the first version of AUM I noticed that some device models had much more jitter between the audio timestamps mSampletime and mHosttime (IIRC) than other models. So this might be related. Even though we use the same software and parameters, you're probably on a different device model? I have an iPad Pro 12.9" 1st gen. I'll do the same test on my iPhone 7 as well and report back.
iPad gen 6 here. One notable thing is that the discrepancy only happens at 44.1 kHz.
And the number of samples recorded has been the same with every test which have been done a few different times over a few months.
Ok, I tried on my iPhone 7 and got exactly the same result as I got on my iPad Pro.
Ancient thread bump alert. I ran across this issue tonight. With sync quantum set to 1 bar in AUM Im seeing audio loops in AS that are a hair too long. Trimming em up in AS is not the end of the world but I’d love to skip that step if possible. First world problem I know. 🙂