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
New update, recorded in AUM, buffer at 64, still a significant lag:
Just for comparison, Noir looks like this, same setup:
Thanks for the up date @Philandering_Bastard
Was hoping it was fixed
Will not purchase till sorted
It's annoying that it got released like this, but as I think I pointed out earlier, if you like the sounds for £3 it's still worth having just to make your own samples.
Record a few (out of time) hits, Twiddle the knobs, chop them up and there ya go... You have your own sounds from a really nice, albeit currently flawed, app. And that solves the CPU issue too.
I do really like the sound. Still...
I'm starting to wonder if this latency thing is a fundamental flaw in AudioKit's AUv3 implementation?
(Does AudioKit time-stamp all the audio blocks it generates. If it does this timing thing would not even be an issue).
Anyways, I hope it gets sorted out as it does sound pretty neat and I have no intention to start rebuilding the sounds with Drambo...
Here’s the 808, driven by Rozeta XOX:
Weirdly, the latency goes UP when I reduce the buffer.
Did you disable the 'Simulate 808 timing' in Rozeta X0X?
Even when freezing the track in Cubasis I’m still getting 20+ ms of latency. 🤷🏾♂️
Oops. My bad:
Doesn’t affect the 909 however:
The upcoming changes post did mention that sequencer timing was improved in the pending update, but that AUv3 timing improvements were coming after.
Matt has mentioned to me personally and on Twitter that there are major issues with running a sequencer within a host. Not sure of the technicalities, maybe someone like @Samu could comment, but looks like they might crack it soon, which would be great, cos then I could finally makey video on this beautiful sounding but wonkily timed app, 😂
Seems odd to work on fixing sequencer issues at all when there are non-sequencer related latency problems. I'd think you'd want that one put to bed so it's not interfering with resolving the other. But maybe they're completely unrelated and both are being worked on separately.
For the people who are puzzled why this isn't fixed already a few days after release? Software ain't easy, and audio software on iOS is hard as hell. Jeeze, things take time. What seems like a simple turn of a dial or something to you can have many hundreds of lines of code buried in tens of thousands of lines of code. Expecting a fix practically overnight is unrealistic. They'll get there give 'em a little slack.
What I don’t get is why this issue exists when sending midi and not using their internal sequencer. Never seen it before. Even with their other plugins.
It's easy enough to have happen. iOS audio is a complicated system of processing in buffers, having to process in threads without interrupting other things, for instance, updating a screen when you need to be processing an audio buffer at that instant. Also, the handoff between hosts and plugins is a delicate affair. Add midi processing into the equation and you have even more complicated issues to navigate.
While I'm surprised the timing things weren't found before release, I'm not surprised at all that it's a challenge to fix.
AudioKit isn't a fixed team of developers, so it's not surprising that results aren't always consistent. AudioKit provide libraries that people can use to make audio app development easier. They're not a company of programmers pushing out apps. Rather, they encourage and inspire independent developers to make apps. Individual developers have varying strengths and weaknesses. A group of chefs may shop at the same market, but their creations will vary according to their character and talents. "AudioKit" is just the market where they shop.
Mocking the developer isn't going to help anything.
@rezidue said:
I think what people might not be understanding: AudioKit's goal is to create a pro-quality audio programming framework in Swift -- and Swift was apparently not designed with realtime audio performance in mind. So, there are performance issues that arise because of how Swift works.
My semi-educated guess is that some of the issues they are dealing with are bugs and performance problems in Swift that require Apple's attention to fully address. So, they probably have to spend some time working around quirks of Swift that don't exist in Apple's non-Swift frameworks and some time lobbying Apple to fix things in Swift.
Sometimes they might think that they will be able to find workarounds than is possible.
And all of the people working on it have other "real" jobs. When they get this all sussed out (and I hope they do), it will make it a lot easier for people to write audio apps and plugins.
That sounds about right Ed, though you have explained it much more clearly than Matt explained it to me. Apple have very high level people who check in on this project every week - the head of music is one - and this sounds like a feasible explanation of why they care so much. It is still unfortunate that it was released with such a major flaw, I just hope it all comes together sooner rather than later.
This is correct. In fact, you can't do audio processing directly in Swift at all. Audio processing has to happen in real-time safe context, which Swift is not. You have to use bridging classes to interact with the actual Audio Unit, and you have to do so in a very careful way, or glitches or timing issues will happen. It's not simple stuff. The AudioKit framework tries to make it easier, but that's a tall order.
One such note from the Apple audio unit example code:
The fantastic and wonderful thing about the FREE AudioKit team library is they're enabling a whole population of developers who don't necessarily have the deep C and DSP coding skills needed to develop apps. The downside is that population is also liable to make mistakes and to have a tougher time fixing them than veterans with decades of experience, such as Bram Bos, would have.
People complaining about these apps may feel better if they realize that despite the issues, they'd never have these apps without AudioKit's amazing FREE contributions. Somewhat broken D1 vs. no D1? Fantastic sounding 909 with some timing issues for $2.99 vs. not? I know my choice.
I hate to see people mocking these new developers. As if not being able to make a living developing iOS apps wasn't enough, taking abuse after probably thousands of hours of effort has got to be enough to make more than one person who might make many great apps for us in the future decide it's just not worth the grief.
Just a quick further note that I think some folks understand and some don't. The Audiokit guys have a lot of heavy lifting to do -- and it is quite a feat to get the traction that they have finally started to get at Apple.
I totally get peoples' frustration with the apps. At the same time -- I think it is worth appreciating that these folks have stuck with this for years and succeeded to get Apple to pay attention to something that would otherwise get no traction at all. I suspect that they will eventually succeed and we will all benefit from apps other folks write.
And I am willing to bet that their efforts are also benefitting non-Swift apps and plugins merely by virtue of the fact that some folks at Apple are having regular contact with music software programmers they wouldn't otherwise have.
One of the problems of Apple having gone from essentially a massively popular boutique company whose customers were disproportionately weighted towards "creatives" to a company whose products are used by the mass market (where "creatives" are a smaller piece of the pie because we are a niche) is that we don't have the traction that we used to have.
I appreciate that the AK folks are getting some regular time with people that impact the support for audio programming.
Yeah - they'll be buying yachts and Teslas and multiple beachfront properties with all that quick money....
If you're not joking, then you're way dumber than I thought.
There’s dev challenges with timing when dealing w sequencer within a sequencer
I had similar problems with the sequencer in touchscaper. This has nothing (or I suspect, has nothing) to do with the realtime audio rendering "rules".
I don't use the AK framework, just for the record, so these are my own observations with my own code, and touchscaper isn't AUv3. Not yet, anyway.
StepBud is midi only, so (kind of) different challenges. Well ... not really ... but less complicated.
909's audio timing problems and sequencer timing problems are two different, though perhaps related, issues. You could play a sound even in the standalone, without the sequencer at all, and the audio would still lag by a significant amount. It's getting better.
@CapnWillie Now that was funny!
While I agree that AudioKit doesn’t do themselves or their cause any favors when they release buggy apps, I do think it’s important to base your expectations of their apps on the understanding that their main goal is to develop code which will enable less skilled developers to create viable apps. If they are indeed raising the bar for Apple with respect to how well Swift functions for real time audio apps, then I think that’s a good thing. Does this mean they should get a free pass when their apps are released with significant flaws? I don’t think so.
Perhaps the users who want to support AudioKit’s mission could help them develop better beta testing protocols so they don’t release apps before they’re fully baked?
If you’re not wanting to be the guinea pig for their new apps, it’d be wise to wait until the bugs are worked out. It seems that creating professional level apps should include adequate testing as part of the process so they can build their reputation rather than discourage people from buying them by having significant bugs upon release.
Coffee down the nose! If you’d added commie to that sentence I’m sure I would’ve bust my stitches. 😂