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 container app usefulness

2»

Comments

  • MonkeyDrummerMonkeyDrummer

    @pagefall said:
    do you think that this is a new policy? - Chris Randall (Audio Damage) has been complaining of the same. Seems like a big step backwards for developers.

    Maybe us developers could make a standard AU container app - perhaps open source it so we can all share it. dunno.

    I posted this exact suggestion to Chris on his twitter feed yesterday.

  • AndyPlanktonAndyPlankton

    @Samu said:

    @ka010 said:

    @Samu said:

    @ka010 said:

    @Samu said:
    When an app or extensions has multiple points of entry (ie. stand-alone and plug-in) it just creates confusion, that's how I see it.

    Interesting, where exactly do you see this adding complexity?

    For example users starting to request added features to the stand-alone app that are already provided by the 'hosts' and other plug-ins.

    Oh, yes from the dev-side sure, I was thinking from the users point of view.

    I'm thinking as an 'end-user' here. I seldom use stand-alone apps (with Gadget being the exception).
    Most of the time I just launch a host ApeMatrix, AUM, Cubasis or BM3 etc and continue from there...

    Hosts make it easier to 'find' a plug-in instead of having to traverse thru pages of apps on the home-screen.

    I use stand alone apps all the time....and then move into hosts/AU once I have something I want to work on...we are all different.
    an example...I'll load iBassist...get something going....fire up Rock Drum Machine...maybe mess around with just those 2 apps until I have a workable tune...then blocs wave to add some vocal loops....it is now that I start thinking about a host and can just load AUM and add the 3 open IAA apps I am using.

    @NeonSilicon said:

    @AndyPlankton said:
    [...] it can just appear as App of the day.

    I've got to admit that I hadn't actually considered that as a possible occurrence with my AU's :D.

    Aim higher then ;)

  • brambosbrambos

    Standalone containers are a massive waste of time and just raise the wrong expectations with users. I will no longer add every single ridiculously redundant connectivity and sharing standard to standalone apps when hosts offer all this stuff out of the box in a much more consistent and hassle-free way. Hence I feel that offering boilerplate containers is actually bad UX and will lead to disappointed users and irritated devs...

    But obviously I'm slightly biased ;)

  • [Deleted User][Deleted User]

    @brambos said:
    Standalone containers are a massive waste of time and just raise the wrong expectations with users. I will no longer add every single ridiculously redundant connectivity and sharing standard to standalone apps when hosts offer all this stuff out of the box in a much more consistent and hassle-free way. Hence I feel that offering boilerplate containers is actually bad UX and will lead to disappointed users and irritated devs...

    But obviously I'm slightly biased ;)

    I support your stance. Developers should be able to optimize their coding time by limiting their apps to AUv3 only. Apple created AUv3 for iOS and they should support it by having a straightforward app review process and a way to differentiate it on their App Store. I think there are plenty of users for AUv3 only apps to support this type of app. An incompetent Apple app review process should not be a barrier between AUv3 developers and their customers. The process Audio Damage had to go through to get their Enso app approved was just another example of poor customer service by Apple. Apple needs to listen to developers and their app users or fewer developers will be willing to develop AUv3 apps.

  • skratskrat

    There is really no reasonable argument to be forced to create AU plugins also as a standalone app and I think the way many developers did it in the past - just showing a text mentioning you need to open it in a host as an AU - is completely fine.
    Maybe one workaround to pass the review would be to show the completely functional UI but without the connections - no audio in and out, no MIDI in and out etc... with a clear warning that the app provides all the needed functionality when hosted as AU.
    Not sure if this helps, but my naive idea is that UI has to be already pretty flexible for AU so just “wrapping” it inside an app is not that much work. I am probably completely wrong 😂

  • realdaweirealdawei

    How many Apple employees (other than retail) use iOS for music? The answer is crickets.

  • NeonSiliconNeonSilicon

    Thanks for all of the input. I'm going to try to stick with the plan of using the containing app to deliver the manual. I simply don't like the idea of adding code to a project that serves no real purpose but still needs to be maintained.

    I also wanted to let everyone know that my appeal of the rejection has been approved and the new version of the AU has gone up on the App Store. So, there is at least some hope that the idea of using the container app as the manual will continue to work.

    For anyone who is interested in trying this approach, my appeal was based on sections 4.2 and 4.4 of the App Store Review Guidelines.

  • SevenSystemsSevenSystems

    As if programming wasn't hard enough already, and specialized niche programming in one of the most complex and least documented areas wasn't hard enough either, you then get to fight an omnipotent kafkaesque black box opponent 😂

  • CracklePotCracklePot

    @midiSequencer said:

    imo, Apple reviewers are allocated on a random basis and run through a set of standard tests (eg is the submitters name Chris, if so reject giving random reason!!).

    This one had me rollin’.
    :D

  • NeonSiliconNeonSilicon

    @SevenSystems said:
    As if programming wasn't hard enough already, and specialized niche programming in one of the most complex and least documented areas wasn't hard enough either, you then get to fight an omnipotent kafkaesque black box opponent 😂

    Yeah, clouds roll in and the sky turns to gloom whenever I even think I might have to go look something up in the docs. It's easier to randomly guess a name and hope auto-complete gets it and then go to the header files.

  • NeonSiliconNeonSilicon

    I'm reviving this old thread because the problem seems to be back. I've been trying for the last few days to get a new AU approved by the App Store. The reasons for the rejections this time are different from before but the underlying cause seems to be the same. This time, the reason given is that my app's metadata is being rejected. That is clearly nonsense because the metadata is exactly the same as every other AU I have. After three rounds of communication with Apple, I'm now being told I will have to provide a video of the AU being used -- not the application, but the extension. So, this is what makes me think this is a new directed attack on AU's that have minimal container apps.

    I haven't released a new app in awhile now, so I'm wondering if other devs have experienced a higher level of rejections lately.

Sign In or Register to comment.

© Vanilla Keystone Theme 2025