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.

Moog Model D 1.3.2 update is out

1235711

Comments

  • @uncledave said:
    You cannot switch auto update off for a single app. The "Background App Refresh" setting applies to the app refreshing itself, getting new data, etc. It really only applies to apps like news or weather, which rely on dynamic data. You can turn off App Updates for all apps in the App Store settings. That's what I do. AppStore still shows me a tag when updates are available, and I can update selectively, as desired.

    Thanks! I didn’t know it.

  • @MoogMusicInc said:

    Interesting and thanks so much for testing more.

    On the iPad Air 2 we have with iOS 14.3, we can run two Model D instances in AUM at 512 buffers size with only 79% of CPU usage. We're upgraded to iOS 14.4.2 on that device now, you never know.

    Yeah, those updates can be 'tricky' at times.

    Don't know yet how iPadOS14.5 will affect things when it drops...
    ...still quite a bunch of AUv3 related things need fixing.

    The 'Missing AUv3' doesn't create any entries to the system logs...
    I suspect it's iOS memory management that wipes out the AUv3 cache since it's rebuilt when rebooting the device.
    (This 'bug' happens more easily on devices with a LOT of AUv3's and is less likely to happen with only a few installed).

    For now I'm happy with the performance of Model D and since the Air 2 is quite old I've settled with 512 buffer to be able to run a bunch of other apps and effects at the same time.

    At some point I'll check the difference when using an external audio interface (Steinberg UR-242) at various sample-rates.
    (The current tests were all done using iPad Air 2's built-in speaker).

    Cheers!

  • @MoogMusicInc said:
    Hi everyone,

    A quick update, we think we have a version ready but sadly several of our old devices have developed bulged batteries and don't hold their charge, which makes them behave strangely and hard to test. So we've submitted new versions to TestFlight for external testing and as soon as Apple approves them, we'll post a public link here. We would very much appreciate it if you could try those once they're available and let us know if they fix the problem on your device.

    <3 your friends at Moog

    Wow. Seems like you really screwed this up at the beginning but you owned up to it and the way you have been communicating and handling damage control and improvement since is very impressive. Respect.

  • Following yesterday’s update I was able to run 4 instances (2mono+2poly) @512
    Today (after update and reboot) 6 instances (all poly with 4 notes) @512 or 5 @ 256
    Air3 13.7

    Thanks! :)

  • I did a test last November in Cubasis 3 to check how much the different number of Model D AU instances load the CPU. (Original purpose of the test was to compare the multi core vs single core performance of CB3)
    Now I repeated the test. You can see the results below.

    DSP load vs number of modelD instances:
    Nov ‘20 (v1.2.12) —> Apr ‘21 (v1.3.3)
    1: 14-15% —> 44%
    2: 28-30% —> 41% (no mistake, it’s less than @ 1 instance)
    3: 45-48% —> 46%
    4: 58-60% —> 63%
    5: 74-80% —> 77%
    6: 94-98% —> 93%

    iPad model: Air 3
    OS: 13.7

    What I also noticed that model D does not load the CPU in idle which was not the case with the previous versions.

  • I got to 7 open instances playing simultaneously on my iPhone 11 and it was around 93. I tried one more but my cpu said “sppppprbbt” and aum froze a bit

  • I'm on a first gen 9.7" iPad Pro with the latest beta OS. The new update definitely performs better. In standalone mode, it works pretty well with a small bit of glitching that seem to be related to UI interactions and specifically with things that might have to do with system frameworks -- like views changing or moving.

    In AUM, I'm at 256 samples and 48kHz, it runs nearly perfectly when the UI is closed. With the UI open, there are some glitches. I noticed that it glitched a lot when the OS started to recognize a swipe up gesture from the bottom edge of the screen.

  • @GLacey said:
    I did a test last November in Cubasis 3 to check how much the different number of Model D AU instances load the CPU. (Original purpose of the test was to compare the multi core vs single core performance of CB3)
    Now I repeated the test. You can see the results below.

    DSP load vs number of modelD instances:
    Nov ‘20 (v1.2.12) —> Apr ‘21 (v1.3.3)
    1: 14-15% —> 44%
    2: 28-30% —> 41% (no mistake, it’s less than @ 1 instance)
    3: 45-48% —> 46%
    4: 58-60% —> 63%
    5: 74-80% —> 77%
    6: 94-98% —> 93%

    iPad model: Air 3
    OS: 13.7

    What I also noticed that model D does not load the CPU in idle which was not the case with the previous versions.

    Keep in mind: the CPU numbers are not good indicators until you approach 100%....in the lost above, the variance with a few instances is more likely a measure of OS throttling and nothing about the AU’s performance.

  • edited April 2021

    Model D 1.3.3
    2019 iPad iOS 14.4.2
    Host is NanoStudio 2
    5 instances each with NS2 Algoverb applied
    NO ISSUES



  • This is weird, yet another Model D 1.3.3 update just dropped and now I'm getting 80% with two instances and 512 buffer!
    I'll keep on using 1024 buffer for some extra headroom just in case :)
    (iPad Air 2, iPadOS14.4.2).

    So for now I'm happy again, thank you @MoogMusicInc !
    /Samuel

  • @Samu said:
    This is weird, yet another Model D 1.3.3 update just dropped and now I'm getting 80% with two instances and 512 buffer!
    I'll keep on using 1024 buffer for some extra headroom just in case :)
    (iPad Air 2, iPadOS14.4.2).

    So for now I'm happy again, thank you @MoogMusicInc !
    /Samuel

    Weird! The App Store has been particularly glitchy lately, even corrupting binaries after upload.

    Really glad that you're now seeing the same numbers as we do!

  • @anickt said:
    Model D 1.3.3
    2019 iPad iOS 14.4.2
    Host is NanoStudio 2
    5 instances each with NS2 Algoverb applied
    NO ISSUES



    Awesome, thanks so much for the clear measurements and screenshots! Very much appreciated!

  • @Philandering_Bastard said:
    97% CPU On my Air2.

    Soo, no?

    Size matters

  • @RUST( i )K said:

    @Philandering_Bastard said:
    97% CPU On my Air2.

    Soo, no?

    Size matters

    Sigh. I guess the law‘s the law. Here goes:

  • @mrufino1 said:

    @GLacey said:

    @BCKeys said:

    I believe that if you got the Model D update notification before you turned off the automatic updates, you will still get the automatic update for Model D.. In other words, it's like a waiting list that you get on and can't get off except by updating.
    The defects of iOS..
    But then, unless you had a concert scheduled tonight, Moog is really concerned by solving this issue as fast as possible :)

    Yeah, luckily I didn’t plan to give a concert at Wembley tonight 😋

    The good news is that if you did, there wouldn’t be much of a crowd, so perfect time to have a non working setup.

    Or, if you follow the news of what happens in our political process here in the USA (if you’re not in the USA), maybe your concert was scheduled to be held at wembley landscaping?

    “Wembley Landscaping “ 😂

  • edited April 2021

    2017 12.9-inch iPad Pro
    with iPadOS 14.4.2

    Model D - Version 1.3.1 build 121
    Five instances of Model D in AUM - 63% DSP (when idle)

    Model D - Version 1.3.2 build 125
    Five instances of Model D in AUM - 73% DSP (when idle)

  • @DavidEnglish said:
    2017 12.9-inch iPad Pro
    with iPadOS 14.4.2

    Model D - Version 1.3.1 build 121
    Five instances of Model D in AUM - 63% DSP

    Model D - Version 1.3.2 build 125
    Five instances of Model D in AUM - 88% DSP

    Thanks so much! Were you able to update to 1.3.3?

  • @MoogMusicInc said:

    @DavidEnglish said:
    2017 12.9-inch iPad Pro
    with iPadOS 14.4.2

    >

    Thanks so much! Were you able to update to 1.3.3?

    Will try that next. Note the correction to the first post: it was actually 73% with five instances. I made a mistake in posting, in that the 88% was for six instances.

  • @MoogMusicInc said:

    @DavidEnglish said:
    2017 12.9-inch iPad Pro
    with iPadOS 14.4.2

    Thanks so much! Were you able to update to 1.3.3?

    Just updated to 1.3.3

    Model D - Version 1.3.3 build 126
    Five instances of Model D in AUM - 65% DSP (when idle)
    (with same AUM settings as before)

  • With six instances of version 1.3.3, the DSP increases to 78% when idle.

  • edited April 2021

    @DavidEnglish said:
    2017 12.9-inch iPad Pro
    with iPadOS 14.4.2

    Model D - Version 1.3.1 build 121
    Five instances of Model D in AUM - 63% DSP (when idle)

    Model D - Version 1.3.2 build 125
    Five instances of Model D in AUM - 88% DSP (when idle)

    Hm - but were you actually „using“ this five instances - I mean were you feeding midi in them and opening the Auv3-window and stuff like this?

    Cause yes - same Ipad here - IPad Pro 12,9 - 2017 - on IOS 13.7 -

    AUM Session - Model D 1.3.3 loaded as AUV3 - buffer size: 1024

    And when I just load 5 instances as in @DavidEnglish Screenshots ... I do get similar results of DSP - around 95%

    But as soon as I use the app I get very different results and super high DSP spikes especially when I close/open the AUV3-window ... spikes up to 150% DSP and instant crackles ...

    To be honest -

    I cant even run 2 instances without crackles ... the DSP spikes do always happen as soon as I open/close the Auv3 window - spikes of around 103-110% - but enough for terrible crackles

    While when the two instances are just running with closed AUV3-windows - the DSP is around 35% and runs smoothly ...

    Just a single instance runs fine and without any crackles - no matter what I do with the window ...

    The built before was basically the same for me - crackles with 2 instances - as soon as I touch/move/open/close the Auv3-window - just the spikes were higher - around 120-130% DSP

    @MoogMusicInc so - no - not a real improvement for me - even with the new built - especially since I was abled to run at least 2 or 3 instances of Moogs App plus several other apps without running into any issues ... before the update ... when I remember correctly ...

    IPad Pro 12,9 - 2017 - on IOS 13.7

    AUM Session - Model D 1.3.3 loaded as AUV3 - buffer size: 1024

    1.3.2. - 2 instances of Model D - crackles while opening/closing AUV3-window

    1.3.3. - 2 instances of Model D - crackles while opening/closing AUV3-window

    1.3.3. - 2 instances of Model D - no crackles - just running - Auv3-window closed/untouched

  • @Bon_Tempi said:

    Hm - but were you actually „using“ this five instances - I mean were you feeding midi in them and opening the Auv3-window and stuff like this?

    No, it was a simple load in five instances from scratch. Everything else was untouched. There was no MIDI routing or audio effects.

    Also, note that I corrected the first post. It was actually 73% for five instances with version 1.3.2. It went down to 65% for five instances with version 1.3.3. With six instances, it was 88% with version 1.3.2 and is now 78% with version 1.3.3.

  • Thanks for the quick response and update! :)

    It's better, playable in standalone mode, but not as good as before.

    Occasional glitches in standalone mode, even with mono patches.
    One single instance in AUM and it reaches 95% CPU. I've played three notes with the PADS: OPUS patch and notes got stuck with eternal sustain and glitch noises, had to boot the device.

    iPad Air 1 iOS 12.5.1

  • @DavidEnglish said:

    @Bon_Tempi said:

    Hm - but were you actually „using“ this five instances - I mean were you feeding midi in them and opening the Auv3-window and stuff like this?

    No, it was a simple load in five instances from scratch. Everything else was untouched. There was no MIDI routing or audio effects.

    Also, note that I corrected the first post. It was actually 73% for five instances with version 1.3.2. It went down to 65% for five instances with version 1.3.3. With six instances, it was 88% with version 1.3.2 and is now 78% with version 1.3.3.

    I see - ok - and have you checked if it changes while actually using the instances?
    Do you experience something similar while opening/closing/moving the Auv3-window?

  • edited April 2021

    .

  • @FRibeiro said:
    Thanks for the quick response and update! :)

    It's better, playable in standalone mode, but not as good as before.

    Occasional glitches in standalone mode, even with mono patches.
    One single instance in AUM and it reaches 95% CPU. I've played three notes with the PADS: OPUS patch and notes got stuck with eternal sustain and glitch noises, had to boot the device.

    iPad Air 1 iOS 12.5.1

    Thanks! When you say before, do you mean Model D 1.3.1 or before that?

  • @cadetrim said:

    @MoogMusicInc said:

    Thanks so much! Were you able to update to 1.3.3?

    The performance of the latest 1.3.3 version on my device is not good.

    Model D - version 1.3.3 (i.e. 1.3.2 build 125)
    AUM Buffer Size : 512 frames
    iPad 6th Gen with iPadOS version 13.5.1

    2 instances of Model D in AUM - above 50% dsp (when idle) / above 70% (when idle with one inst GUI shown, spike above 100% occasionally)
    But the dsp spikes above 100% always and sound becomes glitchy when AUM being switched back from the multitask view with AUM the ONLY app in the background and only one instance being played.

    3 instances of Model D in AUM - above 70% dsp (when idle, hit above 100% occasionally ) / above 80% (when idle with one inst GUI shown, spike above 100% often)
    In this scenario, the sound always becomes gitchy with only one instances being PLAYED with its GUI shown.

    Little question, which one needs more processing power, Model D or Model 15?
    My Model 15 is still in the last 2.2.4 version, i.e. version 2.2.4 build 261, and it doesn't have all those issues. But it might not work well when it got updated.

    It sounds like you're testing with v1.3.2 and not v1.3.3. The about page should indicate Version 1.3.3 build 126. Could you double check?

  • edited April 2021

    @Bon_Tempi said:

    @DavidEnglish said:

    @Bon_Tempi said:

    Hm - but were you actually „using“ this five instances - I mean were you feeding midi in them and opening the Auv3-window and stuff like this?

    No, it was a simple load in five instances from scratch. Everything else was untouched. There was no MIDI routing or audio effects.

    Also, note that I corrected the first post. It was actually 73% for five instances with version 1.3.2. It went down to 65% for five instances with version 1.3.3. With six instances, it was 88% with version 1.3.2 and is now 78% with version 1.3.3.

    I see - ok - and have you checked if it changes while actually using the instances?
    Do you experience something similar while opening/closing/moving the Auv3-window?

    if I open one of the instance windows, it jumps around from 65% to 70% for a short time. It then settles back to 65%. Same with moving one of the instance windows around. Or adding the AUM keyboard and playing. Or even routing all five instances to the AUM keyboard and playing. It jumps up a few percentage points, then settles down after the moving or playing stops.

  • edited April 2021

    @MoogMusicInc said:

    It sounds like you're testing with v1.3.2 and not v1.3.3. The about page should indicate Version 1.3.3 build 126. Could you double check?

    Ah, you are right. I thought I jumped over 1.3.2, and Appstore showed the latest 1.3.3. I downloaded it, and it's still 1.3.2.

    I blame Apple for this. 😂

    I updated it again, and the performance is much better now. Many many thanks.

  • @DavidEnglish said:

    @Bon_Tempi said:

    @DavidEnglish said:

    @Bon_Tempi said:

    Hm - but were you actually „using“ this five instances - I mean were you feeding midi in them and opening the Auv3-window and stuff like this?

    No, it was a simple load in five instances from scratch. Everything else was untouched. There was no MIDI routing or audio effects.

    Also, note that I corrected the first post. It was actually 73% for five instances with version 1.3.2. It went down to 65% for five instances with version 1.3.3. With six instances, it was 88% with version 1.3.2 and is now 78% with version 1.3.3.

    I see - ok - and have you checked if it changes while actually using the instances?
    Do you experience something similar while opening/closing/moving the Auv3-window?

    if I open one of the instance windows, it jumps around from 65% to 70% for a short time. It then settles back to 65%. Same with moving one of the instance windows around. Or adding the AUM keyboard and playing. Or even routing all five instances to the AUM keyboard and playing. It jumps up a few percentage points, then settles down after the moving or playing stops.

    Ok - and all of this without any influence on the sound - no crackles?

    Weird - since we have the same iPad - just different IOS-versions - maybe the performance difference is grounded there ...

    But I am still skeptical about updating to IOS 14 due to the missing AUV3-issue .,,

    Hm.

Sign In or Register to comment.