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.

12.9" iPad pro performance comparison

Howdy folks. does anyone here have both a 2015 iPad Pro 12.9" and a 2017 iPad Pro 12.9" ? How do they compare for music on iOS 12?

A few months ago I made the upgrade to the 2017 model, but oddly it feels like the CPU can't handle as much as my old 2015 model... I may be imagining things but I can't compare them because I had to sell the 2015.

If there is someone here who has both... JEALOUS! But also could you compare both devices on iOS 12 for CPU performance with music apps? I'm talking about a simple AUM patch with 3 or 4 Moog Model D patches running arps... or something similar. I'm getting crackles all over my 2017 and 200% + cpu meter when I open the UI of an AUv3 Model D.

Comments

  • edited January 2019

    @Hmtx said:
    Howdy folks. does anyone here have both a 2015 iPad Pro 12.9" and a 2017 iPad Pro 12.9" ? How do they compare for music on iOS 12?

    Im also very much interested in this topics!

    A few months ago I made the upgrade to the 2017 model, but oddly it feels like the CPU can't handle as much as my old 2015 model...

    I already read this many times here in the forum. Is it true? If so, a 2017 Pro seems at a bad investment for me. I like to know...

    I'm getting crackles all over my 2017 and 200% + cpu meter when I open the UI of an AUv3 Model D.

    Same here with a 2017 12.9 Pro!

    In this AUM Screenshot i have just one Model D and one instance of Model 15 loaded.
    Model 15 plays an Arpeggio (DSP at around 47% with an Buffer Of 256)

    When I just move the Model 15 AU-Window in AUM DSP goes up to 87% and I get crackles.
    When I close the UI DSP went down to 37%

    Together with Model D (both synths playing arpeggios with no GUI i have 40% DSP.
    With open Model D window 47-60% DSP, moving the window up to 73 DSP. When I also open the Model 15 window I get 69-70% when I move the window it goes nearly 90%

    A third Moog Instance is almost not possible with a open GUI only if I close all windows in AUM I can get a crackle free Audio .

    When I move a open window also the arpeggio speed goes down

    That’s not normal isn’t it? 😎
    @MoogMusicInc ?

    Edit//
    I forgot to mention I’m running IOS 12.1.3 , no other apps open and the iPad got an fresh reset before starting.

    I was hoping the iOS 12.1.3 update would also have a positive effect for 2017 Pro models but it doesn’t seems so. 😩

    With an iPad Pro 10.5 it’s quite similar!

  • Have you guys tried different settings in M15?
    From manual:

    MINIMAL iOS SIGNAL PROCESSING
    This option improves the audio quality of your Model 15 by minimizing the amount of signal processing in the host device, such as the automatic gain control (AGC). This may cause the App to sound much quieter on your device.
    NOTE: This setting is also known as Measurement Mode in other iOS applications.

    ECO MODE
    Using the ECO MODE reduces the CPU load and improves battery life by only processing the modules that are active in the current Preset. With Eco mode off, the Model 15 generates a constant CPU load and avoids iOS lags.
    NOTE: When in the ECO MODE, switching from a Preset with few active modules to a new Preset with many active modules, the CPU may take a moment to come up to speed, and audio crackling may occur briefly.

    The first one should be handled by host app, so you can ignore it.
    But the second should improve things. Change the settings in standalone and then run it as AU.

  • edited January 2019

    Thanks a lot for the hint @recccp ! 👍

    I just turned the minimal iOS signal processing ON and the ECO mode off.
    With two instances it have a positive effect here. With Model D and 15 UI Open i have just 56% DSP and i can move both windows without crackles, very fine! 😊

    I can now open a third instance (Model 15) but I need to close all other windows if I need the GUI of the third instance. With moving around the window I get crackles. No moving , just turning the controls works fine with three different moogs/arpeggios. (DSP between 63 and 80). All windows closed 53-60 DSP 👍

    These settings you are mentioning I just overlooked up to now!

    Thanks again, this was very helpful! 😊

  • edited January 2019

    @chandroji said:
    Thanks a lot for the hint @recccp ! 👍

    I just turned the minimal iOS signal processing ON and the ECO mode off.

    You want to have ECO mode ON, to reduce CPU - this means Model 15 and Model D will only process active modules.

    I had similar issues on an iPad Pro 2017 with CPU overload, but ECO mode ON solved it.

    Displaying the GUI of Model 15 in particular does cause quite a DSP meter hike, because of the complexity of the GUI.

    It's possible that limiting screen refresh rate to 60Hz might made a difference here ( Settings > Accessibility > Display Accommodations > Limit Frame Rate) but I haven't done a side by side comparison. In theory, limiting refresh rate would lower CPU usage if the Moog apps were using a 120Hz refresh rate.

  • edited January 2019

    @craftycurate said:

    @chandroji said:
    Thanks a lot for the hint @recccp ! 👍

    I just turned the minimal iOS signal processing ON and the ECO mode off.

    You want to have ECO mode already ON, to reduce CPU - this means Model 15 and Model D will only process active modules.

    Thanks for mentioning it @craftycurate !
    Before I had the ECO mode already ON that’s why I turned it OFF.
    Tomorrow I will try different settings as well. I’m curious now... 😊

  • edited January 2019

    @chandroji Would you mind listing the presets you've used?
    It's hard to do any comparison without knowing that.

    Edit: Just loaded 2 instances of Model 15 and 2 instances of Model D in apeMatrix, each with a randomly chosen preset, played them with 2 voices polyphony on an iPad 2018 with iOS 11.4.1 and I get 58% cpu load, no crackling. It seems that changing "Eco" mode in M15 has no effect for the AUv3.

  • edited January 2019

    It would be great to share some actual Audiobus/AUM/apematrix sessions to make an accurate comparison.
    Also what sample rate and buffer size are being compared? This will have a big difference.

    I always have the 120hz display setting off as it's not necessary and think it might interfere with the processing :)

  • Hey guys,

    When running Model 15 as an AUv3 ECO mode is always on and minimal signal processing has no effect since that is being handled by the host (also named measurement mode).

    @chandroji ideally, the arpeggio should not slow down when doing GUI interactions, but when our apps run as AUv3s there's a very limited about of control that we have. We'll take a look, but we might not be able to improve this.

    Also please note that we have an update of Model 15 waiting to release that does have a series of engine improvements. Sadly, there's a problem with Xcode 10.1 that prevents us from making this release public. If we let this version out, AUv3 usage of Model 15 will be frequently killed. This is due to how Apple has changed how the memory usage is calculated. The maximum allowed limit is reached very quickly now, causing iOS to kill the AUv3 instance. We've been in touch with Apple engineering about this in the hope that this can be addressed in the near future. We've not been able to find any workarounds for this.

    <3 your friends at Moog.

  • thanks very much Moog for making these astonishing apps! Good to know that ECO mode is always on in AUv3.

  • @MoogMusicInc said:
    Hey guys,

    Thanks for the info. :)
    Not sure if it's the same issue, but Sugar Bytes recently updated Aparillo which had an instancing issue. They said they found a workaround. Maybe worth comparing notes with them. (although no idea if it was due to memory restrictions)

  • @MoogMusicInc said:
    Hey guys,

    When running Model 15 as an AUv3 ECO mode is always on and minimal signal processing has no effect since that is being handled by the host (also named measurement mode).

    @chandroji ideally, the arpeggio should not slow down when doing GUI interactions, but when our apps run as AUv3s there's a very limited about of control that we have. We'll take a look, but we might not be able to improve this.

    Also please note that we have an update of Model 15 waiting to release that does have a series of engine improvements. Sadly, there's a problem with Xcode 10.1 that prevents us from making this release public. If we let this version out, AUv3 usage of Model 15 will be frequently killed. This is due to how Apple has changed how the memory usage is calculated. The maximum allowed limit is reached very quickly now, causing iOS to kill the AUv3 instance. We've been in touch with Apple engineering about this in the hope that this can be addressed in the near future. We've not been able to find any workarounds for this.

    <3 your friends at Moog.

    I thought that the memory restriction for AU is already gone or will be gone soon.
    It is not good to hear that Apple seems to have other plans.

    This can only prevented, when as much audio App developers as possible complain at Apple, I think.

  • edited January 2019

    I don't think anyone has posted a comparison yet... maybe it is wishful thinking that there's someone out there with both 2015 and 2017 iPad Pro 12.9s.

    So, can someone with a 2015 iPad Pro 12.9" test this exact setup to compare?

    For consistency, use these settings:

    • Settings> General> Accessibility> Display Accomodations> Limit Frame Rate - ON
    • hard reset
    • cellular and wi-if OFF (airplane mode)
    • in AUM, measurement mode ON, Sample Rate 44100, buffer size 256, High Quality -ON

    Here is a basic AUM preset with 3 instances of Moog Model D to test https://forum.audiob.us/uploads/editor/fo/dl6n3w98ssu2.zip you just have to unzip it in Audioshare first.

    on my 2017 12.9 I can open the preset, and hold a single note and all 3 instances play fine (with arps). CPU stays at about 55%. If I open up any of the UI for Model D, then the CPU meter jumps to 85% but no crackles.

    I'm curious how the 2015 compares to this performance.

  • edited January 2019

    also, thanks everyone for the replies, but we need a bit more info. ;)

    Could each of you update your tests with this:

    • sample rate ___
    • buffer size ___
    • measurement mode on?
    • Limit Frame Rate ON?

    without that, there's really no reference point or way to compare.

  • @MoogMusicInc said:
    Hey guys,

    When running Model 15 as an AUv3 ECO mode is always on and minimal signal processing has no effect since that is being handled by the host (also named measurement mode).

    @chandroji ideally, the arpeggio should not slow down when doing GUI interactions, but when our apps run as AUv3s there's a very limited about of control that we have. We'll take a look, but we might not be able to improve this.

    Also please note that we have an update of Model 15 waiting to release that does have a series of engine improvements. Sadly, there's a problem with Xcode 10.1 that prevents us from making this release public. If we let this version out, AUv3 usage of Model 15 will be frequently killed. This is due to how Apple has changed how the memory usage is calculated. The maximum allowed limit is reached very quickly now, causing iOS to kill the AUv3 instance. We've been in touch with Apple engineering about this in the hope that this can be addressed in the near future. We've not been able to find any workarounds for this.

    <3 your friends at Moog.

    Is this only related to Model 15? Or does Model D have the same issue with Xcode 10.1?

  • Apple seems to not have any plans to remove the restriction, in fact they have tightened them and now even take UI rendering into account, which is what pushes Model 15 past the boundary so easily when compiled with Xcode 10.1.

    @tja said:

    @MoogMusicInc said:
    Hey guys,

    When running Model 15 as an AUv3 ECO mode is always on and minimal signal processing has no effect since that is being handled by the host (also named measurement mode).

    @chandroji ideally, the arpeggio should not slow down when doing GUI interactions, but when our apps run as AUv3s there's a very limited about of control that we have. We'll take a look, but we might not be able to improve this.

    Also please note that we have an update of Model 15 waiting to release that does have a series of engine improvements. Sadly, there's a problem with Xcode 10.1 that prevents us from making this release public. If we let this version out, AUv3 usage of Model 15 will be frequently killed. This is due to how Apple has changed how the memory usage is calculated. The maximum allowed limit is reached very quickly now, causing iOS to kill the AUv3 instance. We've been in touch with Apple engineering about this in the hope that this can be addressed in the near future. We've not been able to find any workarounds for this.

    <3 your friends at Moog.

    I thought that the memory restriction for AU is already gone or will be gone soon.
    It is not good to hear that Apple seems to have other plans.

    This can only prevented, when as much audio App developers as possible complain at Apple, I think.

  • The same issue is present for Model D, but its UI resources are much less than Model 15. So it's extremely rare to actually push it past the point of iOS killing the AUv3 instance. It is possible now though.

    @realdawei said:

    @MoogMusicInc said:
    Hey guys,

    When running Model 15 as an AUv3 ECO mode is always on and minimal signal processing has no effect since that is being handled by the host (also named measurement mode).

    @chandroji ideally, the arpeggio should not slow down when doing GUI interactions, but when our apps run as AUv3s there's a very limited about of control that we have. We'll take a look, but we might not be able to improve this.

    Also please note that we have an update of Model 15 waiting to release that does have a series of engine improvements. Sadly, there's a problem with Xcode 10.1 that prevents us from making this release public. If we let this version out, AUv3 usage of Model 15 will be frequently killed. This is due to how Apple has changed how the memory usage is calculated. The maximum allowed limit is reached very quickly now, causing iOS to kill the AUv3 instance. We've been in touch with Apple engineering about this in the hope that this can be addressed in the near future. We've not been able to find any workarounds for this.

    <3 your friends at Moog.

    Is this only related to Model 15? Or does Model D have the same issue with Xcode 10.1?

  • @MoogMusicInc said:
    The same issue is present for Model D, but its UI resources are much less than Model 15. So it's extremely rare to actually push it past the point of iOS killing the AUv3 instance. It is possible now though.

    @realdawei said:

    @MoogMusicInc said:
    Hey guys,

    When running Model 15 as an AUv3 ECO mode is always on and minimal signal processing has no effect since that is being handled by the host (also named measurement mode).

    @chandroji ideally, the arpeggio should not slow down when doing GUI interactions, but when our apps run as AUv3s there's a very limited about of control that we have. We'll take a look, but we might not be able to improve this.

    Also please note that we have an update of Model 15 waiting to release that does have a series of engine improvements. Sadly, there's a problem with Xcode 10.1 that prevents us from making this release public. If we let this version out, AUv3 usage of Model 15 will be frequently killed. This is due to how Apple has changed how the memory usage is calculated. The maximum allowed limit is reached very quickly now, causing iOS to kill the AUv3 instance. We've been in touch with Apple engineering about this in the hope that this can be addressed in the near future. We've not been able to find any workarounds for this.

    <3 your friends at Moog.

    Is this only related to Model 15? Or does Model D have the same issue with Xcode 10.1?

    Thanks for the explanation, I find it interesting that this is an Xcode bug instead of an iOS bug.

  • Wait, what? I thought that one of the advantages of iOS12 was lifted memory for AUv3.?

  • So did I. Can’t remember where I read it, but do remember it being one of the reported advances....but was on Pro devices only I think...

  • Wouldn't it be great if we finally had some definitive information on the auv3 memory limits for each iOS device? :D

  • edited January 2019

    @MoogMusicInc said:
    Hey guys,

    When running Model 15 as an AUv3 ECO mode is always on and minimal signal processing has no effect since that is being handled by the host (also named measurement mode).

    @chandroji ideally, the arpeggio should not slow down when doing GUI interactions, but when our apps run as AUv3s there's a very limited about of control that we have. We'll take a look, but we might not be able to improve this.

    Also please note that we have an update of Model 15 waiting to release that does have a series of engine improvements. Sadly, there's a problem with Xcode 10.1 that prevents us from making this release public. If we let this version out, AUv3 usage of Model 15 will be frequently killed. This is due to how Apple has changed how the memory usage is calculated. The maximum allowed limit is reached very quickly now, causing iOS to kill the AUv3 instance. We've been in touch with Apple engineering about this in the hope that this can be addressed in the near future. We've not been able to find any workarounds for this.

    <3 your friends at Moog.

    Thanks a lot for listening to us @MoogMusicInc !
    We all love your incredible good sounding Apps and we appreciate your help here! 😊

    When running Model 15 as an AUv3 ECO mode is always on and minimal signal processing has no effect since that is being handled by the host

    I’m quite surprised because after switching the settings in standalone mode I loaded the same AUv3 session in AUM and i noticed a remarkable improvement. The DSP went down and i was able to open at least one Model 15 instance more without crackles. 😎

    Anyway, I think I don’t really need 4 simultaneous instances of M15 . Two Model 15 at the same time would be enough for me! 👍

    I think one of the main reasons to load as much iOS Moog synths we can is to benchmark our iPad power.... 😎

    😊

  • @Carnbot said:
    It would be great to share some actual Audiobus/AUM/apematrix sessions to make an accurate comparison.
    Also what sample rate and buffer size are being compared? This will have a big difference.

    I always have the 120hz display setting off as it's not necessary and think it might interfere with the processing :)

    yeah thanks for suggesting this. Here's an AUM preset to test:

    So, can someone with a 2015 iPad Pro 12.9" test this exact setup to compare?

    For consistency, use these settings:

    • Settings> General> Accessibility> Display Accomodations> Limit Frame Rate - ON
    • hard reset
    • cellular and wi-if OFF (airplane mode)
    • in AUM, measurement mode ON, Sample Rate 44100, buffer size 256, High Quality -ON

    Here is a basic AUM preset with 3 instances of Moog Model D to test https://forum.audiob.us/uploads/editor/fo/dl6n3w98ssu2.zip you just have to unzip it in Audioshare first.

Sign In or Register to comment.