One More Concern about AudioProcessorParameter classes


I’ve been watching for a while, and I see a lot of people resisting the impending removal of legacy parameter methods. I see the open question posted many times of what people’s specific qualms are. I mentioned mine some months ago, but haven’t been very active in the meantime, and didn’t get a response.

My concern is that I am working on a plugin wrapper that needs to maintain a number of duplicates of instances of another plugin. The purpose is microtonal music, something that is still undersupported, even in modern software. People have been suggesting other possibilities to me for years. I know there are other ways to make microtonal music, but I see no reason why this shouldn’t be one of them. It would certainly be the most intuitive for most composers.

Unlike a standard host, or a standard plugin, this will need to have several identical instances open all the time. Could be 10-15, or more, for more experimental composers (not quite my bag, but I’d hate to tell them it can’t be done because of breaking changes in JUCE).

To my understanding, then, I would need to create a set of parameter instances, for each parameter, for each instance, in order to have the duplicates listen to and follow the original all the time. That could be, e.g., 200 parameters each, for 15 instances, and if they’re floats, I suppose at least 8+ bytes per instance. 24 KB, probably several times more, if the names of the parameters are longer than a few characters, which they usually are.

I could be way off on this, and I’m open to correction, but it seems to me that having to create and keep track of actual objects for each parameter will inevitably use more memory than the old way, which IIUC does not need to maintain a constant list of all of the parameters; it just invokes them when they’re used. Not THAT much more memory, but it’s still the opposite of “better”. My project may be the only one that needs to use that many for a single plugin, but again - if I understand correctly - this will make JUCE less than ideal for the job, after months of people suggesting it to me as the best solution. Especially given my goals, I can’t fathom what would be the advantage of removing the legacy methods completely over leaving them with the warnings they currently have, or even as options that can only be enabled by setting certain flags.

Any clarification is much appreciated!

Why would you care about a few dozen kilobytes (or even megabytes) of memory use these days? I can see other problems happening (slowdowns due to algorithmic inefficiency, JUCE not supporting dynamic changes in parameter counts etc), but excessive memory use really wouldn’t come to my mind first. The plugins themselves likely allocate several megabytes each anyway.

I guess so. Maybe it’s not a huge price, but as far as I can tell unnecessary.
Maybe sparing memory is just an old habit.