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.

Quick Q about multi-out for devs or those in the know

GavinskiGavinski
in General App Discussion

Is it hard to add multi-out functionality to an app that doesn’t have it? I am currently on the beta for an app that would benefit a lot from it, wondering how hard it is to implement. Cheers

Comments

  • NeonSiliconNeonSilicon

    I'm unsure of what you are asking without more context. I understand that you might not be able to give more info since this is a beta you are asking about.

    But, here's a kind-of answer. Just setting up an AU to do multiple inputs and outputs is nearly trivial. You just need to to put the correct output information into parameter that the host queries and then change the number of busses you allocate when the host sends you the request to allocate resources.

    But, and this is a very big but, what the dev would need to do to actually use that in their AU would depend entirely on the way the code is structured. It could be nearly impossible without a complete rewrite. It could be really easy, like simply copying the data in one buffer to another buffer.

  • GavinskiGavinski

    @NeonSilicon said:
    I'm unsure of what you are asking without more context. I understand that you might not be able to give more info since this is a beta you are asking about.

    But, here's a kind-of answer. Just setting up an AU to do multiple inputs and outputs is nearly trivial. You just need to to put the correct output information into parameter that the host queries and then change the number of busses you allocate when the host sends you the request to allocate resources.

    But, and this is a very big but, what the dev would need to do to actually use that in their AU would depend entirely on the way the code is structured. It could be nearly impossible without a complete rewrite. It could be really easy, like simply copying the data in one buffer to another buffer.

    Ah, thanks a lot, good to know. Do you also know, (or anyone else for that matter) how much work is involved in exposing parameters?

  • NeonSiliconNeonSilicon

    @Gavinski said:
    [...]
    Ah, thanks a lot, good to know. Do you also know, (or anyone else for that matter) how much work is involved in exposing parameters?

    Exposing parameters how? If you mean the thing that AUM does where you see the little control to the left of the plugin, that is trivial. It is just setting a property on the AU.

    If you mean the MIDI mapping to parameters so the host can route MIDI control to the parameters, that's still pretty easy but a little more involved. For this, the dev needs to mark their parameters with the correct flags to let the host know what to do with them, and then they need to process the list of events as they come in with the render calls in the audio thread. This is mostly going to be doable with the code that is already there to respond to the parameter changes from the host and/or the AU's UI.

    Processing direct MIDI to the parameters is a different path but it is similar to the host MIDI parameter mapping deal.

    I should note that my comments are assuming that the AU is written directly using the AUAudioUnit class. If a dev is using an environment that wraps this up, like JUCE or the VST3 wrapper, it could be more difficult. I don't know that for sure though.

  • GavinskiGavinski

    @NeonSilicon said:

    @Gavinski said:
    [...]
    Ah, thanks a lot, good to know. Do you also know, (or anyone else for that matter) how much work is involved in exposing parameters?

    Exposing parameters how? If you mean the thing that AUM does where you see the little control to the left of the plugin, that is trivial. It is just setting a property on the AU.

    If you mean the MIDI mapping to parameters so the host can route MIDI control to the parameters, that's still pretty easy but a little more involved. For this, the dev needs to mark their parameters with the correct flags to let the host know what to do with them, and then they need to process the list of events as they come in with the render calls in the audio thread. This is mostly going to be doable with the code that is already there to respond to the parameter changes from the host and/or the AU's UI.

    Processing direct MIDI to the parameters is a different path but it is similar to the host MIDI parameter mapping deal.

    I should note that my comments are assuming that the AU is written directly using the AUAudioUnit class. If a dev is using an environment that wraps this up, like JUCE or the VST3 wrapper, it could be more difficult. I don't know that for sure though.

    Thanks so much, pretty sure it is AU native, I will pass this info on, much appreciated, and thanks again for all your great apps!

Sign In or Register to comment.

© Vanilla Keystone Theme 2025