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.
Black Hole Nova: AU Integration Support Proposal
![[Deleted User]](https://secure.gravatar.com/avatar/8e2ba17b6a6e9f58aa5bbd272b74df69/?default=https%3A%2F%2Fvanillicon.com%2F8b1d12d34a03a3a28ace2390aa177bff_200.png&rating=g&size=200)
Attached is proposal for how to proceed with creating an AU only hosting app which will be Audiobus compatible, sync with an IAA host app, support MIDI control routings, and have multiple input and output ports accessible from the hosting app or connected audio hardware interfaces and controllers.
Restricting the app to AU hosting only means it will have a comprehensive preset system which will remember all of the settings for the app including routings and AU settings.
It will act as a node for uses such as in Audiobus, AUM, ModStep, Moebius Lab, or DAWs. With a comprehensive preset system, users will not have to go through all of the hassle of setting up their AU apps if they don't want to. Essentially it can be a black box you connect to without needing to know all of the setup details, but if you're so inclined you can create all manner of routings and controls.
As envisioned, this process may take a couple of years but by then iOS devices should be more powerful plus AU, IAA, and Audiobus will be even more developed and able to integrate well with such an app.
Comments
An interesting read, perhaps it could include some example screenshots to help illustrate what the user experience could look like
Interesting...
Upon further contemplation, most of the proposed functionalities may be provided by limiting AUM setups to AU apps such that saving those presets would then provide all of the settings and the various combinations of hosting or being hosted by other apps such as ModStep, Audiobus, Moebius Lab, and DAWs might be viable.
Perhaps the remaining worthwhile ideas of the project would be getting Apple to provide better and more consistent iOS audio infrastructure to developers so we don't end up with situations where AU presets are specific to the apps that host them, or that many IAA apps lack IAA host sync often without any clear indication as to whether they have that functionality in their App Store description. Perhaps joint developer/user lobbying approaches will result in more effective service for iOS audio?
The second piece would be some sort of centralized preset site that could be accessed by multiple iOS apps, have a tag/search capability, describe what the preset does and how it works, be able to access the site from within the app and to download presets directly into apps. For presets involving multiple apps, it'd be very convenient if there was a way to automatically filter presets by the apps needed to run them with the option to list apps you lack as well as to suggest alternative presets that will work with the apps you do have.
Having various interest groups you can join on the site would also help preset creators by sharing common interests and goals. Once again a filter system based upon tags and apps could help users to connect with others working on similar projects.
It's been my experience, other than the Audiobus forum, there seems to be relatively little user engagement on other app user forums. Having a way to consolidate collaboration and presets that is also integrated with in-app functionality would be ideal. Perhaps one of the existing app preset sites could come to fill this role by developing relationships with developers who don't have the time, resources, or interest to run their own forums?
I imagine it's a tall order, but what I think would be interesting is a system level app snapshot, regardless of the app type. It would need a mgmt system as well. I've also wondered how an audio exclusive version of iOS devices would be. I imagine market forces couldn't drive it, but it's a fun thought.
@dunjunkie27 interesting ideas. I wonder how resistant Apple would be to a system level management system as they're extremely protective of iOS security and may see such an app as too much of a security risk?
I'm suggesting it reside within the os...I couldn't imagine it working any other way, given the security concerns. Apple would only allow apps access to the snapshots, but the snapshots themselves are captured and maintained at the system level.
Note that I'm no programmer.....other than some Pascal and Basic years ago. This is just wishful thinking sorta stuff.
I think initially a community effort around getting AU support from some of the richer iOS synths would really help momentum, which can be further leveraged to getting the spec/documentation improved.
Some examples could be
Nave, Z3ta+, iM1...and more
I think a big problem with such a plan are the resource limitations of the current AU specifications which may be insufficient for running some of these apps. An additional problem is that developers will not be able to charge for these conversions.
So yes, if we want to see more existing apps have AU support we'd need to lobby Apple for changes to:
Improve AU documentation and specs
Provide a way for developers to be compensated for converting their apps to AU
I think convincing Apple to allow developers to charge for AU conversions is unlikely to happen as Apple doesn't want developers to be able to create variations of their apps so they can charge users for core iOS functions. They'd be concerned about having IAA, AU, and non-IAA/AU versions of the same app in the App Store.
MIDI might seem to be an exception to this policy, but although iOS provides core MIDI support, Apple did not invent MIDI so they can't invent rules for how developers use or don't use it in their apps.
A more viable approach might end up being one where the iOS community decides to independently fund a project whose goal is to convert legacy apps to apps with AU support once Apple has upgraded the specs and documentation for developers who agree to participate in the project. If there is not enough user interest in funding such a project, then it seems unreasonable to expect developers to do so from their own funds.
Perhaps a less burdensome alternative would be if Apple provided a method for IAA apps to provide state saving preset information to IAA host apps as Audiobus currently does through their preset state savings. Once again this would be a case, as with IAA, where the Audiobus team is doing the development work for the iOS audio development team at Apple without any additional compensation from them. This would still not solve the issue of being able to create multiple instances of an app, but at least you could preserve the settings for all of the apps in a given setup provided they all had state saving functionality.
Think we really want presets to be local to the AU itself and references to those to be stored in the host for recall. Otherwise, if you create a sound in iSEM while using host A it will not be available when using host B.
The option to have universal AU preset availability from any AU host is a sound one though perhaps the method for doing so could be better than storing them inside the AU.
The idea of an AU is that all of the controls for it come from the host AU and the AU only has what is needed for performing its function. Storing presets inside the AU would undermine this minimal/essential structure.
Not all AU host apps are created equal either so there could be any number of reasons why people may not want to use all of their AU presets in every AU host app. Having too many presets could end up being a hassle or won't work where changes are automated. For example, during a concert only presets for the performance would be loaded so you wouldn't have to be scrolling through too many presets. Some may control setup changes between songs with MIDI program changes using foot switches.
Ideally there would be a central document storage area for AUs outside of both the hosts and the AUs. The host would select a preset in the AU it's hosting as it does now but when you select the preset it could select presets from the shared AU documents area.
An even more sophisticated approach would be the ability to organize your presets in groups using a tagging system. This is similar to synth apps which use a tagging system so you can filter to get the presets you're interested in. Naturally there would be the option to list all of the presets and to sort them by various ways as well. Cloud storage and export/import options for these presets would be options too.
Most importantly in an AU host, like AUM for example, when you save a session file it will still store all of the presets used to control all of the AUs in the session such that if you were to send someone the session file, they'd have the same presets you used. When you open up a session file, the presets will be as they were when you saved the session.
People would not be required to use the central AU preset storage area and could choose to save presets as they do now, but they'd have more options.
So the entirety of iM1 is ~100MB, Nave sits at 198MB both of these can fit comfortably within the current memory limits of AU. Model 15 is at 211MB and Synthmaster is at 349MB which I believe is much closer to the threshold.
So many great sounding synths can still be very useful even with today's AU
@sirdavidabraham fitting within the memory limitations of the current AU specifications isn't the only limiting factor developers face when adding AU support to existing apps, they will also need to fit their app within the confines of the AU window, create ways to be controlled by the host, not to mention whatever internal changes in how the code works that are needed to work as an AU.
They will also have to decide how much extra support they're willing to provide to deal with usage of their app as an AU. If developers did not see any significant increase in sales of their apps after they added IAA support, it will be another reason why they can't justify doing an AU update. Developers will not be able to charge for any of the work they've done to add AU support either. Many developers have said that the documentation for developing AUs is extremely poor so they may be concerned Apple is not committed to the current AU standard and may change it. If the AU specs should change it would mean another round of updating to maintain AU compatability. It's not clear what would motivate developers to update their existing apps with AU support.
@InfoCheck I'm aware of the challenges, I just mistook your original post for one that advocated for AU...seems I misread the intent.
Fwiw whenever I have gotten an email response from a synth or effect developer regarding AU it's been a much more promising response than what seems to be the prevailing wisdom on this forum, understandably so I suppose because of the AudioBus focus.
AU is a beautiful concept. It just needs a bit of spit and polish (and some love from Apple). And I don't see the resource constraints as overly limiting. Unless you need to accomodate a 2Gb multisampled Grand Piano, the limitations should not be blocking for any normal synth, effect or instrument. It just takes a bit of planning on the end of the developer, and that has never killed anyone ;-)
Cool great days ahead
I am definitely interested in advocating for AU. As with all advocacy it has been my experience that you are better off examining all sides of an issue and perspectives in order to come up with the most viable way forward. It has not been my intent to discourage ideas about moving forward with AU and I acknowledge how raising issues can seem counter productive.
Asking questions about what the obstacles might be to having more AU enabled apps can be a step towards overcoming them.
It was great to see @brambos, the developer of the excellent Ruismaker AU drum machine app, provide insights into the viability and potential of AU. He seems to put to rest the idea that resource constraints are overly limiting.
I hope he and other developers contribute more to this discussion so AU development will improve. It can also be an opportunity for communication between developers and musicians about how they'd like to use AU apps.
To be fair @Sebastian in his AU discussion on the Audiobus forum has been more skeptical about the topic than @brambos. I value the Audiobus team's perspective on the topic as in my opinion, they've done the most to facilitate viable multi app work flows on iOS by working with a diverse group of developers so apps can work with each other. This also includes projects such as The Amazing Audio Engine which help developers to write more efficient and reliable apps.
I think everyone can agree that AU development would benefit from more attention by Apple. There is room for improvement with AU and I want to do what I can to support it.
This is a follow up to the discussion about universal AU preset access I discussed a couple of posts earlier in the thread. It might also be relevant to the system snapshots that @funjunkie27 posted about as well.
What about version control?
When an AU app is updated, the controls or sounds in a preset may not work or sound differently. If one of the great benefits of using AUs and their presets is that everything will be the same as when you left it, there must also be a way to address what happens when AU apps are updated. The song you've saved in your DAW should sound the same.
What's the solution?
In the best of all possible worlds, in the iOS music creation environment the presets used in projects will be tracked automatically. When you go to update an app, information about changes to the app will be processed to compare them with your presets and issue you a report. You can dig deeper into the report to see which specific projects, presets, or setups will be effected by the update. This information will help you decide to update.
You can also configure your update settings such that certain changes will be okay based upon how you've configured your preset system. For example, you have a group of app setups you're using for the current concert tour. Any presets used in these setups will prevent you from updating an AU, apps, or iOS that would change them or for the more conservative, it will prevent updates to any of the above for the duration of the tour.
Equally important, you'll have the option to install a different version of apps or iOS as needed without losing any presets. The AU preset system will keep track of AU version compatability issues.
It seems we're not there yet, how do we get there?
iOS currently operates on a basis where you can only move forward and not back. You can save backups of apps and restore them later, but this requires a computer and can be a less straight forward experience than updating apps. If Apple truly wants to support musician's work flows, they'd improve and provide a more flexible user experience.
Since music creation is such a relatively small proportion of Apple's total revenue, what will motivate them to commit more resources to accommodate musicians?
I believe the answer lies in Apple's push to have iOS devices seen as workable options for replacing desktop and laptop computers as well as pro applications. How does this have anything to do with music creation apps?
At a fundamental level music creation involves the manipulation of sounds over time, often under real time performance conditions with a very low tolerance for errors. This means the ability to create snapshots of specific music creation states is a vital part of the process and AUs can play a central role in facilitating this.
Similarly, pro applications involve complex collaborative real time transactions over time with the need to be able to recall specific states. It can also mean working with people who are on different systems. Project collaborators have to be in sync for the work to flow efficiently and smoothly. There is also a very low tolerance for errors and a need for version control as administered within the project's organizational structure rather than as determined by Apple.
To meet the needs of pro application users, Apple will have to pivot away from an only forward update focus and sandboxed documents linked to specific apps. My assumption is that it'd be easier for Apple to work with musicians and music creation app developers on some of these more flexible and robust iOS level changes because they'd have less at risk given music creation is such a relatively small part of their business. Once they have created viable, efficient, flexible, and desirable work flows for musicians, they can then use what they've learned to address the issues of other pro application user communities with a track record of resolving real world, real time, complex, multi user, multi platform, multi hardware environments within iOS.
The Audio Unit story is a rather complicated, multi-faceted discussion at the moment. Here's my take from a developer point of view (mind you, users will likely have a different perspective!)
Established AU alternatives and support
Audio Unit Extensions are a new, barely proven, 'standard' (and I use that word loosely) on iOS, and it faces stiff competition from IAA and AB which both have already found a way in the workflows of most iPad musicians. It needs to clearly show it's worth adopting by users and developers, before it will be embraced. Audio Unit is lacking in documentation and its the developer community is still small, so support must come from Apple. And it isn't at the moment. At least not as far as I can see, and I think I'm looking for it in the right places.
Limitations and constraints
Audio Unit Extensions are a totally different paradigm than standalone applications. Think of it as a dumb sound generating (or mangling) engine that can be taken and used by any host application. It will not replace all functionality that stand-alone apps can offer (such as advanced midi magic and complex audio routing) because that's not what it sets out to do. Therefore, it may be difficult to do a straight port of existing standalone applications to Audio Unit format. Some features may simply not exist or not make sense in a plugin-environment, where responsibilities are logically shared between plugin and host.
When starting from scratch however, there is nothing in the Audio Unit format that is stifling or overly limiting - unless you want to do something that it was not designed for. The resource limitations are logical for the platform and should offer sufficient room for most synth/effect applications. I learned coding in a time when internal memory was measured in dozens of kilobytes. Having hundreds of megabytes is enough for any competent programmer. If it's not, you're doing it wrong (or the mobile music world is not ready for you yet ;-).
There are some obvious limitations. Personally, I love working within constraints because it forces you to be creative and "work with what you got". Clear constraints are the fixed screen dimensions (something that was once a critical successfactor for iPhone app design, by the way!). And another thing I ran into was some undocumented throttling of UI refresh rates. (E.g. I couldn't make the channel buttons in Ruismaker blink when MIDI was received... they would always trail behind the actual event). This could be due to the Extension system or due to host implementation. Either way it was a constraint for my plugin's UI design. A third one is the lack of persistent User Presets. Apple claim they're working on it, but it's something they have to do fast. Because right now every plugin and host is implementing it in its own way and interoperability is non-existent (it's the reason for this thread, in fact).
Developer motivation
I think very few devs can actually make a living from developing audio applications on iOS. Some can, most can't. So most of us, including yours truly, are in it for the love of sound and music. We do it because it gives us warm fuzzy feelings and a creative outlet. What is the fun part of creating music software? Mostly creating and shaping the synthesis engine and everything that has to do with sound. What is the shit part? Getting it to work with every other application in the known galaxy. That's why (at least for me) Audio Unit is appealing. It's a nice self-contained format and (in theory) fairly straightforward to get working with all compatible hosts. And lots of the shit duties then become the burden of the host/sequencer who typically have the mechanisms already in place (e.g. midi management, syncing, audio routing, customisable controller support, etc.).
Making something standalone opens up a huge can of worms, because as soon as something runs standalone, users will start demanding glitch-free compatibility with Audiobus, IAA, AU, Link, MIDI, AudioShare, AudioCopy, Dropbox and every other link/sync/share protocol ever invented by mankind. For me, personally, that would make a project unappealing to the point of "not worth the effort anymore". It would then become 10% fun and 90% chores (learning new APIs, fixing compatibility issues, disentangling incompatible standards that don't play nice together within a single app). In a nutshell: for me AU tipped the balance of the scales of the project from "ugh" to "yay".
_TL;DR: _Audio Unit is what lured me to the iOS music making world as a developer, whereas the old Wild West situation of proliferating competing standards and protocols just made the platform seem daunting and discouraging.
If I were Apple, I'd take the following approach:
@brambos thank you very much for your perspective and work. I know that I've benefited over the years from the work of developers such as yourself on iOS who are primarily motivated by the love of sound creation. It is great news to hear that for at least some developers, there is less overhead and complications involved in creating AU apps.
I defer to developers as to whether or not they believe their apps would be suitable as an AU or not.
Hopefully Apple will do a good job as they address the issue of universal AU preset access. I think there will be an opportunity for an app developer to create an AU preset management app with more options for tracking presets and could utilize the standard AU specs in addition to whatever user info. someone wants to add to their presets so that AU and AU host app developers wouldn't have to deal with it nor would other users who are satisfied with the standard system, but it'd be an option for others to enhance their work flows.
I'll have to think about how an AU preset app manager might work and post some mock ups of what I'm on about as big blocks of text don't convey it so well.
fantastic read...I'm hoping it facilitates more talented developers to jump in.
I've attached an outline which attempts to address issues related to AU preset management. I believe AU preset management can be a way to organize presets, share them, see where you're using them, and to also address compatability issues related to app and iOS updates.
To be useful, the AU preset management system should be optional, take advantage of built in information, and allow users to configure it to meet their needs. It could be part of the AU iOS specification so that it will be consistently implemented and require minimal effort on the part of AU app and AU app host developers.
Here's a brainstorming outline (so it might not make much sense) as food for thought. I apologize for the awful formatting as I tried to convert it from a mind mapping format to a web page version I could post here, but a lot was lost in the translation. The html file you can download to your browser and read directly. Posting the text seemed way too long and rambling for any but those interested enough to use the links to access the outline anyway.
Here's the original version in Freemind format you can view using the free iThoughts2go app. The Freemind file you'll have to open in Dropbox and there it can be opened using "open in" to the iThoughts to go app.
@InfoCheck ,
You are so thoughtful!
The best writer on the music net....
I read as much as I can from you.
While that's sad you're one of the very few third party developer who have been lured in that way. Sorry you had to take one for the team.
If anything, it's the other way around: Apple has had help from third party developers already to get to the point where they are with AU Extensions. And as you mentioned that state of the 'Standard' is lacking, still, even after WWDC 2016.
Apple has never pushed IAA just like they have never really pushed AU Extensions. Apple just releases technologies and hopes for adoption.
When IAA was forced upon us we already had hundreds of Audiobus-compatible third party. Since IAA was the only way to continue because Apple shut down Mach Ports (the underlying technology behind Audiobus 1.x), IAA got the adoption it has today. We did most of the pushing (we had to).
Apple has fixed some of the bugs in IAA. I hope they continue that route, because Audiobus and IAA are not going away, since AU Extensions are not able to replace them.
We've already added state saving (something that standalone IAA doesn't have) and we're going to push the platform further with Audiobus 3 (ahem, did anyone say comprehensive and reliable MIDI routing? No? Nobody? Well... that then).
Thanks for chiming in.
Oh.. it doesn't feel like taking one for the team. The project has been fun and fulfilling, feedback from users is generally positive. Also the Audio Unit concept works as promised: multiple instances, resource-efficient, blends into the host's workflow.
And there are currently more Audio Unit hosts than plugins, each with a substantial installed base, so it's a fertile ground for plugin developers.
Haha.. indeed. It's their modus operandi and generally it's the way they get things done: introduce something and block all other options (Lightning headphone connector, anyone?).
I guess they can afford to be that arrogant. Can't say I'm a fan of such behavior, though.
We're certainly on that same page then.
Looking forward to it! More consolidation in terms of infrastructures/technologies/routing paradigms/etc can only be a good thing. The fewer chains and steps are needed in a workable setup the better it eventually will be for musicians (fewer things that can go wrong + less time wasted on setup rather than making music + less technical complexity = moar win for everyone).
@brambos and @Sebastian thank you both so much for your efforts and insights. What can musicians do to support you in your efforts and how can we lobby Apple to develop iOS in a way that is useful to developers?
Thank you very much. I appreciate the love of multi app work flows you have. I'm sure it is a challenge to communicate your discoveries with us on the forum in a language that is not native to you. To reach more people, I will need to think about how I can share ideas which are less dependent upon language.
@InfoCheck : Sebastian was right on the money when he said that Apple needs developer support to let their 'standards' thrive. The tools are there, the user community is there (still somewhat budding, but steadily growing) but it needs to be more enticing to become part of the iOS developer community. Apple can do a number of things to achieve that, such as...
...remove the frustrations from the development process (proper documentation, more consistent dev-forum support, a formal feedback channel to learn from developers: needs + wishes + learnings)
...facilitate marketing: a long-overdue audio/music category in the App Store, and promote music creation apps beyond just single-button-music-making apps or visual novelties that lack in the substance-department (I guess the appstore hipsters editors are a bit clueless about the actual music scene)
And plenty more things.. but those would be a good start.
I've also been thinking that they could establish the iPad Pro as a genuine content creation platform by going beyond the Pencil (i.e. not just visual content) and also integrating more high-end audio hardware - and promote it as such.
@brambos all of those ideas make sense to me. Which of Apple's many doors should we be knocking on?
I don't know that App Store editors are clueless so much as focused on mass markets while ignoring the collective potential of niche markets like music creation where there are more dedicated users.
Many pro markets can be classified as niche markets as well but they share significant usage requirements which aren't being met by Apple's current mass media consumption focus.