ENSO crashing in AUM with Long Memory enabled

If I enable Long Memory in ENSO, and save the session in AUM (using a few other apps like Aparillo, Ravenscroft, Shimmer), inevitably either ENSO will crash within AUM upon loading, or AUM itself will totally crash. Has anyone else encountered this? Seems to be bug...

Comments

  • Maybe you're reaching the AUv3 RAM limit?

  • @rs2000 said:
    Maybe you're reaching the AUv3 RAM limit?

    Yeah was wondering that. Maybe ENSO reserves too much RAM for the Long Memory function? However, if I don't save the session with Long Memory, but subsequently enable it in the session, it behaves fine.

  • edited March 29

    @SilentObserver said:

    @rs2000 said:
    Maybe you're reaching the AUv3 RAM limit?

    Yeah was wondering that. Maybe ENSO reserves too much RAM for the Long Memory function? However, if I don't save the session with Long Memory, but subsequently enable it in the session, it behaves fine.

    What about other hosts?
    ApeMatrix, Audio Evolution, Cubasis, Nanostudio 2, Beatmaker 3?
    Garageband?

    Edit: If subsequently enabling long memory helps, it looks like a RAM issue indeed. One iOS flaw is that developers can neither safely reserve nor monitor free memory. Again, for a mobile phone that's usually OK, but not for some music apps.
    Chris from AudioDamage might consider streaming long recordings to/from disk instead.

  • If I use 3 instances of ENSO or more inside AUM even with long memory off I get regular crashes of AUM. Had a really good session going last night lost the lot which was a shame. I hope we see some fixes soon.

  • @Jumpercollins said:
    If I use 3 instances of ENSO or more inside AUM even with long memory off I get regular crashes of AUM. Had a really good session going last night lost the lot which was a shame. I hope we see some fixes soon.

    Is AUM the only host that crashes with ENSO?

  • @Jumpercollins said:
    If I use 3 instances of ENSO or more inside AUM even with long memory off I get regular crashes of AUM. Had a really good session going last night lost the lot which was a shame. I hope we see some fixes soon.

    Yeah I can’t run three on my Air 2. Shame, I love using Enso.

  • @rs2000 said:

    @Jumpercollins said:
    If I use 3 instances of ENSO or more inside AUM even with long memory off I get regular crashes of AUM. Had a really good session going last night lost the lot which was a shame. I hope we see some fixes soon.

    Is AUM the only host that crashes with ENSO?

    Had a quick try with Cubasis and that seems ok, although I need to try multiple instances to be sure.

  • Crashed with two instances in ab3 for me. I had patterning 2 running into Refraktor. And then volt and iMono/Poly each with their own Enso. I was loving it. Then it melted down.

  • @rs2000 said:

    @Jumpercollins said:
    If I use 3 instances of ENSO or more inside AUM even with long memory off I get regular crashes of AUM. Had a really good session going last night lost the lot which was a shame. I hope we see some fixes soon.

    Is AUM the only host that crashes with ENSO?

    On my iPad 6th Gen , more than two instances kills Auria Pro.

  • Not had a crash with Enso yet on iPad Pro (2017). Audio Damage video talks about the long memory setting.

  • @rs2000 said:

    @SilentObserver said:

    @rs2000 said:
    Maybe you're reaching the AUv3 RAM limit?

    Yeah was wondering that. Maybe ENSO reserves too much RAM for the Long Memory function? However, if I don't save the session with Long Memory, but subsequently enable it in the session, it behaves fine.

    What about other hosts?
    ApeMatrix, Audio Evolution, Cubasis, Nanostudio 2, Beatmaker 3?
    Garageband?

    Edit: If subsequently enabling long memory helps, it looks like a RAM issue indeed. One iOS flaw is that developers can neither safely reserve nor monitor free memory. Again, for a mobile phone that's usually OK, but not for some music apps.
    Chris from AudioDamage might consider streaming long recordings to/from disk instead.

    It is indeed a RAM issue. Chris responded to my inquiry:
    Yeah, I think that’s because of the 150mb RAM allocation limit bug in AUv3. We thought that might occur, which is why we made it a button rather than a preference. I’ll see if I can’t figure out a way to keep it from crashing when that button’s on in AUM (like delaying the allocation until it is instanced or something.)

  • Any update on this, does anyone know? Enso is crashing in my AB3 with long memory enabled, with just 1 instance.

  • @richfobes said:
    Any update on this, does anyone know? Enso is crashing in my AB3 with long memory enabled, with just 1 instance.

    What hardware and OS version?

  • @SilentObserver said:
    If I enable Long Memory in ENSO, and save the session in AUM (using a few other apps like Aparillo, Ravenscroft, Shimmer), inevitably either ENSO will crash within AUM upon loading, or AUM itself will totally crash. Has anyone else encountered this? Seems to be bug...

    Have you tried deleting whatever you have looped in Enso inside AUM.... works for me & reduces CPU

  • from the developer:

    AudioUnits on iOS are only allowed 150mb total (including the UI and the entirety of the plugin’s operation) when opening. We added the “long memory” button so you could use the plugin once it had opened, utilizing the maximum allowable footprint of 350mb. However, as you’ve discovered, this is a bit of a hack, and attempting to reopen a session with a file that goes over the 150mb second limit will cause problems. The “long memory” button is really only for real-time sessions;

  • @barabajagal said:

    @SilentObserver said:
    If I enable Long Memory in ENSO, and save the session in AUM (using a few other apps like Aparillo, Ravenscroft, Shimmer), inevitably either ENSO will crash within AUM upon loading, or AUM itself will totally crash. Has anyone else encountered this? Seems to be bug...

    Have you tried deleting whatever you have looped in Enso inside AUM.... works for me & reduces CPU

    I had a specific instance the other day where I had rebooted the iPad, also cleared the RAM, but with only Ravenscroft and Factory running inside AUM (plus a file-player loop and a couple of reverbs), and EVERY time I hit record on ENSO (via a CC), I heard a click, briefly saw the CPU go way into the red (110% or so - was around 40-50% beforehand), and ENSO crashed. Every Single. Time. I then quit everything, did ANOTHER RAM clear, and this time it worked. Too afraid to use it for live use because of this - just can't trust it...

    Nothing to do with any loops in ENSO as it was completely empty when this occurred.

    And this is also only enabling Long Memory AFTER the app is open.

  • @SilentObserver said:
    Too afraid to use it for live use because of this - just can't trust it...

    Do you really expect to be able to trust an app that costs less than a pint for live work?

    Try using it in Audiobus 3. It only crashes in AUM for me.

  • @espiegel123 said:

    @richfobes said:
    Any update on this, does anyone know? Enso is crashing in my AB3 with long memory enabled, with just 1 instance.

    What hardware and OS version?

    iPad 6, v12.3.1

  • @richfobes said:
    from the developer:

    AudioUnits on iOS are only allowed 150mb total (including the UI and the entirety of the plugin’s operation) when opening. We added the “long memory” button so you could use the plugin once it had opened, utilizing the maximum allowable footprint of 350mb. However, as you’ve discovered, this is a bit of a hack, and attempting to reopen a session with a file that goes over the 150mb second limit will cause problems. The “long memory” button is really only for real-time sessions;

    Thanks for sharing this.

  • @rezidue said:

    @richfobes said:
    from the developer:

    AudioUnits on iOS are only allowed 150mb total (including the UI and the entirety of the plugin’s operation) when opening. We added the “long memory” button so you could use the plugin once it had opened, utilizing the maximum allowable footprint of 350mb. However, as you’ve discovered, this is a bit of a hack, and attempting to reopen a session with a file that goes over the 150mb second limit will cause problems. The “long memory” button is really only for real-time sessions;

    Thanks for sharing this.

    no prob

Sign In or Register to comment.