Hi all-
For a plugin concept I’m working on, the user can add a ‘voice’ to a ‘chord’ with five components needed to edit each voice, with a maximum possibility of 128 voices for a chord, making it hypothetically possible that there could be 640 concurrent components that would need to exist to manage a chord’s voices at the most extreme.
(though this would be a GUI nightmare, & I will eventually opt to simply swap out existing components to edit a different voice rather than have individual component groups available for each voice, but the question I’m about to ask remains.)
The TL;DR- I’d prefer to intelligently dynamically allocate components based on a particular user’s max voice count within an instance of the plugin, rather than always pre-allocating the most extreme case many users will never reach. I’ve been using OwnedArrays of my components for this.
Preferably, a user would only ever potentially risk a click or pop from a massive amount of dynamic memory allocation when the plugin is first instantiated, perhaps risking a brief one when they add a substantial amount of voices to a chord. What I don’t want is for clicks & pops to occur whenever the user re-opens the plugin editor window, given that I myself will often open & close windows during playback.
And so, my question is: is it a better practice to keep my OwnedArray of components in the Editor, or within the processor where they will persist? These components are of course exclusively used by the Editor (…though they modify values in the processor via the editor), but it seems to make sense to have them persist even when the editor no longer exists, in order to avoid clicks/pops from dynamic allocation of components upon reopening the editor.
Is components in the processor the best approach here, or is there something within JUCE philosophy that would be better that veterans can chime in with?