This is an interesting discussion, in part because it appears to highlight some differences between user expectations and the design philosophies of the device (
I’m only a hobbyist, but I enjoyed the experience of how Apple Mainstage works and lets you organize your patches in a hierarchy of (roughly) Set -> Song -> Instrument/Track, with the ability to hardware map around the hierarchy (next song, next patch, next patch for set, etc). It’s a fantastic piece of software for the price, but I prefer OSS, cross-platform tools.
I’ve envisioned similar use cases for the Duo where I could select a Bank and then use hardware controllers to flip between different Pedalboards, each of which may have a “SwitchTrigger” style pedal (for example).
What the plugins should do and what they actually do are 2 completely different things.
That doesn’t need to preclude:
- having a productive discussion about what challenges might exist today because of current implementations
- assessing whether existing plugins can meet the technical requirements of pre-load / fast-switching
- forming a roadmap for raising awareness and improving capability of plugins w.r.t. to these use cases
And on some specific plugins (fluidsynth based stuff), there will never be a possibility to have them pre-loaded and using low memory at the same time. They load the entire sf2 on ram.
Speaking for myself, I don’t see the need to support every plugin in existence under this mode. For me, I see it simply as ‘use the tools that are right for this job’. I have a garage full of tools but I don’t get them all out every time I sweep the patio. Some tools I only use occasionally, and they do take extra preparation and caution to use. I don’t think there needs to be an expectation that every plugin would operate seamlessly in this mode (or at all). That said, I do understand as a software developer that there would be a non-trivial amount of UX work and plugin benchmarking work to avoid having users creating bad experiences for themselves.