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 Store

Loopy Pro is your all-in-one musical toolkit. Try it for free today.

Audio Unit challenges?

So I have recently been playing around with ruisemaker and iSEM a lot. Amazing apps for sure in their own right but the best part of them so far has been the AUX protocol and the ability to load multiple instances. So what is stopping developers from making all their apps AUX? From synths to effects, seems like that's the way to go!

«13

Comments

  • There are quite a few recent threads with a lot of heated debate on this topic. Seems to be a polarising topic.

  • slow start and temporary politics...but AU is inevitable

  • edited July 2016

    I started a thread on the topic and a couple of forum members and developers shared their view points. My hope is Apple will provide better documentation and flesh out the standard more so it can reach its potential on iOS which I believe to be very significant.

  • @InfoCheck said:
    I started a thread on the topic and a couple of forum members and developers shared their view points. My hope is Apple will provide better documentation and flesh out the standard more so it can reach its potential on iOS which I believe to be very significant.

    Cool, must have missed that thanks

  • @sirdavidabraham said:
    slow start and temporary politics...but AU is inevitable

    AU Extensions are just not feasible to add for most existing apps. Apple has done a bad job at documenting how to make them and they're not doing anything to promote them. Which means that very little money can be made making them (zero, if you're adding them to an existing app, because previous customers get the update for free).

    If anything, it's a slow start with gradual deceleration.

  • @Sebastian said:
    If anything, it's a slow start with gradual deceleration.

    That's speculation. I see an increase of questions asked about Audio Unit implementation on developer forums, which seems to indicate that more developers are interested in- or actually working on AU projects at the moment.

  • edited July 2016

    It's not specuation. I can count the number of AU Extensions after a year (less than 25). Audiobus had that many a week after lauch, 100 after a month, 800+ now.

    I can check App Annie's revenue numbers for AU Extensions when they launch, which is 1/5th of what a standalone app would make.

    I'm not criticising developers making AU Extensions. I have lots of respect for them (you included). I'm just pointing out Apple's shortcomings to explain to users what went wrong.

  • As long as support for standard iOS technologies are included and supported I don"t see any major issues.

    I think one of the bigger challenges are around how apps share content between each other so they won't become 'lonely islands'.

    This is one of the many reasons why I'm so eager to see support for those basic features in iOS that make sharing easier. (iOS Sharesheet/Open In... and Document Picker).

    I'm no live-player so for me for an app to be able to export it's content is a key-feature, either as loop-export or track-freezing.

    My currently mostly used apps are Gadget (and the rest of the Korg line-up),. Cubasis, AudioShare and most currently available AUs and a few other synth apps that I record to Cubasis using IAA, and thaks to the work from Audiobus team I can use most of my synth-apps as IAA-Generators.

    Just a side note, has any of the AudioBus peolpe had a 'face to face' chat with the dude in charge of CoreAudio for iOS or the people who hold the presentations at the Keynotes?

    My gut feeling is that those people treat AudioBus as 'Not invented here' so it doesn't get the official recognition it truly deserves!

  • Yes, I don't question the numbers. But I think it's too early to make the "deceleration" statement.

    We're dealing with a niche market, a rather complex/undocumented technology, and developers with a lot of prior-investments (in terms of R&D effort) in other, somewhat similar, technologies. Any possible switchover to the new technology is always going to be slow and gradual.

    As with anything in the music software scene, this is going to be driven by indie developers who are not in it for making a living (and hence can take the risk of investing time in figuring out how to make an AUx). I don't see any user resistance against Audio Units (quite to the contrary).. Once the indie market thrives, it's much less of a risk for big-name devs to invest in R&D. But this is an inherently slow process unless Apple take some brute force action.

  • @brambos said:
    As with anything in the music software scene, this is going to be driven by indie developers who are not in it for making a living

    The opposite is true. We made Audiobus and keep pushing it because it's our full time Job. If you want to look at projects that don't go anywhere because they're a side project that nobody really depends on:

    OSC, Android's low latency audio framework, Android's inter-process-audio framework, Samsung's professional audio framework, JACK on iOS, I could continue this list if I wanted to.

    Once the indie market thrives, it's much less of a risk for big-name devs to invest in R&D. But this is an inherently slow process unless Apple take some brute force action.

    The opposite is true. Big names can easily release products for technologies that don't have mass appeal yet, because they don't have to be profitable. Ableton Link is an example - Ableton is not making a dime with it, It's just an investment that might pay off in the future.

  • Uhm... just to make sure @brambos: I'm not trying to offend you, Just trying to clarify. Sorry if I sound harsh. It's unintentional, I'm German. :(

  • @Sebastian said:
    Uhm... just to make sure @brambos: I'm not trying to offend you, Just trying to clarify. Sorry if I sound harsh. It's unintentional, I'm German. :(

    No offence taken; I'm Dutch - I think Germans sound polite by comparison :D

  • edited July 2016

    Since we have an expert here, is it my imagination or do I remember reading that AU developed for iOS should also be able to run on Mac?

    As an aside Germans get the credit for inventing the word Weltschmerz, which kind of sums up my feelings about the world atm.

  • The AU v3 (AU extension) documentation was lacking for iOS. It was basically nonexistent for OS X. That's why there's even less traction there.

  • @BiancaNeve said:
    Since we have an expert here, is it my imagination or do I remember reading that AU developed for iOS should also be able to run on Mac?

    Not directly, but most of the code (basically everything except the GUI part) is effortlessly portable to MacOS. So you'll have to create a new binary (the actual "app" file) for the Intel platform that MacOS runs on, but it is relatively straightforward. That's one thing that Apple have done well when creating the AUv3 framework.

  • I understand and respect Sebastian's viewpoint on AUx and am at the same time very glad of the format's existence and the commitment by certain developers to utilise it to it's fullest potential.

    Audiobus is a very elegant solution but becomes unwieldy for me in live use after 5-6 hosted apps. Long boot up procedures and Audiobus Remote becoming quickly too cluttered (icons too small to perform with). IAA without Audiobus is too clumsy for me and the erratic app switching process isn't viable for apps that need quick foreground tweaks. AUx is perfect to fill these specific niches of utility that don't require a full screen interface and the handing off of MIDI implementation to the host is a big boost to workflow. They're also essential for me because they can be 'state saved' outside of Audiobus.

    There are AUx's existing which fulfill every requirement that I have for them and more on the way that continue to refine and enhance the experience, so I have no issues with the small number of them. Fortunately, quality is presiding over quantity!

  • @brambos said:

    @BiancaNeve said:
    Since we have an expert here, is it my imagination or do I remember reading that AU developed for iOS should also be able to run on Mac?

    Not directly, but most of the code (basically everything except the GUI part) is effortlessly portable to MacOS.

    To illustrate:

    d6d.jpg 26.7K
  • @Sebastian said:
    @brambos said:

    @BiancaNeve said:
    Since we have an expert here, is it my imagination or do I remember reading that AU developed for iOS should also be able to run on Mac?

    Not directly, but most of the code (basically everything except the GUI part) is effortlessly portable to MacOS.

    To illustrate:

    That made my day, thank you! :D

  • edited July 2016

    @Sebastian said:

    @sirdavidabraham said:
    slow start and temporary politics...but AU is inevitable

    AU Extensions are just not feasible to add for most existing apps. Apple has done a bad job at documenting how to make them and they're not doing anything to promote them. Which means that very little money can be made making them (zero, if you're adding them to an existing app, because previous customers get the update for free).

    I'm not interested in most of the 800+ existing apps just a few key ones :smile:
    If there ever was a "less is more" case to made - AU would be right up there

  • Just to clarify: This is not an IAA vs AU X discussion. This is really just another thread about why there are so few AU Extentions.

  • For me, the interesting point in the AUx debate is that it seems to be creating a (gradiented) difference in opinion between what users want and what developers want to provide.

  • edited July 2016

    @Sebastian said:
    Just to clarify: This is not an IAA vs AU X discussion. This is really just another thread about why there are so few AU Extentions.

    I second this, and -as I explained in another thread- there is a very strong case to be made for having both standards healthily side by side. There certainly is overlap between the two but also a lot of functional potential that is in one but not the other and vice versa.

  • @OscarSouth said:
    For me, the interesting point in the AUx debate is that it seems to be creating a (gradiented) difference in opinion between what users want and what developers want to provide.

    It's really not about what developers want to provide. It's about that they're able to. Every developer would like to support every standard that users demand. There's just a trade off between amount of features a single developer can support and the support load and initial investment that has to be made.

  • AUs would be nice to have, but at this point the main draw (for me at least) to iOS music apps are the individual apps themselves. That we have Audiobus, Audioshare, and IAA is just kind of a nice little bonus.

    Make no mistake about it, the stars of the show are apps like: Animoog, iMS-20, Samplr, SECTOR, Borderlands, Patterning, Nave, Alchemy, SunVox, TC-11...

    The list goes on, fill in the blank with you favorite app. Add in some sweet MIDI controllers and you have a small feast with Fugue Machine, ChordPolyPad, etc. You get the idea.

    Not sure AUs would really change that, because some of the features of these single and solitary gems are attached to the app, strip them away and they become something less as an AU.

  • If I was a developer the biggest WTF would be the lack of a 'iOS Reference Host' to test the AU X's with!
    The same really goes for IAA-Instruments too.(They work differently depending on the host they are used with).

  • edited July 2016

    @Samu said:
    If I was a developer the biggest WTF would be the lack of a 'iOS Reference Host' to test the AU X's with!
    The same really goes for IAA-Instruments too.(They work differently depending on the host they are used with).

    The biggest WTF are recent changes that in Apples App Review Guidelines that basically forbid AU Extensions (and Keyboard Extensions, iMessage Extensions, MIDI Controllers, DAWs without their own audio generation) from being distributed on the App Store.

    Money quote:

    4.2.3 Your app should work on its own without requiring installation of another app to function.

    That's the amount of thought that Apple puts into their own guidelines. And please don't get me started on

    4.1 Copycats
    Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers.

    Just search the App Store for "Free Music Download iOS app" and laugh and laugh and laugh...

  • edited July 2016

    @brambos said:

    @BiancaNeve said:
    Since we have an expert here, is it my imagination or do I remember reading that AU developed for iOS should also be able to run on Mac?

    Not directly, but most of the code (basically everything except the GUI part) is effortlessly portable to MacOS. So you'll have to create a new binary (the actual "app" file) for the Intel platform that MacOS runs on, but it is relatively straightforward. That's one thing that Apple have done well when creating the AUv3 framework.

    Sorry, but I really have to rant about this:

    I've just googled it and I cannot find a single AU V3 plugin for the Mac.
    I'm certain there are some, but the fact that I cannot find any by googling 'AU V3 Mac plugin' or some combination of these words shows how hard it is for users/customers to find them and then purchase them. And if that's hard, then there's really very little incentive for developers to make them or update their existing plugins.

    And if it's so easy to make one, why is Ruismaker iOS only?

  • edited July 2016

    I totally agree with Sebastian here. In my eyes you can't compare AU for iOS with VST(i) or AU plugins not only for the reasons he mentions but also that iOS is a closed platform, while as a "hobbyist" you can produce the plugins without any problems (paying license fee, etc.) and distribute them the way you want. To develop an AU for iOS for a niche niche market is a going through a lot of hassle.

  • On a more positive note,

    6144 equalizer by DDMF by Christian Siedschlag
    https://appsto.re/gb/zr6mdb.i

  • edited July 2016

    In an ideal world, and purely as a technology example, all costs in both time and money aside I would like to see something like

    Gadget - Main App written as an AUx Host, that is IAA hostable. i.e Gadget app can run inside an IAA host, and use the IAA features for sync etc..for the sequencer start/stop and timing ..and then each individual gadget written as an AUx, that are then hosted inside Gadget app, these could be selectable just as they are now, and not open to loading any 3rd party AUx if Korg so wished, but could also be hosted directly in another AUx host (AUM/ModStep/Cubasis etc..) This could work for drum machine apps, multi FX apps....imagine Model 15 with each module as an AUx useable inside any AUx host.

    I am in not an iOS developer, and do not claim to know the IAA or AUx specs at all or the real technical challenges involved, just using what I have deduced from the many threads on this topic as to what might be possible.

    This would give users the flexibility to use all the components as they see fit within their workflow.

    The developer would be able to develop AUx components independently of other parts of an app, reducing time frame between releases, they could also monetise the components within an app rather than just the whole app, it provides more value to the user (and therefore could demand a higher price) than an IAP as it is useable in other AUx hosts.

    Might just be the heat here in the UK making me crazy, but it seems logical to me.

Sign In or Register to comment.