Just wondering if anyone has experience with taming Ableton’s “Configure Mode” when it comes to AUv2 meta parameters.
The issue is that on an AU, when “configuring” (aka, choosing which params Ableton should expose in its custom UI), Ableton adds all parameters affected by the meta parameter. Here, I’ve just touched “Delay Amount” and all the “sub parameters” are currently withAutomatable(false).
I obviously have an extreme case (one meta param controls hundreds of individual harmonics) but just posting here in case anyone else knows a trick on how to get their AU cleaner in Ableton…
Non-automated parameters aren’t supported by many hosts.
My solution for using them is to add them to a “dummy” processor, and never add them to the real processor to avoid situations like the ones you describe.
Then all that’s left is to manually make sure they’re serialized to/from the preset if you’ve used a solution like the APVTS which won’t ‘know’ them automatically.
Do you know if these hosts are aware they don’t support the flag properly? I’m wondering if we as developers keep side stepping the issue through our own means, or if we just need to form an alliance to hammer their bug report forms.
I don’t, but I’d say they (depends on host, etc) probably are aware.
You can definitely report it to them. But… lets say Ableton Live will fix it in the next version, it will still be broken for users of Ableton Live 10, etc.
I think generally speaking it’s a mistake on a plugin dev side to expose your internal parameters to the host. Once you expose a parameter to the host it should be allowed to automate it, IMO.
I can see it both ways. The one reason I can prefer exposing them is for hardware control support. Having a control on your desk to swap a non-automable parameter would be useful. It’s still implied you should actively change it during playback, but it’s nice to not have to open the gui and use a mouse to change one thing.
Once you’ve allowed the user to automate something (w. hardware, or with the mouse, doesn’t matter), that now means they have the option to override your ‘meta’ parameters, and those can conflict.
If your code is ready for that - great! You probably don’t have the same problem as @sudara.
But… once you’ve let the user control over both the individual parameters and the meta parameter that moves several of them, you’ve opened yourself to the option of the user automating both and you need to resolve that somehow.
Appreciate your response here, thank you! Wouldn’t have come up with that dummy processor idea, though I think I’ve seen you recommend it before. My first thought was to simply store these in whatever format is most efficient for my dsp (and manually merge with state). Curious if your main motivation for doing that is to be able to keep the faux-typing and treat them the same as the other params.
My preference was to keep parameters exposed and automatable. However that’s become clearly unsustainable as my engine evolved. Exposed parameters are now into the thousands and (understandably) DAW UX and performance trends less and less ideal. Obviously not worth the tradeoff just to allow the manipulation of the release time of Harmonic #323 (which might sound cool in theory, but is useless in reality).
Once you expose a parameter to the host it should be allowed to automate it, IMO.
I agree with this. Was exploring the various options re: Ableton “configure” behavior on metas, curious if others have ran into the issue…
