[BUG] AUV3/Official app version crashes GarageBand when using more than once.

[sks2002Official]

I’ll start this off with this, I don’t know how to code lol but I’m writing this as a users perspective. From what I’ve found out with my tunes, I can’t load some of them up because of this massive and detrimental bug. Basically if you load up a patch and then load up BYOD it would be alright. But once you’ve made a chain and your own plugin then make a new one/duplicate the track, it would crash the whole app booting you back to the Home Screen. Hopefully someone has since found the problem but it’s been a pain to know that the recent update has effectively broke the app.
I’ve done a screen record to show an example: https://www.dropbox.com/s/ddcqv145qr6v2h7/2022-12-06%209.48.59%20pm.mp4?dl=0

[jatinchowdhury18]

Thanks for reporting the issue! Unfortunately, I haven't been able to re-create the crashing behaviour on my iPad. Would it be possible to share a bit of additional information:

• Which version of iOS are you on?
• Which version of GarageBand are you running?
• Does the crash happen every time you duplicate a track or load a project? Or just sometimes?
• Are there any specific modules or presets in BYOD that seem to lead to crashes more often?

[sks2002Official]

I’m running the latest version of iPadOS (16.1.1).
I’m also running the latest version of GarageBand 2.3.13.
It does it to both of the things you’ve mentioned; I think it’s down to it having a lot of resources.
I don’t really know tbh, I can’t even load up any of my tracks.
the iPad I’ve been using is the iPad Pro 11 inch 3rd gen.

[sks2002Official]

It didn’t do this on the previous update.

[jatinchowdhury18]

Hey, sorry it took me a minute to get back to this! I've just opened a PR for a change that I think should fix this issue.

Do you have a development environment set up for building the plugin for iOS from source? If not, I can set up a TestFlight build with this change.

[sks2002Official]

I do have TestFlight installed. Could you set up a TestFlight build please?

[jatinchowdhury18]

Ah sorry GitHub closed the issue automatically. I've submitted a build to TestFlight, so hopefully it will be approved fairly soon. In case you don't have the link for the TestFlight, here it is: https://testflight.apple.com/join/vjQyAhGW

[sks2002Official]

I’ve downloaded this and it still crashed the file I’m trying to open up. Is there an email I can send the GarageBand song file onto so you can see the root problem?

[jatinchowdhury18]

Hmm... it doesn't make sense that you were able to download the new build since the App Store hasn't approved it for testing yet. If you're able to open the app in Standalone mode, it should show the build version. The new build should be version 1.1.1.

[sks2002Official]

That could be the reason, it’s on 1.0.11

[jatinchowdhury18]

Okay, the new build should now be available on TestFlight (at least according to an email I just got from the App Store).

[sks2002Official]

I’ve downloaded it and it’s still having the same problem. It’s still crashing when I try to load up my file.

[sks2002Official]

I’ve re-downloaded the older version 1.0.9 and that’s loading up my files.

[jatinchowdhury18]

Hmm, that's odd. Would it be possible to copy the diagnostic info from the latest TestFlight build, running in GarageBand, and share that in the issue?

In case you're curious about the under-the-hood things that are causing the issue, basically what's happening is that in between beta builds 1.0.9 and 1.0.10, we added a way for the plugin to update the host application when it's parameter names change (this happens whenever a new module is added to (or removed from) the "pedalboard"). For some reason GarageBand seems to crash when the plugin asks the host to update the parameter information more than once in quick succession, which sometimes happens when loading the plugin state, since several modules might be added to the pedalboard at once. So the crash is actually happening in GarageBand (not in the plugin), and frankly it's kind of annoying since other hosts (on desktop and iOS) don't seem to have this issue. Anyway, I guess the "fallback" solution could be to turn off parameter name updates for GarageBand altogether... I'll take a look and see if that's something I can do from inside the plugin.

[sks2002Official]

I can only load up my GarageBand diagnostic info crash file. I’ll email it to you.

[jatinchowdhury18]

Since there's been a bit of private correspondence and investigation going on here, I wanted to give a bit of public update for the status on this issue, and maybe ask for some opinions as well.

---

First, I've become pretty convinced that the "root cause" of this issue is a bug in GarageBand. Basically, whenever BYOD adds or removes a "pedal" from its "pedalboard", it sends the host a notification that the parameters have changed (this way the host can update the names of the parameters and so on). For AUv3 plugins, the way I've implemented this is as follows:

[au willChangeValueForKey: @"parameterTree"];
refreshParameters();
[au didChangeValueForKey: @"parameterTree"];

The reason I'm pretty sure this is a GarageBand bug is that even when I comment out the refreshParameters() call, the crash still occurs. Reading through the crash log shared by @sks2002Official appears to support this theory as well.

I've reported the issue to Apple via their Feedback Assistant, but I don't feel especially confident that the issue will be fixed from their end anytime soon.

My next idea was to have the plugin detect that it's running in GarageBand, and not report parameter name changes to the host if that's the case. Unfortunately, from talking with some other iOS devs, it doesn't look like there's any way to detect which host an AUv3 plugin is running in (at least on iOS).

---

So my next idea is to have a global setting in the plugin to determine whether the plugin will report parameter name changes to the host. Obviously this is not an ideal solution, but at the moment, I can't think of another way to make the plugin usable in GarageBand.

The next question is whether or not the setting should be on by default.

If the setting is on by default, then the GarageBand crash will still occur, until the user manually turns off the setting.

If the setting is off by default, then users working with other hosts will appear to have "lost" the parameter names functionality, until they manually enable the setting.

Normally I prefer to err on the side of whichever choice reduces crashes, but in this case I think I'd prefer to leave the setting on by default. Having parameter names update automatically is a pretty important feature, especially for a plugin like this, and so I'd rather improve the user experience for folks using hosts other than GarageBand, at least until GarageBand rectifies this issue on their end.

---

Anyway, I'd be happy to hear other folks' opinions, or maybe someone has an idea for an alternative solution.

[sks2002Official]

Sounds like a solid idea, hopefully Apple does fix it swiftly also, the switch within settings would make it handy.

[jatinchowdhury18]

Okay, there's a new TestFlight build up with the new setting option!

[sks2002Official]

How to disable it?

[jatinchowdhury18]

How to disable it?

When "Refresh Parameter Tree" is ON, the plugin will behave as it does now, which will likely crash GarageBand. When it's OFF, the parameter tree should never be refreshed, so the crash in GarageBand should never occur.

[sks2002Official]

I’ve tapped this a few times and it’s still doing the same glitch out bug.

[sks2002Official]

Don’t worry, I’ve got it to work, I had to make a new project to disable it.

[jatinchowdhury18]

Ah okay, that makes sense. Anyway, if it's working now with the work-around then I think the issue is resolved (or at least as well as it can be until GarageBand is updated). I could close the issue, but I think it would be better to leave it open for visibility in case someone else comes along who is having the same issue.

Thanks for your patience and feedback during the debugging process!