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
The new PlayBeat 3 also goes into the list of ‚AUv3 generators with sync problems‘. I informed the dev AudioModern on their own forum - perhaps this stirs up some change (maybe also for Riffer)
.
If @cem_olcay would fix his midi output code in his AUv3 generators, the list of problematic plugins would get a lot shorter at one strike
Has anyone tried this MIDI Sequencer Timing Tests in other AU hosts such as Audiobus and apeMatrix?
Since this test is made for AUM, it may be worthwhile checking the other two popular AU hosts.
From an old post from last year:
Here's the test for AUM: https://forum.audiob.us/uploads/editor/uq/g5al55vr05cg.zip
Developers, here's the code to fix the issue (from the developer of cykle & polybeat): https://github.com/cornedriesprong/CPSequencer/
Meanwhile i bought polybeat (dev: Corne Dreysprong) and checked it with the posted synctest - it‘s using sample-offset for the note-ons, the note-offs use an offset of zero.
@cp3 I don‘t know it this could result in an OFF with offset=0 activated before a ON with an offset>0 that was supplied before the OFF . Maybe also add a sample-offset to the note-offs like Rozeta does.
Thanks @_ki & @Sequencer1 this is important. I’m really Hoping the listed developers can incorporate this, since I use, or like to use a lot of the apps on the list…
A few months ago he actually mentioned to me he was going to look into this in a DM, but I haven’t heard anything since. I do believe he is working on something so he is probably busy. Hopefully he sees this and finds the time.
For those of you who don’t want to deal with trying to interpret the output from MIDI monitor apps, setup two MIDI sources— one with sync offset for sample buffering compensation and another without it. Route them to two instances of a MIDI controlled sound generator with a short percusive sound and route them to the same output. Press play and let the drift begin.
2.5 hours, I’m curious how far in was the moment in time when you first noticed or monitored a shift? Or is it something that starts immediately but progresses very slowly over time? If so I wonder how long an app is in sync before the difference is noticeable? I guess each would be a little different…
It gets worse over time… how long it takes to notice will depend on multiple things… tempo changes during the set will make it worse / noticeable earlier, several sources of varying differences and you track falls apart, some are more sensitive to these issues than others (many don’t even notice it until it’s super obvious).
@Poppadocrock for me it was noticeable after about 5 minutes. The drift ahead of the beat is continuous and steady with Polybeat 2. I really am not comfortable with having to monitor how long I’ve had a sequence running when there are so many MIDI apps available that do the adjustment for me. I like to develop a beat and then riff on it which isn’t so fluid with MIDI apps that don’t have sample buffer compensation.
Nudgey nudge nudge 😘
Hello people,
Timing issues for Riffer have been fixed. Kindly update to the latest 3.1.3 version.
Thank you!
Edit:
Updated Riffer, ran it standalone, force-closed it, memory reset iPad, rebooted iPad, tested in AUM with no other apps open.
Drift is still a problem at 44.1kHz. 48kHz is much improved.
2018 iPad 6th Gen; iPadOS 15.2; Audio: Internal iPad audio, no external peripherals; AUM 512 sample buffer, tested at both 44.1kHz and 48kHz.
@ocelot In my tests with AUM 44.1 khz and 512 / 2048 buffersize and the AUv3 Riffer v3.1.3 the plugin was computing the correct sample offsets in its midi output and stayed in sync.
I was using my standard sync test session with Plectrum AUv3 and midi input from both Rozeta X0X (808 timing off, sending C2 on every beat) and Riffer (sending C3 on every beat). The sample offsets were checked with MIDI monitor AUv3 iPad Pro 10.5 / IOS 14.8
How did you check for the timing/drift if no other app than AUM and Riffer was used ?
Hi @_ki,
I used the attached AUM session with the AU plugins, and my ears. And the AUM metronome. Riffer triggering Troublemaker. (Playbeat and Ruismaker Noir as well). (btw, It's been over 2 years since I sent all this to Audiomodern, yet this is the first acknowledgment I've heard from them).
At 44.1kHz - drift after ~50bars at 120bpm is very apparent.
At 48kHz - no noticeable drift after 100 bars at 120bpm.
Swapped Troublemaker with Plectrum. Only Plectrum and AUM metronome is audible. (Playbeat + Ruismaker Noir are muted).
At 44.1kHz - drift after 40bars at 120bpm is very apparent.
I just checked your session. On my iPad Riffer stayed in sync with AUMs metronome and Noir. I checked up to bar 150 for 512buffer/44.1khz
PlayBeat didn load a sample, so i choose a short hihat for slot 3. Since PlayBeat isn‘t yet updated with the sample-offset code, it went out of sync as expected. AudioModern confirmed in their forum that PB’s timing will also be updated.
Audiomodern is quite responsive on their forum.
.
@Audiomodern
With a setting of 2048buffers and 44.1kz Riffer v3.1.3 started to drift. I wrote a minimal Mozaic script measuring the timing between the note-on and the OnNewBeat.
When starting a test run with 2048buffersize , the delta output is around 512ms (one beat takes 500ms at 120bpm). But after i while it gets lower to 420ms around bar 100 and down to 325ms at bar 200 which is then also clearly audible as 1/8 offset to the metronome or Noir.
The ms offest to the last beat should stay constant at around 500ms. Mozaic‘s timer value isn‘t updated in every msec, so there might be +/-15ms difference, but no constant drift to lower values when playing for longer time.
The drift at 44.1kHz is very apparent after 40 or 50 bars, on both of my iPads, which natively run at 44.1kHz (and are switchable to 48kHz), unlike the later iPads which are locked at 48kHz, when using the iPad speakers or headphones with 3-pole 3.5mm jack.
Which year/model iPad are you testing on? Edit: iPad Pro 10.5 / IOS 14.8 Hmmm, very interesting.
My setup:
2017 iPad Pro 10.5 and 2018 iPad 6th Gen; iPadOS 15.2; Audio: Internal iPad audio, no external peripherals; AUM 512 sample buffer, tested at both 44.1kHz and 48kHz.
Latest Tests -
Memory reset iPad, rebooted iPad, enabled Airplane Mode.
AUM at 44.1kHz; 512 sample buffer. Riffer>Plectrum against AUM's metronome -
Drift is apparent after 50 bars - both ahead and behind AUM's metronome, and gets sloppier as time marches on.
apeMatrix at 44.1kHz; 512 sample buffer. Riffer>Plectrum against apeMatrix's metronome -
No apparent Drift after 100 bars.
Audiobus at 44.1kHz; 512 sample buffer. Riffer>Plectrum against Ruismaker Noir preset 'TEST CLICK' -
No apparent Drift after 5 minutes.
@ocelot Now with my measuing script i also can confirm that there is a drift at both 512 and 2048 bytes sample buffer size - i don‘t know why i didn‘t notice that on my first testrun when only listening to the troublemaker note vs the Noir click and metronome.
When using X0X note C2 and Riffer note C3 into a single plectrum AUv3 instance with a supershort click noise its a hell more obvious than with two totally different sounds.
.
I updated the AudioModern forum with the new infos about the drift problem still present in v3.1.3 even though i hate to be the bearer of bad news, just after starting to celebrate the sample-offset implementation 😢
@ocelot So you detected no drift when using apeMatrix or Audiobus ? Only when using the Riffer/AUM combination . Thats weird. @j_liljedahl
.
I just checked on my side with Riffer v3.1.3 and the Mozaic script and you are correct. apeMatrix shows a constant offset of around 500ms and AudioBus an offset of 0 or 1 (meaning the note-on happened right after the beat change, while in apeMatrix or AUM the host changes beat right after that note so its a full 500ms offset)
I noticed some odd timing issues with Chordbud 2 feeding Rozeta Arp, this is because of those specific issues mentioned here. Please @cem_olcay your apps are amazing but can you fix this? I can’t stand midi timing approximations, they drive me 🌰 !!
Thanks @_ki. Yes, no apparent drift in apeMatrix or AudioBus 3 - only apparent in AUM (EDIT: at 44.1kHz, not 48kHz) with the apps you listed. But I'm using my ears, since I don't know Mozaic.
Is your list current? (btw, both cykle and polyBeat by Corne Driesprong have tight-timing, like the Bram Bos apps now.)
Some folks may think that tight-timing after many bars is a non-issue, but for the folks who use polyrhythms and polymetric rhythms, where rock-solid timing is crucial, the drift is apparent much earlier.
Thank you, gusgranite, and the other folks for bringing this to light.
The list of 28.october is the last one posted. I confirmed polybeat on 11th november, but didn‘t post an updated list.
Fixing the drift on Riffer will first need an idea why it‘s happening in AUM and not in the two other hosts.
Awesome thank you @Audiomodern
Now the others will follow.
Yes. @cem_olcay i know you’ve been busy and it’s the holiday season. You’re apps are so amazing, and I love using them, but it’s hard to use them for a session without having to record the midi somewhere because of the time slip. they just need one timy sample accurate timing fix. Please see this entire thread, since the solution to the problem is provided on GitHub. Cheers man hope to hear from you soon. Happy holidays!
Rather than using a script, the way I prefer to test is a known accurate sequencer triggering a sample in a known good player, panned left, and the app to be tested triggering another instance of the same sample/sampler panned right. The resulting mix down from the host makes it easy to zoom in on timing errors.
I like this method better. Maybe it's just because I don't always trust my code and have even less reason to think a developer would trust results relying on my code. Or my ears for that matter.
Okay, i re-did the whole test and build an AUM session from scratch (not using Ocelots AUM session), where X0X sends out note 36 on every beat (808 timing off) and riffer sends out a note 37 (C#1) on every beat.
i made two test sessions:
First session where both instances send to Koala which contains a the same short hihat in slot one (note 36) and two (note 37). Slot one is panned fully left, slot two panned fully right. Koala‘s output is fed to Oscilloscope AUv3 showing L&R. Both X0X and Riffer stayed in sync for more than 200 bars.
Sesond session where X0X send a note 60 on each beat to a Plectrum instance (default setting but feedback = 60%) panned left using AUMs stereo balance and Riffer sends a C3 on each beat to a a second Plectrum instance panned fully right /using AUMs stereo balance). Both Plectrum route into mixbus A, mich then contains an Oscilloscope AUv3. Riffer and X0X (and the metronome) stayed in sync for more than 200 bars.
.
I then reload your session and re-did your test - Riffer went out of sync against Noir, the metronome and Troublemaker. Very, very mysterious. Readling my test sessions and checking again didn‘t show sync problems. Maybe i‘ll post my two AUM sessions (and the hihat sample) later, so that you @ocelot or @wim could check on your side. I also checked AUM with/without link enabled which made no difference. I‘m confused now 🤔
.
Latest test: I updated ocelots original AUM session with two Plectrums, one left driven with by a new X0X instance, the other on the right driven by the existing Riffer instance. Bam - the drift is 1/16 after around 130 bars. There must be something wrong stored in that session, as in my fresh sessions didn’t show drift.
@j_liljedahl I now have two seemingly identical AUM sessions:
One based on ocelots session showing timing drift between X0X and Riffer. The drift is 1/16 after around 130 bars
One build from scratch with the same plugins, routings, settings - without drift
.
AUM X0X/Riffer/Plectrums Session with drift
AUM X0X/Riffer/Plectrums Session without drift
Clearing the AUM session and importing the 4 channels of the ‚drifting‘ session (instead of loading that session) will play without drift.
.
I attached both sessions, can others please test run them (to around bar 130) to check if they show the same mysterious drift/no drift and perhaps @j_liljedahl could you have a look into the session file where this different behaviour might come from ?
I'll have a look. But I don't have Riffer and can't find Oscilloscope AU on app store. You have a link?
It's Oscilloscope and Spectrogram by Mani Consulting.
@j_liljedahl Here a link for Oscilloscope & Spectrogram AUv3. I asked AudioModern to send you a promo code for Riffer on their forum.