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
Hey guys,
NFM and NS1 developer here. Last week I released NFM and since then I have gotten a lot of emails regarding the users not being able so browse presets in BM3. After I emailed Mathieu about this he pointed me to this forum. Thought I’d respond here to share my take on the subject.
For a long time I've held a belief that host should provide a uniform experience to the users, a bit like how things work in Logic Pro and Ableton Live. Where you can browse and audition presets from the left hand browser without ever touching a plug-in. This can be quite convenient and from my perspective is the best user experience. I personally love using that feature. When I released NS1 in 2016 I even wrote a blog post about it https://nikolozi.com/blog/2016/4/2/ns1-demo-by-the-sound-test-room-and-some-faq
I never ended up adding presets UI to the NS1 extension and over time a lot of hosts added preset support. This includes Cubasis, modstep, Auria, AUM etc.
And like you guys have discussed here, I also proposed that Apple should create an iOS wide feature where hosts and AUs can participate and share presets. And the presets can be indexed, be searchable and tagged system wide. So I filed a radar and I encouraged my blog readers and NS1 to do the same. Additionally, I suggested that this feature doesn’t need to be limited to iOS and could work great on macOS too. theanalogkid from the Apple forums acknowledged the radar. So I had some hopes, but 2 WWDCs later we still don’t have anything better.
Also, just to be clear, I’m not against AU developers having preset selector UIs in their extensions if they think it suits it. But it should be up to the AU developer if they want to provide that additionally to host managing it. A bit like drum machine plug-ins. Some drum machine plug-ins allow you to trigger drums from the their interfaces or program patterns in addition to doing all that via MIDI.
Having said all that, I’m feeling the pressure from the users, and some hosts (e.g. GB) don’t have a very convenient UI for auditioning the presets. So I might end up adding an option to NFM (and NS1), to show/hide the preset selector in the extension.
Cheers
Niko
Hey guys,
NFM and NS1 developer here. Last week I released NFM and since then I have gotten a lot of emails regarding the users not being able so browse presets in BM3. After I emailed Mathieu about this he pointed me to this forum. Thought I’d respond here to share my take on the subject.
For a long time I've held a belief that host should provide a uniform experience to the users, a bit like how things work in Logic Pro and Ableton Live. Where you can browse and audition presets from the left hand browser without ever touching a plug-in. This can be quite convenient and from my perspective is the best user experience. I personally love using that feature. When I released NS1 in 2016 I even wrote a blog post about it https://nikolozi.com/blog/2016/4/2/ns1-demo-by-the-sound-test-room-and-some-faq
I never ended up adding presets UI to the NS1 extension and over time a lot of hosts added preset support. This includes Cubasis, modstep, Auria, AUM etc.
And like you guys have discussed here, I also proposed that Apple should create an iOS wide feature where hosts and AUs can participate and share presets. And the presets can be indexed, be searchable and tagged system wide. So I filed a radar and I encouraged my blog readers and NS1 to do the same. Additionally, I suggested that this feature doesn’t need to be limited to iOS and could work great on macOS too. theanalogkid from the Apple forums acknowledged the radar. So I had some hopes, but 2 WWDCs later we still don’t have anything better.
Also, just to be clear, I’m not against AU developers having preset selector UIs in their extensions if they think it suits it. But it should be up to the AU developer if they want to provide that additionally to host managing it. A bit like drum machine plug-ins. Some drum machine plug-ins allow you to trigger drums from the their interfaces or program patterns in addition to doing all that via MIDI.
Having said all that, I’m feeling the pressure from the users, and some hosts (e.g. GB) don’t have a very convenient UI for auditioning the presets. So I might end up adding an option to NFM (and NS1), to show/hide the preset selector in the extension.
Cheers
Niko
It seems like this AU preset menu is only available in the iPad version. While in the "parameters" view on iPhone there doesn't seem to be a way to get to it....
It’s there.. just a bit hidden:
Sorry to revive an old thread, but did BM3 ever add AU preset management?
As far as I know nope, get in touch with Intua or something.
Maybe tag Vincent over at the Intua forums and ask if they are still developing the app or not...
Thanks @Samu. Context: I don't do user / custom preset management in moodunits, which I think is the right thing. Obviously, it's supported under the hood, but I don't do the UI to save / restore user presets. However, that's not so great if the AU host doesn't handle it either. I had a user get in touch and I wasn't familiar with BM3. I found this old thread and was kinda surprised by the stance of (presumably) the BM3 dev and had hoped maybe that had changed by now...
He's French.
I prefer AU apps that allow me to save presets in both the host and the app if I choose to. Sometimes I’ll use the same preset in various AU hosts and recreating presets for each host is a waste of my time. On other occasions I create presets for specific projects and save them in the AU host app as I wouldn’t want them cluttering up my global AU app preset list. I hope you reconsider your stance. I think Jonatan Liljedahl’s decision to provide his users with the option to save their user presets in AUM, the AU app itself or both is the optimal way to do this.
I think we're actually agreeing on this if you're talking about AUM. The Save Preset dialog in AUM has the option to Save in Plugin or Save in AUM as you say. However, That's AUM doing that (i.e. the UI), not the plugin. Basically the host should (IMHO, as AUM does) simply query what's known under the hood as the "full state" for the AU, and put that data in a file "somewhere" with the name you give it. Where it puts it, is up to the host IMHO.
This is pretty much what @brambos said earlier in the thread. Pretty crazy that almost 3 years later and none of this stuff is really standardised...
No, it's an iOS feature now. Although somewhat confusingly named, "Save in Plugin" is facilitated by the system and must be handled by the plugin. It tells iOS to store the presets in a centralized location in the system so all hosts can access them. I suspect at this point only AUM and Garageband support this new feature (introduced in iOS13), but I'm already slowly adding support for it to most of my plugins.
Do you know if there's any way to 'backup & share' the presets stored in the 'centralized' location?
If not this is something Apple should definitely add in iOS15/iPadOS15 and the same time stop 'dumbing down' everything.
(On the Mac it's easy as there is a Presets folder I ~/Library/Audio/Presets/Dev/Plug-In-Name/)
It would likely be a very easy task for Apple to optionally expose that folder in Files.app for easy preset management...
(This centralized location could also be used to share samples and other audio files between apps but then again this would take away Apples opportunity to sell iCloud Storage and the need for 1TB iPad to store duplicate files would go down).
Cheers!
Does GarageBand actually support user presets in the AU now? I thought it didn't.
Apple doesn't really need to do anything to make it easy to backup, store, or share presets. All that is needed is a third-party utility app and for all of the hosts and AU's to start supporting what Apple has already provided. I really want to write a little app to do this, but my last survey of AU's and hosts tells me it's pointless because very few actually support using the mechanism that is there.
OK... thanks @brambos. If you're talking about saveUserPreset / deleteUserPreset I was assuming (perhaps stupidly...) the default implementation in AUAudioUnit would handle that as per the "documentation"
The default implementation of this method will save the user preset to an internal location. Audio Units are free to override this method to operate on a different location (e.g. their iCloud container).
It seems to work, but I guess I could override them anyway to be on the safe side. Thanks for the clarification on this.
@Samu - the iOS walled garden file system and AUv3 do not sit well together at all do they? Believe it or not, it's quite a convoluted exercise just being able to share files between an app and the app's extensions (in our case, AudioUnits). You can't help get the overwhelming feeling of this is kinda stupid having to set up "App Group" entitlements just so you can shunt files around essentially within the same app, albeit extensions thereof.
And it's even harder to explain this to users, whenever they question why you make handling presets so clumsy and convoluted. All this stuff really makes developers look bad
Some people over at Apple need plenty of spanking and push to 'wake up'.
I know iOS is a 'dumbed down' walled garden as I've been in this 'iOS Game' for >10 years now...
'Pro Users' need 'Pro Features' and until those come to iOS/iPadOS the iPad/iPhone Pro's are just a bad, bad jokes.
Many buy the devices hoping that things will 'improve' in the coming year or two and when nothing happens they get bored.
I am looking forward to iOS15/iPadOS15 later this year as it keeps on improving in 'baby steps'...
...maybe 2021 will be an exception?!
Hopefully Apple will drop a iLogic so AUv3 developers will have a fully featured 'reference host' to test their stuff with...
...GarageBand just doesn't cut it.
Cheers!
@brambos thank you for your insight on this topic. It’s a shame Apple hasn’t put more energy into developing more reasonable standards for their mobile devices OS infrastructure as it seems to often result in different developers creating different approaches when Apple hasn’t standardized or created something yet and then the developers having to shift gears when they do.
It's free R&D for Apple. Let developers spend years thrashing around finding ways to work around what Apple can't be bothered to do, then when the dust settles, put out a competing, and incompatible, way of doing the same thing. The coup de grâce is the App Store dynamic of not having a paid upgrade mechanism, meaning developers don't even get paid for doing Apple's R&D. Classic.
Take the saga of IAA > AUv3:
Phase 1: Apple provides no way of allowing audio apps work together. A brilliant developer solves the problem with an app and an SDK for developers to incorporate. Willing developers expend effort adopting the SDK. The idea catches fire and is refined over a period of years until it becomes a de-facto standard.
Phase 2: Apple swoops in and establishes IAA, which does the same thing but in different and incompatible ways. Brilliant developer must re-implement his protocol and SDK to remain compatible. Now there are two "standards" living side by side.
Phase 3: Apple, introduces a better (in some ways) standard: AUv3. No need to waste time refining the details or developing decent documentation - the developers will work that out for free.
Phase 4: Announce the depreciation of IAA, screwing all those developers who bought into the original standard and didn't embrace the new because it is so unrefined and poorly documented.
Final Phase? Once the consensus of what is needed emerges, and with a wealth of implementation examples courtesy of the developer community, introduce a method that if it were created and documented in the beginning, would have saved developers countless hours of time.
Apple is brilliant.
Apple removes all the ports on the mobile iDevices and kills mobile music creation for good
After spending >10 years with various music apps things still don't work properly...
...wonder if they ever will until there's a fully featured reference host (ie. LogicPro) available to check all the plug-ins with...
I mean we still have basic issues where mixed sample-rates cause issues, plug-ins work in one host but not the other.
Track Freezing/Bouncing is a hit or miss. File management is still bad joke and the forced sandboxing will never allow full app2app or app2plug-in communication.
I'm no longer even tempted to get a new iPad for my music apps as they work well enough as a 'sound module' for Renoise & LogicPro.
We'll have to wait and see what iOS15/iPadOS15 will bring later on during WWDC'21...
Cheers!
I expect that Apple (and every other phone manufacturer) will eventually make phones with no plugin type ports. I doubt if they'll go this path with the iPad. I expect that the iPad will transition to USB-C and then Thunderbolt when they all move to USB-4.
Sandboxing will only get stronger. It won't be weakened. You can blame Facebook, Google, etc. for this. In addition to their own spying on people, the purposefully abysmal security of their platforms has been used by not-so-benevolent State actors to track and abuse people.
Computer style filesystem support isn't needed to do what's needed for preset management. The features are there in the AU spec to do what is needed. Developers just need to support the features. It would really help if Apple would support them and actually document them, but I doubt if that is going to happen. Send requests to the AU and host devs to support the preset features that are available. They really aren't hard to support.
The direction that Apple takes with iPadOS in the next release will be interesting to see. I expect that there will be more features added to support multi-tasking and multiple users, but I really doubt if they'll do anything to alter the security model.
I love how you continue always look forward to the next iOS/iPadOS release. Even after we're at 14.3 and there are still significant problems for audio apps. I don't. Each one for me is an exercise in deciding when/if to upgrade, or whether this is "one update too far" for my Air 2. Actually, I'm looking forward to the upgrade where Apple drops support for the Air 2 and it becomes my "frozen" device.
I'm perfectly happy to work around Apple's sub-par file management system. My iPad is for making music, not a file repository. If they never introduced a new feature, but just kept fixing things forever, I'd be fine with that.
This.
I know the overwhelming majority here resent, and consider ridiculous, the ever tightening security hassles. I don't. I've worked with computer security for more than 30 years and know without a shadow of doubt that most people have no idea how important, and difficult, it is to harden an OS. If iOS devices were only used for music making it would be different, but they're ubiquitous.
Apple has no way of knowing whether a device is used in sensitive ways or not and what people will install on them. They have to assume the worst. I can tell you that hackers are well able to find ways to leverage security flaws of any kind. They are smart, thorough, and organized.
Let the chorus of people saying I'm being paranoid begin. That's understandable. Those who do are probably not who Apple are trying to protect. That doesn't mean there aren't tens of thousands or millions of people who do need it. Come back to me and call it ridiculous the next time there is a massive theft, or sabotage of some critical piece of infrastructure, where a smart phone was the attack vector.
Support for iPad Air 2 will most likely be dropped in iPadOS15. I'd be surprised if it gets it
My iPad is for music making as well but when an AUv3 plug-in can not even directly access the data in the host DAW without work-arounds it becomes quite annoying thus we'll never have 3rd party plug-in (ie. external app) that fully integrates with a DAW unless the security model is changed allowing bi-directional the plug-in to communicate with the host.
The irony here is that it's for example NOT possible to do 'Drag'n'Drop' between say Cubasis and an AUV3 plug-in but I can bring up the Files.app pop-over, browse to the Cubasis folder and drag exactly the same file that is used in the project straight into a Plug-In window.
So if this is already possible, why can't a host do drag'n'drop' to the sandboxed AUv3 when the Files.app can?
Some apps allow drag'n'drop of content when used in split-vew-mode but this does not apply to AUv3 Plug-Ins?
I have no doubts that the developers behind GarageBand and LogicPro could knock up a more fully featured DAW for the iPad and considering Logic Pro already runs on ARM/M1 there should be no performance issues on the iPad unless it's the 'iPadOS security stuff' that messes things up.
To sum it up, iPadOS is not 'feature ready' for Pro apps yet...
Cheers!
Yeh, different levels of tolerance. What drives some people nuts is fine for others.
Having started music making on the violin, then acoustic guitar, then electric guitar, before computer music, I expect music to be hard. Even the worst of this shit is so much easier than dealing with strings, tuning, pickups, amps, stomp boxes, wires, DI boxes, AC hum, PA's, mixers ... etc., not to mention how hard they are to learn to play.
Jeesus, I could care less about a few workarounds to copy a file somewhere. But I surely understand why it bugs others.
Cheers!
✌🏼