Audiobus: Use your music apps together.

What is Audiobus?Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.

Download on the App Store

Audiobus is the app that makes the rest of your setup better.

Multiple loaded but unused Auv3 instances effect on CPU?

Hey I have a question about how audio units work in terms of memory usage:

If multiple instances are loaded, but only one is actually processing any input, do the other open instances also use up precious CPU?

My use case is loading multiple instances of an AU audio effect in different channels within AUM, and selectively bus sending the input audio through those independent channels one at a time.

I’d like to do this rather than use one instance and select different presets, because I find this to be a smoother way to change the applied effects for most apps since if this is done while sound is passing through there is a “shmorsooshwtwang!” kinda thing that often happens as the settings are changing with the preset.

Simply changing the bus send avoids this but my CPU is already overloaded so I’m trying to cut the fat wherever possible...

Comments

  • You ask about memory usage, then switch over to CPU usage, which is different. In fact, though, both are important, and yes, multiple instances consume more memory and CPU.

    How much is dependent on the plugin itself, what it’s doing, and how efficiently it’s been programmed. There’s no science for predicting or measuring these effects. Only trial and error can tell.

    But the basic answer is yes, more instances = more load.

  • example of very poor CPU optimisation is Moog Model D and Model 15 - they boh are eating same amount of CPU no matter if they are playing or not...

  • Slide the node to the left, where the eject button shows, and I think that it's no longer taxing the system, but still ready to re-load by swiping back to the right.

  • @animalelder said:
    Slide the node to the left, where the eject button shows, and I think that it's no longer taxing the system, but still ready to re-load by swiping back to the right.

    That is not the case. Some AUs may be written so that they aren't using many cycles when they aren't actively doing something, but sliding them out of the way in AUM doesn't do anything special other than make sure that their output isn't being sent anywhere.

  • @espiegel123 said:

    @animalelder said:
    Slide the node to the left, where the eject button shows, and I think that it's no longer taxing the system, but still ready to re-load by swiping back to the right.

    That is not the case. Some AUs may be written so that they aren't using many cycles when they aren't actively doing something, but sliding them out of the way in AUM doesn't do anything special other than make sure that their output isn't being sent anywhere.

    Thank you, I appreciate that information.

  • Thanks for the info. And yeah @wim, I often make that mistake of interchanging the terms memory and CPU...and actually what I’m really referring to is the DSP monitor in AUM that when gets high causes all kinds of problems, which I just kinda thought was more or less CPU related, but anyways you answered my question so thanks!

  • edited January 9

    @espiegel123 said:
    [...] but sliding them out of the way in AUM doesn't do anything special other than make sure that their output isn't being sent anywhere.

    Are we sure about this? Internally, all audio apps need to build an AU graph (even before we had auv3!). One could imagine that AUM would remove the node from the graph and rebuild the graph, reducing CPU load during audio processing (but not memory). I guess we need @j_liljedahl.

  • @dendy said:
    example of very poor CPU optimisation is Moog Model D and Model 15 - they boh are eating same amount of CPU no matter if they are playing or not...

    you are mistaken these apps are very well optimized, but they implement free running oscillators for a better emulation

  • @bleep said:

    @espiegel123 said:
    [...] but sliding them out of the way in AUM doesn't do anything special other than make sure that their output isn't being sent anywhere.

    Are we sure about this? Internally, all audio apps need to build an AU graph (even before we had auv3!). One could imagine that AUM would remove the node from the graph and rebuild the graph, reducing CPU load during audio processing (but not memory). I guess we need @j_liljedahl.

    You can test it. In AUM, load in a bunch of AUs that use a lot of CPU when they aren't doing anything. Load them until the CPU use is around 90% -- you may have to use a variety of AUs so as to not hit the memory limits for memory allowed by a single AU. Now let things stabilize. CPU may drop quite a bit. Keep adding them until when in a stable state they CPU use is up around 90%

    Now, go through and slide each AU left so that it isn't engaged. On my iPad gen 6 under iOS 12.3.1, the CPU meter will show only marginal changes after you disengage all the AU instruments and let the CPU stabilize.

    There may be AUs that manage their CPU use so that they use less CPU when idle. But simply disengaging an AU without ejecting it doesn't automatically free up resources. Which makes sense since you want them to be immediately active when you swipe to reengage them.

    I know that @Michael has spent a lot of time thinking about how one might accomplish getting CPU savings by disabling/re-enabling AUs not come up with anything. I imagine the same is true of @j_liljedahl

  • Ape Matrix seems to unload properly when off ( like cubase track disable)

    Shame AB and AUM done have this function as it would be great for big templates.

    I did request this for AUM but nothing. @j_liljedahl

  • edited January 9

    Sadly not. (Oops sorry esp)

    @animalelder said:
    Slide the node to the left, where the eject button shows, and I think that it's no longer taxing the system, but still ready to re-load by swiping back to the right.

  • edited January 9

    @wellingtonCres said:

    @dendy said:
    example of very poor CPU optimisation is Moog Model D and Model 15 - they boh are eating same amount of CPU no matter if they are playing or not...

    you are mistaken these apps are very well optimized, but they implement free running oscillators for a better emulation

    I don't see how eating same CPU even when plugin is not playing can be called as "well optimized" .. argument about free running oscillators sounds to me very much like nonsense (at least based on my coding knowledge)

    free running oscillator is basically just that every new voice starts with random oscillator(s) phase .. you really don't need to have running whole synth engine even when it is silent just to get free runing oscillators :-)

  • edited January 9

    @espiegel123 said:
    There may be AUs that manage their CPU use so that they use less CPU when idle. But simply disengaging an AU without ejecting it doesn't automatically free up resources. Which makes sense since you want them to be immediately active when you swipe to reengage them.

    I know that @Michael has spent a lot of time thinking about how one might accomplish getting CPU savings by disabling/re-enabling AUs not come up with anything. I imagine the same is true of @j_liljedahl

    It would not be trivial to do this on the AU host side, but possible. Save the AU's fullStateForDocument, unload the AU completely, and when the user wishes, simply reload the AU and restore fullStateForDocument.

    Though I must admit in my AU host that I'm toying around with, I also just bypass AUs instead of unloading them. For now at least :)

  • edited January 9

    @dendy said:

    @wellingtonCres said:

    @dendy said:
    example of very poor CPU optimisation is Moog Model D and Model 15 - they boh are eating same amount of CPU no matter if they are playing or not...

    you are mistaken these apps are very well optimized, but they implement free running oscillators for a better emulation

    I don't see how eating same CPU even when plugin is not playing can be called as "well optimized" .. argument about free running oscillators sounds to me very much like nonsense (at least based on my coding knowledge)

    free running oscillator is basically just that every new voice starts with random oscillator(s) phase .. you really don't need to have running whole synth engine even when it is silent just to get free runing oscillators :-)

    Yep, I was about to say the same. I have a modular synth that used to have all oscillators free running as well (that can easily go into the hundreds if you want, say, 16-voice polyphony and use lots of unison etc...). However, at some point you DO actually WANT synchronized oscillators, for certain FM things etc., so I re-coded it all. That means dynamic voice allocation. That is a huge hassle to implement correctly and efficiently, so I guess Moog might have done it to save a bit of development time (it's much easier than doing dynamic allocation). And they probably have a good marketing department that manages sells it as an advantage ;)

    (you're right of course -- free running oscillators can be emulated by modifying the start phase).

  • In AUM, when AU instruments are bypassed they are still active on the cpu, but the audio is bypassed. This was set during the beta to keep stability because when bypassing Audio units with midi playing there's a high chance of crashing the audio unit.

    So it was set to improve stability. Au effects when bypassed I think reduce load still though.

  • @Carnbot said:
    In AUM, when AU instruments are bypassed they are still active on the cpu, but the audio is bypassed. This was set during the beta to keep stability because when bypassing Audio units with midi playing there's a high chance of crashing the audio unit.

    So it was set to improve stability. Au effects when bypassed I think reduce load still though.

    AUM does however set the shouldBypassEffect property (even for non-effect AUs) while bypassed. So the AU could in theory use this to relax its CPU usage.

  • @j_liljedahl said:

    @Carnbot said:
    In AUM, when AU instruments are bypassed they are still active on the cpu, but the audio is bypassed. This was set during the beta to keep stability because when bypassing Audio units with midi playing there's a high chance of crashing the audio unit.

    So it was set to improve stability. Au effects when bypassed I think reduce load still though.

    AUM does however set the shouldBypassEffect property (even for non-effect AUs) while bypassed. So the AU could in theory use this to relax its CPU usage.

    Thanks Jonatan nice tip, I will definitely use that flag with my new AU!

  • @j_liljedahl said:

    @Carnbot said:
    In AUM, when AU instruments are bypassed they are still active on the cpu, but the audio is bypassed. This was set during the beta to keep stability because when bypassing Audio units with midi playing there's a high chance of crashing the audio unit.

    So it was set to improve stability. Au effects when bypassed I think reduce load still though.

    AUM does however set the shouldBypassEffect property (even for non-effect AUs) while bypassed. So the AU could in theory use this to relax its CPU usage.

    oh great, hopefully more developers will use that :)
    I'm finding I'm usually always up to the max CPU with the stuff I'm doing, hoping next gen ipads will have a nice bump in CPU power too :)

  • However, I'm thinking of adding an option to actually take the AU out of processing while bypassed (as used to be the case). In theory it should be possible for every plugin to handle that scenario.

  • @j_liljedahl said:
    However, I'm thinking of adding an option to actually take the AU out of processing while bypassed (as used to be the case). In theory it should be possible for every plugin to handle that scenario.

    Could be the best if bypass per AU can be controlled by midi too :smile:

  • This would be great for building large templates :-)

    @j_liljedahl said:
    However, I'm thinking of adding an option to actually take the AU out of processing while bypassed (as used to be the case). In theory it should be possible for every plugin to handle that scenario.

  • @j_liljedahl said:
    However, I'm thinking of adding an option to actually take the AU out of processing while bypassed (as used to be the case). In theory it should be possible for every plugin to handle that scenario.

    That would be super cussword awesome

Sign In or Register to comment.