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
Sounds like a great idea.
Can anyone explain how the Blending parameter/Audio quality and Load/Save work in textural synthesiser? These don’t seem to work as the manual indicates.
Not talking about the Audiobus Host being deprecated, I know that’s not the case as it will still be able to host AUV3 plugins. It’s the IAA protocol which the Audiobus plugin uses. Once Apple decides to pull IAA support, the Audiobus plugin format will also disappear. Who knows when Apple will pull the plug, 2 years or next month. Just hate to see the miRack dev waste his time given the uncertainty.
.> @philowerx said:
I don't agree that @mifki wastes his time.
I'd rather not upgrade to an iOS version that has no more IAA support.
No, sorry, you’re innacurate on this point. Yes, IAA will eventually stop working. However, Audiobus functioned before IAA ever came along, and was only later merged with IAA technology. Michael has said that should IAA stop working, he will still support AB functionality without dependence on IAA.
I don’t really want to try to hunt down the thread, but I will if you need me to.
(To reiterate, though, I agree with you that AU is the preferred direction for most apps.)
Actually forum search seems to have improved as of late.
https://forum.audiob.us/discussion/33215/the-future-of-audiobus-spoiler-alert-fine
We’re saying the same thing in a different way. The Audiobus Host will still host AUv3 plugins but IAA/AB format will eventually go away. I know there was originally a AB plugin format, then came IAA, then Apple made changes that forced Michael to use the IAA protocol.
Argh. I give up. No, we aren’t saying the same thing at all.
Is at least IAA > @[Deleted User] said:
exactly.I still didn't purchase it as i don't buy apps without AU anymore.Assigning Macros would be a good solution for my taste.
Ok 🤣
1* AudioBus was released on December 10, 2012
2* Apple introduced IAA with iOS7 release on September 18, 2013
3* I don’t have the exact date but Apple announces all audio must use the IAA protocol starting with iOS 8
4* AudioBus 2.1 SDK released June 10, 2014 in preparation for iOS8 AB forced marriage to IAA
Not that part. If you thought that was my point then you missed what I was trying to say.
If you’ve read Michael’s post that I linked and you still hold that AB plugin format is dead as a result of IAA depreciation, then fine, think as you please.
I don’t see a link but you’re saying Michael has a new AB plugin format in the works separate from AUv3?
I don't think you understood what Michael was saying. He is saying that if there is still a use for the AB protocol when IAA goes away (which could be years and years away), he will implement so that it doesn't use IAA. He is saying that AB will not go away with IAA.
If I get Michael correctly then his point was that AB compatibility will not depend on the existence of IAA. In other words, AB compatibility will live on but apps with IAA support would not be able to use IAA anymore for communication with other apps.
When I think about it, I don't get the point why Apple think that IAA should not co-exist with AUv3. Both have different advantages, see miRack!
From your link:
“Audiobus will be simply a best-in-class Audio Unit host, with all the features it has now with respect to Audio Units and MIDI.”
There’s no new AB plugin protocol. iOS audio will only use AUV3 when IAA goes away. As I said above the Audiobus host is not going away.
@philowerx I can recommend this reading:
https://developer.audiob.us/doc/index.html
I see the AB SDK more like a "third plugin format" next to IAA and AUv3 with an app that is also capable of hosting these.
Alright. Audiobus is a set of software modules (a Software Development Kit, or SDK) that developers can include in their apps, not a plugin format. This SDK provides the ability to send audio between apps, without the app developer needing to worry about the underlying mechanism that makes it happen. In other words, if someone includes the AB SDK in their app, and follows the right procedures to call its functions, then Michael changes how that works under the hood, it doesn’t matter for the developer. So, if Apple yanks IAA, but Michael changes his libraries to work with another technology (for instance the technology he used before or another), the app will normally still work without changing its code, other than to include an updated version of the SDK.
So, there is not a new AB plugin format, but any app that continues to include the AB SDK, will continue to work. If you read Michael’s post carefully, I think this will make more sense. https://forum.audiob.us/discussion/33215/the-future-of-audiobus-spoiler-alert-fine.
Anyway, this isn’t the “future of AB tech” thread, so I’ll bow out. I just wanted to try to clarify that lumping in AB inter-app communication with the demise of IAA is a misconception.
Just so there’s a canonical response here: what @wim, @espiegel123 and @rs2000 have said is correct. There’s no need for AB to depend on IAA. If IAA goes away and people still want to use an Audiobus-style workflow (which I find very likely), then I’ll simply be updating the SDK to remove the IAA dependence.
The quote from me above which @philowerx posted was taken out of context – that situation will only come about if there’s just no demand any more for an AB workflow.
Nice explanation of what Michael has offered to do should there be sufficient interest when IAA finally goes away.
Good point. I guess I was a bit fixated on AB using IAA for audio routing. AB certainly has more functionality with State Saving, etc than IAA.
Hopefully Apple will better flesh out the AU framework to fill in the gaps between it and IAA before they phase IAA out entirely. Hopefully.
Or maybe they’ll come up with some kind of proprietary dongle that’s needed to make it all work. 😂🧐
Integrating AB SDK was one of the easiest things (yes there's still state saving to implement and ideally some support for ABR triggers, but still) and the fastest way to provide certain functionality. So I'm not wasting time in any case.
Excellent! Had no idea this was already done. Fantastic work @mifki !
Doesn’t recording automation kinda kill The whole concept of euro rack?
Creating sounds and patches with automation via lfo and other tools is a lot of what makes modular synthesis what it is, recording automation like you do in gadget example is fun because you really can’t do it with modules or any other way... maybe I’m missing a part of the conversation about recording automation.... but I don’t understand exactly what people are asking for
I guess for some, modular is just a way to build some custom "device" and then use it like any other effect or generator plugin.
It depends... there are unlimited ways how to use modular... for example i'm not interested in self-playing patches build from step sequencers...
My use case is to build synth inside rack, then feed it with notes and automations from DAW and record audio .. AU plugin like @mifki proposed would be time saver, my music is simple so i don't need automate hundreds of parameters per track, usually 4-5 automation lanes per track is totally sufficient - so proposal with just few assignable knobs in readonly AU "player" is perfect for me ..
At the end, isn't it technically impossible to make AU plugin which would expose all miRack patch parameters directly to host ? Parameters list can be different from patch to patch and i'm in doubt that AU protocol allows for plugin change exposed parameters "on the run" when it is loaded in host. Or, that any of existing hosts count with possibility that plugin changes exposed parameters on he run.
On other side, even with "just" audiobus it's totally sufficient for me ... i just hit record , then i tweak various stuff, keep recording go lets say for your and i just tweak .. then i go to audio editor, cut recorded audio to smaller chunks, pick what i like and throw away what not .. its perfect workflow for me too ..
>
That’s makes sense I can relate to that
Theoretically yes, but I've found myself using miRack more like a physical modular system with sequencers being the main triggers during sound design, even more on the iPad.
Now once I've got a great groove or arp going, for me it makes perfect sense to record it and use the clip in whatever DAW. When I need a "normal" synth sound, I'll rather use a built-in or AUv3 synth.
With often more complex patches I wouldn't be able to use miRack as an AUv3 in my DAW anyway, the CPU would quickly freak out.
That's why I'm happy that @mifki has agreed to give us an audio file recorder and player soon.
Indeed, my physical euro rack can make plicky plock sounds but also i can turn it into a sh 101 clone which I can play via keyboard and controllers etc.. this is normal to me.
The way I have solved for automation is using the midi cc module, then I pass midi cc from AUs hosted in AUM to any cv input I want to modulate. It would be great to visually see that the knobs / parameters are being modulated but it works.