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.
AB3 into AUM Recording Problem
Hey folks, I've been having some issues for a while with recording in AUM. I had hoped the recent 1.2 update for AUM would resolve my problem but unfortunately it did not.
I have used Elastic drums for the screenshots, but the same results are for SeekBeats or any other drum synth. I have a simple kick hat 1 bar recording into AUM.
If Elastic is hosted in AUM with either IAA sync, or LINK, this is what AUM records
If Elastic is hosted in Audiobus3, and AUM is on the AB3 output channel, then AUM records this
So this creates very sloppy results if AB3 is used to host the synths or drums and anything is hosted in AUM.
Can anyone help with this?
Thanks
Comments
I personally use Patterning hosted in AB, powering Ruismaker hosted in AUM. I don't know how to address your situation though.
Looks like some kind of latency/buffer compensation issue?!
Quite a few apps suffer from this so I seldom record stuff live but instead try to use the export features when available. ED has pretty good export options straight into audio-share. After that it's easy to use the AUM file-player to play the file(s). Sometimes the link/buffer-timing can fluctuate and you get the first beats transient at the end of the recording causing clicky-clicky time, not so nice...
Does IAA host sync work through AB3, does AB3 forward the host sync from AUM to the source app? (I haven't tried so I don't know). Regarding Ableton Link, maybe AB3 adds additional latency that the source app doesn't know about, and thus the audio is delayed in relation to the clock? AUM adjusts the timestamp presented to the hosted nodes to include any additional latency introduced by AUM itself (due to plugin latency compensation etc), so it should "just work". Maybe AB3 does the same already, but those apps use something else for time reference than the provided render timestamps?
http://lijon.github.io/iaa_latency_comp.html
@j_liljedahl IAA host sync doesn't appear to work through AB3, only Link, but the timing is the same if ED is hosted in AUM, and it doesn't matter if its using IAA sync or LINK. The problem seems to be some weird latency from AB3 into AUM
I've noticed that the timing of linked apps in AB3 can change drastically when app switching in AB remote. Loopy is pretty steady but it's timing is noticeably behind Ruismaker inside AUM. Egoist just changes its first beat to a different sync continuum at random, when changing between apps.
Just looking into this now, guys - let me get back to you
@Michael, thanks, this has made combos with AB3 and AUM almost unusable for me. Hope you find the problem soon.
yeah i had similar problems, but i was sidechaining with AUFXPUSH, all apps coming into AUM from AB3, but AUFX PUSH running on its own BUS in AUM, timing was way off, moved everything into AUM and it worked a bit better.
i dont know, ive noticed some apps screw up more than others, when i introduced Blocs everything went really bad so i reverted to recording loops into loopy again and it was working better.
When you're using AUFX:Push with the limiter enabled hosted in AUM, AUM will compensate for the added delay caused by the look-ahead limiter. (Same thing if you use AUM's built-in limiter node, or enable the limiter in any other AUFX app). This compensation means that the current "now" timestamp must be adjusted so that apps using Ableton Link can adjust accordingly. AUM sends the adjusted timestamp to the channel sources, regardless if they're hosted directly in AUM or if it's an AB3 receiver port. I don't know if AB3 passes this timestamp as is to the apps hosted in AB.
I'm starting to think that ab3 doesn't adjust the time stamp. Timing is just plain better with all the apps hosted in AUM. Just wish state Saving worked for iaa apps.
@gsm909 Hey, are you able to measure that time discrepancy at all? I'm curious about its magnitude...
Never mind! Problem found and fixed, will issue an update soon.
Thanks @Michael , looking forward to it
@Michael, hi, wondered if you have an eta on this fix. It is still present in today's beta 3.0.4 (19)....No hurry, I know you're busy guys
It's going to require an update of the output app, I'm afraid @gsm909 - so the Audiobus app update won't immediately address it. There's another auxiliary issue I discovered we're still working through though so that'll be a little bit longer - want to get all our ducks in a row there before we ship the SDK update.
Thank you @Michael