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
someone try it in garageband, i erased it.
Both Korvpressor and DDMF envelope work at 1024 samples in AUM. I double checked by also launching Auria and going to the setting to see what the reported system latency was, and Auria confirmed it to be 1024 samples.
I'll file a proper bug report with WML when I get some time on Monday.
>
This will be very interesting, as earlier in the thread WML stated that the the problem is nothing to do with Auria Pro.
I don't want to create and save a new patch every time I use it, that's ridiculous. Auria remembers everything else I've done, I just wish the delay plugin would have proper state saving.
One of those very basic bits of functionality that if missing, can put you off using an app.
But, the patch is there when you restart Auria Pro...
It's only the name of the patch that has change... you've got an state saving already...
Rim probably hasn't had a chance to test every permutation out there. I'm sure he was telling the truth in that some AUs can't work at higher latencies. It's not always that easy finding bugs, but here we have a clearly reproducible case so hopefully it can be fixed.
Not completely accurate. Apple recommends a maximum buffersize of 512 frames for AU. This is also baked into their sample code, hence most AU plugins are set to this maximum. It is the responsibility of the host to check this setting for the plugins and make sure that calls do not exceed this value. Safer to split the AU call into multiple successive calls instead to deal with it, I guess
I ran into this problem when implementing Audiobus in my plugins, which also raises the buffersize to 4096 when in the background. Suddenly my plugins stopped responding and returned strange error messages. Hence I changed the max frame number in my AUs to 4096 as a workaround (took me a day of pulling my hair out to figure that one out, as the AVAudioEngine framework was hiding the error messages from me
). But you can't expect all devs to do this, because it's not according to the official documentation and requirements - and most are probably not even aware of it since it's part of Apple's code.
For sure. Didn't mean to imply anything else.
There's no dishonesty here, just a small mystery, which may or may not be solvable.
Is there a technical reason why Apple would want a maximum size of 512 frames? I'm guessing it's because MIDI on iOS can't go beyond that, but it just goes to show that AU is still all a bit of a mess. Auria's native plugins work so much better and more smoothly, it's a shame that something like them can't be made universal.
I think Bram has nailed it. A quick search of Github reveals how many developers are using Apple's sample code:
https://github.com/search?p=2&q=maximumFramesToRender+=+512&ref=searchresults&type=Code&utf8=✓
Not sure, I haven't found a detrimental side-effect of using a higher buffer size than 512 (although I haven't tried a lot of real-world cases with higher settings) in AU.
I think they envision AU and iOS audio in general as a realtime performance environment where lower latencies must be encouraged.
Not so good for mixing though. Is there a reason to limit MIDI to 512 frames? Does it start drifting beyond that?
I'm not aware of this limitation, but I'd love to read about it if it's documented anywhere.
Either way, AU MIDI event input is processed at the same time as the audio rendering (and plugins are assumed to respect MIDI timestamps) so regardless of buffer sizes or MIDI limitations every MIDI event should be sample accurate.
It's really a neat system in theory. Just a pity that Apple doesn't provide a reference host to show how hosts and plugins are meant to behave in a perfectly imlemented environment.
@WaveMachineLabs let me know if you'd like to test with plugins with various buffer limitations. I'm happy to set up a testflight with one of my plugins for you to try different things.