Hi Justin and Team,
Strictly speaking this is not a Reaper feature request, but a proposal for an upheaval of the plugin architecture, to enable a lot more than is possible today, to lead, rather than follow.
https://www.gearslutz.com/board/13005052-post17.html
At the thread/post in the link above, while giving feedback to a wonderful plugin manufacturer. it occurred to me that, with all due respect to the amazing advances in audio technologies, and those such as you and your team who have been at the forefront of these advancements, we might have exhausted the architectural limits of the current plugin architecture and going any further may need a fairly drastic re-think.
At the end of the post - which aims to rearchitect audio processing to make it easier for suppliers and consumers to focus on areas of strengths, rather than the current model where everyone(especially on the supplier side) is trying to do everything, code, user interface, user experience, user support, distribute, integrate, and obviously not excelling at everything - I propose a new model, of audio service providers and consumers, with a lot more flexible potential for integration between them.
There is not really anything that out of the ordinary about this concept, it just needs those with the ability to bring it to pass - technically, and some others to provide conceptual contributions and whatever else is needed.
I give an example - of this need, many plugins come with their own display for level, frequency, stereo spread, etc, and while I love the features of one plugin, I might prefer how audio is displayed in another plugin, which needs me to run both of them, consuming resources, my divided attention - as well as setup these plugins in the right sequence, - screen estate, CPU. at the least some of this is redundant, should I need the best of both worlds. How wonderful it would be to be able to have audio components that could provide services to one another, letting each focus on what they do best.
I give another example - your Reaper product has one excellent distinction, in-built wet/dry mixing - per plugin. Yet lots of plugins duplicate these same functions, or similarly the bypass feature, which the host also includes and as I have discovered, the bypass function is improperly implemented in some plugins. With a new standard, these common features need not be implemented in each plugin, as they are available as common services.
I know that you already have your hands full, with the Reaper product and ecosystem, but I consider from your antecedents that as a person of vision and execution, as I also am, we could take what you have already achieved and rather than follow - establish a whole new better world of audio processing by extending the current plugin paradigm, with a more extensible one with possibilities even we cannot yet imagine.
Especially as you have been the most successful at creating an extensible ecosystem to your DAW, and via the Jesusonic scripting language also provided a "plugin" for audio code, I am certain, this new world is well within your grasp and potential.
I do hope you will find the time to read all of the above and the summary in the link referred to, and it would be wonderful to hear back from you, and better still work with you to define, refine and bring some of this to pass, ultimately handing it on to others to continue evolving the opportunity.
In conclusion, it's really about - how do we recreate the - "plug - in", allowing a more flexible association between plugins and hosts - with plugins also being able to be elevated consumers kinda like hosts.
Benefits - from an end user perspective, as an example, I would not have to learn every plugins varying method of displaying frequency, but can choose my preferred supplier of frequency display, and much more - should someone else come up with some other display I prefer, change this and apply it to all plugins.
We could have console emulation as a service, applied to only specific tracks, or plugins.
Oversampling can be a service that one plugin provides to another, not something that needs to be hard coded, or included per plugin.
There's more - sample rate conversion as a plugin service, so users or plugin makers can choose, and stay in step with any inventions/developments/options in sample rate conversion, without having to touch a single line of their own code, if the option to delegate this exists.
Of course, the new world will integrate with what we have today, but take us much further than the constraints of what is fundamentally a wonderful but fairly consistent VST model, and hopefully take these concepts beyond the control/constraints of one well worn ecosystem.
If we build the new world, they will come.
We could do the same for video.
Enough said, I am sure you get the drift. I await your further contact.
Regards
Olakunle Odebode
(google will have enough information about me, which you can look up)