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
just to be sure - do do you use latest 1.0.3 version ftom appstore or some version from TestFlight ?
Try delete bith AUM and AudioPipeline and reinstall them again just in case it is really some cache (unlikely but I saw weirder rhings already than this so, worth to try)
It’s version 1.0.2 installed yesterday from App Store. Perhaps 1.0.3 hasn’t got through Apple yet. There was a buggy version of GeoShred that took 10 days for the fix to get out a few days ago.
I’ll try the reinstall after making sure my main AUM Session files are backed up
On a side note @rewolf48 - the power/noise issue is common when powering iPads from mains. If it's possible to power the iPads via battery bank, you might be able to eliminate that issue. That's what I do, though there's no mixer involved so my case might be different.
I have a power bank with 4 outputs, and tried that with 1 each for the iPads, plus 1 for the Zoom L6 max that would otherwise be drawing power from the iPad connected over USB. It’s the combination of iPads plus mixer on shared power that causes problems. The power bank can charge and discharge at the same time.
What really started me down this route was wanting to avoid a couple of minutes every rehearsal or gig (especially shared stages), getting everything talking to each other over BT MIDI. I addition to the Pro and Air there is also and iPad running OnSong sending scene changes for each section into the Pro (MIDIMixer), an m-Vave Chocolate talking to that iPad (Next Section, etc), and a Sonicake Pocket Master for Guitar, all also doing BT MIDI. I just wanted to plug it in, open one App (per iPad) and it just works. The audio was just going to be a benefit off network MIDI, but I haven’t got that working either! AUM BT MIDI just works as long I remember which connects to which or define both and duplicate the routing.
What I love about AudioPipeline is that it just reconnects and carries on working - WiFi, Ethernet or USB connections. Just need to sort this latency compensation problem
do you get same big latency also in case you have ampty project, no other plugins judt AudioPipeline Receiver ? Also there are 2 Receivers in package - one is instrument, one is effect - both of them are adding same latency ?
There is no latency reported on the send. I tried both Instrument and Effect, but unfortunately they are the same.
On the receive side with a new install and only including receive (either as the source or as an inline node) the latency is still reported as 244.6ms (WiFi). I have a video of a reloaded receive slowly accumulating reported latency in AUM if it helps. The actual delay for the pipelined audio is like a slap back delay which I expected over WiFi.
I haven’t re-installed on the send side, But I discovered that I can’t set the sample rate in AUM even in a clean session with nothing loaded. When I tried the AudioPipeline sample rate conversion option the Receive couldn’t see the Send (even when set to 48K in a 48K session), when I unchecked the conversion option they reconnected.
i know about 48k -> 48k I was just to lazy to fix it yet, cause it's edge case anyway
))) Normaly this is used for case when sender and receivers are running in hosts which are really running on different sample rates, to solve problem that LINK AUDIO protiocol itself doesn't do anything to match different sample rates.. In case both sender and receiver are runnong in host with same sample ratee you don't need to enable it, then this entuire adaptive resampler is just bypassed.
Sorry but I am out of ideas, i don't know from where such big latency comes. There must be something outside of plugin on that iPad pro which causes that Link protocol simply delivers audio into my plugin with such massive latency ..
It's not the actual latency - which is fine when wired; it is the latency that AUM thinks is being reported, and it then adjusts the other channels so they are aligned. I have reached out to Jonatan at Kymatica to see if there is a way to disable the AUM Latency Compensation; if so it doesn't matter what the reported latency is because AUM won't do anything with it.
Latency compensation is required if everything is sequenced - to ensure the results are all in sync, if slightly delayed. It is not wanted for instruments being played live (GeoShred or any Soft Synth controlled by Keyboard)
@dendy : I am also seeing a reported latency on the order of 240ms via wifi OR wired connection sending between iPhone and iPad. As I understand it, AUM uses the latency reported by the plugin itself and doesn't do any latency measurement of its own.
By a wired connection (USB-C to USB-C) the latency initially shows as around 100ms then climbs to 240-ish ms.
This is correct behaviour .. Audio comming into Receicer from Link AUDIO api is stamped with timestaps, my Receiver measures the delay of received audio (adds a few ms of internal processing latency) and reports that latency to HOST .. This value may fluctuate from beginning so this is OK. All what you describe indicates like everything is running correctly at the side of plugin and at the side of AUM - big question is why the audio which is coming into plugin from Link AUDIO api is so delayed. That is real problem. Latency reporting to host works correctly.
I still think it must be some networking problem either on the side of your iPad or on the side of your router. The delay you see in AUM is real thing, if there was not such delay on audio comming into Receiver, Receiver wouldn't report that big latency into AUM.
Sender doesn't introduce any delay, it just sends all audio into Link API. It's Receiver audio where delay is created, simply becasue when Receiver reads audio from Link AUDIO api, it is delayed. If AUM skuips delay compensation, that doesn't kill delay - it's just that rest of plugins in session starts to be out of sync with audio comping from Receiver track.
Hope that makes sense.
I hit into something !! Will let you know, later will relelese new TestFlight build and you guy can test it if that helped. Will be back after few hours
I will need an invite for Test Flight please
@dendy I will need an invite for Test Flight please
My day job is in IT, and we deal with distributed systems across many time zones. Even devices that are supposed to be synchronised with UTC will drift… if you are basing the latency on receiver on a timestamp from sender that will have to assume that their system clocks are aligned. I don’t know enough about iPadOS and iPad internals to offer any detailed suggestions.
Conceptual suggestions:
1) Getting the timing of a full round trip assuming that receiver can talk back to sender
2) Advanced Option on Receiver to manually set the Reported Latency
hmmm, seems a lot like AudioBus to me...and, unless I read it wrong, you also need a DAW and the local network wi-fi....what if you are on stage and NOT having access to wi-fi?
I won't use anything that needs actual wi-fi network at gigs. It is too flaky.
This app is AUv3 plugin so yes obviously it needs AUv3 host (it doesn’t need to be DAW) - that’s the entire point of app, to be plugin 🤣
Also you can connect two devices directly using USB -C cable so no, you definitely doesn’t need wifi, in fact I totally agree wi-fi is basically unusable for real music making due to latency.
well, AudioBus does not NEED a DAW and does the same job standalone! Makes it the winner in my book, even if this is free, does not make it useful!
btw, your infantile first sentence was uncalled for as I made no reference to that at all. And you made no contradictions to the wi-fi required either!
ok, moving on. This app is a "nothing to see here" - You can reply if you want, I won't be reading it as I will not re-visit this thread. It is what I think, and nothing more.
This system has nothing to do with device system clock. Therr is single source of truth sbout timimg and that is Link itself.
Simple explanation how it works:
per render block it measures full transit as “render-time − sender’s-intended-play-time” (reconstructed from the shared Link beat clock), EMA-smooths it and then on every change above 1ms reports it to host at approx 1hz freq (to avoid too much spamming host)
Process HOW it is done is flawless in principle, does not need to be improved and manual overriding would make things just worse….
only problem is I had bug there and I think I found where :-)))
Patience. New version 1.0.4 is in TestFlight approval process. I believe this will fix it.
I think you misunderstand what this does. It is primarily for piping audio between devices using Ableton’s new protocol for sharing audio streams between link clients. Many people want to send live audio back and forth between their devices in real-time. This is for them. Audiobus was audio on the same device in the days before Inter-App Audio.
Just for informational purposes ...
I wouldn't use WiFi at a gig either, but it is simple to set up a private standalone WiFi router to avoid reliance on house wifi if that's appropriate. Also, Link Audio can work over wired ethernet. That has the added advantage of adding lots more cables to trip over for a little comic relief for the audience. 😉
All that is needed is a USB cable. Ableton link and network midi work over USB. My understanding is that it creates an ad hoc Ethernet connection.
@rewolf48 @espiegel123
1.0.4 beta .. is +240ms latency problem solved ?
https://testflight.apple.com/join/fCSxQfwu
That's only applicable if you only want to connect two devices.
seems solved for wired connection. I am seeing 6.5 - 8 ms reported
Updating using TestFlight
And I am seeing 38ms via wifi
That was from my iPhone 16 to my iPad Air M2. But I just tried from my iPad 6 to the air and am seeing 220-240 ms.
dumb question but are you sure you updated to 1.0.4. beta on both ? :-) If at least at some combination of devices problem disappeared, other one may be completely unrelated to this bug.
1.0.4 beta 1 on all three devices
@dendy : interesting wrinkle. Pipeline receive on my iPhone 16 running iOS 26 shows latency 21 ms receiving from the iPad 6 (iOS 17.x). But in the opposite direction, iPad 6 shows the latency of 246.9. The iPad 6 as receiver is having a lot of dropouts.
While the iPhone 16 can send to the iPad 6, it is not seeing the iPad 6's send node when I try to pick a channel.