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 effecting Xequence timing? Solved
It could just be my ears but wondering if any Xequence users can hear an occasional drift when using swing? Been testing with short sharp drum hits on fairly high swing settings to make it easier to hear. Sounds fine for a little while but seems lose it every now and again.
Might be ears playing tricks though…
Any findings appreciated, thanks
Comments
Record the audio and open the resulting audio file editor and you will be able to measure and drift.
Is that something that can be done in AudioShare? That’s the only app I have to record to (I think). Thanks
If the drum or synth app is IAA. What is hosting your synths or are you only sending the midi to standalone apps?
Apps hosted in AUM and Xequence sending midi to them.
AUM can record its channels. Just set AUM to record the drum hits. Then open that file in an audio edit or DAW. Any drift will be visible and measurable.
Ah, don’t have a daw. Only audio editor I have is AudioShare which I don’t think will do the job…
There are cheap and free audio editors available. If the drift is significant it might be visible in AudioShare if you zoom in where you notice it
Audioshare’s grid only seems to snap to whole notes and I’m looking for small discrepancies in 16th notes so no joy there. I could download cubase le but am not sure how the test would work.
Would you snap a marker to 16ths on the timeline? Does the timeline represent swing and how would it be matched to Xequence swing? Sorry if these are daft questions, not conducted this sort of test.
All you have to do is look and see if the spacing of the notes is consistent. Discrepancies big enough to hear are likely to be pretty noticeable.
There are some free audio editors if you don’t already have one.
I’ve bodged it in AudioShare as the discrepancies are just visible.
Image shows a simple kick on 1, snare on 2 and hi Hat playing 16ths. I’ve highlighted the hats and if you look at the furthest right set of highlighted hats they don’t match the others on the left and i can hear it skipping out of time.
The discrepancies look smallish but when something is swung and it’s not tight it’s very noticeable.
@SevenSystems are you noticing anything regarding this? Thanks
Thanks for the report and your investigation!
Can you make another test WITHOUT swing and check the resulting file again and see if the hats are then perfectly aligned to the grid? I just want to make sure that it's really due to swing and not a general timing problem.
No problem. Never noticed it previously. Maybe from a recent update or something..?
I jumped to the wrong conclusion and it is a general issue.
Image is same pattern but with swing set to zero.
It’s harder to see but if you compare the 2nd and 4th measure you should be able to see that the hats are behind on the 4th measure.
I can’t find anything in terms of when/why it does it like at a loop point or between copied parts. Seems to be random..
Thanks for replying!
@Zerozerozero . It might be time to mention your iOS/iPadOS version and device. Are you on iOS 16?
Thanks @Zerozerozero. I have seen timing problems with plug-ins hosted in AUM but controlled from Xequence myself recently, but had no time to investigate so far. It's good you're bringing it up though.
@j_liljedahl do you maybe have an idea what's going on here? I'm almost sure that previously, MIDI packet lists sent to AUM's virtual MIDI port preserved their timestamps and plug-ins were able to properly render their notes at a sample-accurate position in the buffer... this seems to no longer be the case! (maybe something in iOS has changed?)
Xequence as usual sends bunches of packet lists in advance with future timestamps (at least 100 ms in the future), this still works when eg. targeting Gadget directly.
Good point. I always miss this! Was on iOS 15 (iPhone 8+). Just updating now….will see if it helps .
Update hasn’t helped unfortunately…
You’re not wrong. Hosted drum machine in Audiobus and problem is gone…
No, unfortunately CoreMIDI -> AUM does not make use of the CoreMIDI timestamp, and never has. It's still on my TODO list to improve this, but I've actually never got any complaints so I assumed most users do not use this particular setup. Note that AUM -> CoreMIDI produces accurate timestamps, as well as any MIDI between AUv3 plugins and IAA internally within AUM, etc.
So for best timing, do not use schedule-ahead in the CoreMIDI sequencer (external hardware sequencer or stand-alone app using virtual MIDI ports), and use as low buffer size as possible in AUM.
But isn't Xequencer at least IAA? If so it should use direct IAA to host MIDI instead of going through CoreMIDI, which will be sample accurate and perfect.
Thanks for your feedback!
OK, that's surprising, I thought there had been a similar discussion here on the forum at some point in the past and it was confirmed that AUM did make sure they'd be passed on. I must be getting old (I definitely am, easy to prove mathematically
).
Maybe this is then indeed something that you could look into at some point.
To the contrary, I'd say this is actually one of the most common setups that AUM is used in, i.e. Xequence -> AUM via CoreMIDI and spread across 16 channels. Xequence's manual has an entire section on it even... so be assured it would make a lot of users happier if timing was more accurate (even if they don't realize it with their tiny buffers 😂)
It's only IAA "by accident" because of the Audiobus integration, but it doesn't use IAA MIDI (except, indirectly, when targeting stuff through "Audiobus MIDI".)
I don’t understand all the technical’s but sounds like fairly bad news for Xequence/AUM/AB workflow people and that a solution (if even possible) may be a while in the making.
As an aside the tempos of AB and AUM also don’t match. If you run identical instances of drum machine in both there is audible flamming.
@j_liljedahl is this to do with buffer settings or something else?
It might be easier/quicker for you to use IAA MIDI with sample offset timestamps in Xequence than me adding support for receiving CoreMIDI timestamps, queuing up events for the future and convert their timestamps to sample offsets. One problem is that CoreMIDI delivers the events "on time" to the receiving app, which means they are already too late, so I would need to add a fixed latency to shift them into the future.
I think you can receive CoreMIDI events ahead of time as long as you're being targeted (not listening to another source). You mentioned this on your blog a while ago:
http://devnotes.kymatica.com/ios_midi_timestamps.html
Or is this outdated?
(I'm not sure I want to add ANOTHER layer of MIDI support to Xequence -- it already has to support CoreMIDI and Audiobus MIDI... especially since IAA is officially deprecated. If I added anything, then I'd rather opt for direct AUv3 integration.)
Oh, yes this is correct, but since that bypasses the whole CoreMIDI event management it means even more work on the receiving end: there can be multiple senders connected to the same virtual input, so events can be received in any order. So then we also need a Priority Queue, and realtime-safe ways to deliver them to the audio thread just on time for the next audio render cycle, etc. A lot of work, and at the same time users are waiting for other more prioritized features such as MIDI Clock Receive, channel group tabs, etc.
I hear you. AUv3 FTW
@j_liljedahl thanks for the insight and your time. I totally understand. Maybe I should start a Kickstarter for a Xequence AUv3 version 😆
Just to recap for a layman…
AUM’s timing is working properly but only with AUv3 and not IAA. There are not enough people requesting this (+depreciation) to make it worthwhile for @j_liljedahl to implement. Incidentally reducing buffer size does help as stated above but does this tip apply to both IAA and AUv3? Obviously crackling increases with this and isn’t very practical so not sure it is working as it should (if it applies to AUv3 also)..?
There is more work involved in amending IAA in Xequence than making it AUv3 so AUv3 is way to go for @SevenSystems.
Happy to contribute to a kickstarter. It’s been requested by a fair few others so who knows..?
No, AUM's MIDI timing is sample perfect for both AUv3 MIDI and IAA MIDI, as well as CoreMIDI output. The only thing that is not perfect is CoreMIDI input (for example receiving MIDI from another app via Virtual MIDI). In this case, lowering buffer size helps.
Ah, apologies for misunderstanding. So just the specific thing of coremidi input. Thanks for explaining again. Don’t know if any other apps use this but good to be armed with the info
If AUv3 or Audiobus MIDI had been a thing when Xequence was first designed and developed, I'd probably have skipped CoreMIDI instead 😆 sorry for that!
Ha, not at all! Can’t do much about that!
Been using reduced buffer and to my ears timing not noticeable now. Have to be careful with cpu but rather that than change my workflow.
Happy to contribute to any updates as I’m sure others are. Whether it’s viable or not is another thing I guess. Different conversation but as the consumers we really should be paying more, otherwise where’s it going…?