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
I’m pretty sure some of the bud apps got the fix but can’t remember which ones did and didn’t? I’m guessing any newer bud apps have that implemented.
So - it‘s january 2023 and i again retested the MIDI AUv3 without sample offset. And checked the MIDI Auv3s i newly acquired. Here the updated version of the list:
With sample-offset
.
Without sample-offset
Midi generators that don‘t set the sample-offset will produce sync-issues.
.
Could not check
I don’t own the following midi AUv3, so i could not check them. The ones marked with (X) are from a dev that offers AUv3 midi apps with correct sample-offset, so its likely their new apps also support it.
Textquencer from Cem Olcay (X)
.
Changes in this version of the sample-offset list
New in the list and with sample offset:
o LFOH
o Mela 3
o OODA
o Piano Motifs
o Riffler
o Scaler 2
Fixed:
o Arp Bud 2 v 1.7 - Note-ons apply sample offset, but note-offs don‘t.
o MIDI Tape Recorder v 1.0.6 - fixed sample offset playback even for older recordings
o PlayBeat 3 v3.1.7 - now sends all tracks to plugins midi output and applies sample offset
New in the list and without sample offset:
o MidiLFOs
This thread just makes me afraid to buy any more midi fx or sequencers. I don't imagine chordjam will ever get a fix. If we didn't have superheroes like @_ki, we'd likely all be shooting in the dark.
Do issues like this pop up for our desktop musicians? I mean, to worry that a midi app isn't going to actually sync properly is a huge deal and I have always just assumed that duh, it would work since it's being sold to sync.
Thanks so much for this incredible conversation and hard work! This is the stuff of ABF legend.
Thank you So much for this great and time consuming work @_ki. Just a little heads-up though that the font colour you use for your annotations is extremely small and quite hard to read in terms of contrast (unless I turn my phone contrast way higher than normal) when reading the forum in dark mode. Perhaps consider a different colour than grey? Thanks again, now we need to get checking on the ones you're not sure about and get the devs with problem apps to fix them.
As far as I know Mela 3 is under public beta but I can’t seem to find the link at the moment!?
@Gavinski Thanks for the feedback. I’m just using the ‚small‘ font that the forum editor offers. It seems that these use the same dark grey color in Light and Dark theme of the forum making them hard to read. Maybe @Michael can change this.
Your comment made me try around for alternatives - and I found out that the forum allows html tags for setting colors and font sizes.
I‘ll fiddle around some more and then update the above post for better readability.
@Samu Thanks for the reminder (i just updated from IOS 14.8 to 16.2 this weekend, Mela 3 required 15). The Mela 3 testflight is found on the FAQ page, i just tested that it applies sample offset and updated the above list.
Nice find! You're a star, brother!
Edit - sorry I noticed that Mela 3 midi fx is already in the 'works fine' list!
@tja The current list is now formatted using different sizes using the html „< font size=X > text < /font >“ tags and bold fonts instead of the forums < small > or markdown # title tags that additonally apply different colors which leads to bad readability in the Dark theme of the forum. Everything should be in the same default text color for both forum themes.
I am a bit sad that the list of pugins I can't test has grown so much over the years - but buying the n‘th LFO, step sequencer (even with a twist) or chord generator just for the sake of testing is a bit costly. I suspect that most of them apply sample offset, that‘s why i made the (X) a bit more prominent in the latest edit.
True, same with me trying to stay supportive of all new apps that drop...
...I just can't do it. I will not say no to 'promo codes' from devs but I will not beg for them...
(If a Promo code would drop as a PM here I'll at least consider spending some time learning the app and answering questions).
The 'Insta Buys' and 'Overhyping' of new 'Desktop Ports' is just lunacy and flock/zombie behaviour at its best...
...It's not like a new toy will automatically make everyone better even though that is the 'image' that is sold with most new apps.
(Buy this or that and sound like the Pro's etc. etc. etc.).
If the flies are right we'd all be eating sh*t for lunch...
Cheers!
I think if you contacted the devs whose apps you don't have and showed them the work you've done, the value of it, and the fact that its in their own interests for any issues to be identified and fixed, they'd quite happily give you free codes Ki
Is this broken again? In this thread, it is being reported as there being no offset
https://forum.audiob.us/discussion/comment/1160995/#Comment_1160995
No. MTR is not broken, the input recorded (AUMs keyboard) does not produce sample offsets for the notes.
.
In fact none of the AUv3 keyboard apps i have produce sample offsets for the notes issued.
I checked: AUM’s keyboard, Xequence key, Xequence Pads, KB-1, Velocity KB, Mononoke Pads, the keyboard and chord pads integrated in LK, Tonality ChordPads, ChordPadX.
Since none reports a sample offset, i suspect there is a technical reason. And this thread was about ‚sequencer timing’, so i didn’t mention the keyboards.
Explanation about the zero sample offset in keyboard and choard apps from SevenSystems:
Thanks for the explanation.
Thanks! I was just about to start looking into what might be the problem, and now I got a few hours back in my day
I wrote a blog post about this exact subject: https://cp3.io/posts/sample-accurate-midi-timing/. Hopefully it's useful to any developers.
@cp3 Thanks a lot for your blog post - it‘s a good description of the problem and explains how to fix the midi timing problems including various code snippets.
Time to add 4Pockets Midistep to the test queue.
OK so I now own 4Pockets MidiStep so can test and I think it’s midi timing might be off and playing late (0011). @_ki or @xor are you able to verify? Thx
I don‘t own 4Pockets MidiSteps (if you would have posted a week ago, i could have bought it in the sale due to your inquiry
)
The only tool displaying the midi sample offset of received midi messages i am aware of is the MIDI Monitor from Victor Profos MIDI Tools auV3 suite.
If the displayed sample offset is 0 for all midi messages send by an auv3 plugin while the hotsts transport is running, you can be sure that there will be timing problems.
Several of 4Pockets AUv3 midi plugins issue the sample offset correctly, so i would expect MidiSteps also supporting this and not showing timing problems.
Midisteps is always very slightly behind from what I can tell (1 is Atom, 25 is Midisteps)
@gusgranite That MidiSteps offset could result from the execution order of plugins (Maybe Atom is executed before Mozaic and MidiStep after Mozaic so its events are received one buffer too late)
Does anyone own 4 Pockets MidiStep and Victor Profos MIDI Tools ? Please route the midi output of MidiStep to the MIDI Monitor and check the the displayed sample offset - for the midi events. They ahould mostly be non zero and change.
I own Midi Tools but it wasn’t showing up on my new iPad. Just reinstalled and restarted and all good.
Here’s Midisteps
Here’s Atom for reference
@gusgranite That‘s strange that Atom always supplies a 0 for sample offset. Are these really notes send out by a recorded sequence in the piano roll ? New notes played from a keyboard (virtual or real) will always use 0.
Or maybe you mixed up screenshots and MidiStep is using zero ?
What is the sample rate and buffersize of your device ?
.
I just verified, on my iPad 10.5 both Atom 1 and Atom2 are sending non zero sample offsets. In the following screenshot both are emitting a 1/8 long note per beat in a 2 bar loop. I cleard both monitors and started AUM play and then after about two bars pressed Pause on each of the MidiMoitors and scrolled to the start of measurement:
As you can see, both Atom versions supply a sample offset and the offsets values are also about the same for each of the note on/off events. (because both pianrolls use the same note starts and length)