I suspect this isn’t going to work, but I’m wondering why.
At least, for VST3 on Windows, the name the host shows for a plugin seems to be the macro for JucePlugin_Name. I know hosts are different, but just to get started: if the macro text is in double quotes, such as “MyPlugin”, is it not possible to replace that with a const char *? Either as a global variable, a member of an object, or even a function’s output?
If not, I have another question. I am writing a plugin that wraps another plugin, determined at run-time. The problem is that the user may want to run any number of instances of this wrapper plugin, all wrapping different plugins, and if they all show up with the generic name in the host, the user can’t tell which is which.
My other solution - which I hate having to use, but it should work - would be to compile it, say, 16 times, as “MyPlugin01”, “MyPlugin02”, etc.
If I’m forced to do it this way, could anyone share a build secret, a script technique, to automatically compile it those 16 times with 16 different macros, or 16 versions of “JucePluginDefines.h”, rather than compiling it and manually changing the name 16 times?
That wouldn’t work anyway, because hosts differentiate plugins based on the “plugin code”, not just the plugin name. You mention the wrapped plugin being determined at runtime - obviously all the plugin’s identifying info must be set at build-time, so this is likely not possible.
AudioProcessor does have a getName() function, so you can experiment with that, but I suspect returning anything other than the product name will lead to confusion and may have unintended consequences.
Even if implementing this were possible, personally, as a DAW user, I would find it confusing if different instances of the same plugin show up with different names.
OK. It keeps seeming to be close, but I suppose I will leave it. Too bad.
The user will copy-paste my plugin file into the same folder as their desired plugin. Then, if the wrapped plugin is called “WrappedPlugin.vst3”, they change the name of the wrapper from “Xwrapper04.vst3” to “XWrappedPlugin.vst3.04.vst3”. This way, at some point, they should also be able to wrap AU as VST3, using “XWrappedPlugin.au.04.vst3”. For example. Maybe it’ll look different, we’ll see.
It’s not conventional, I know. It will confuse some people, I know. But there are thousands of good plugins out there that are not microtonal-capable, and this can force them to be. It’s not for everyone.
I think having 5 plugins that all have the same name but are wrapping 5 different plugins would be more confusing than having 5 copies of the same plugin with different names (Xwrapper01.vst3, Xwrapper02.vst3…) and which wrap 5 different plugins.
What trips me is that changing the filename, in most cases, won’t affect the name of the plugin in the host, but if that’s the procedure, I’m trapped.
*I do not want to make a complete GUI and have them load plugins dynamically while running. It is far simpler, and more lightweight, to have my wrapper just load the plugin whose filename is hidden in its own.
With CMake these things are much simpler. When I was using the Projucer I had to write Python scripts to modify the Projucer files prior to building. It was a bit of a mess, but got the job done.
I’ve no idea how they achieved this, but Novation used to have a special wrapper for one of their controllers. It was the one with the display above every control, the wrapper would then query the parameter names and communicate with the controller to show those names above the controls. In the host DAW (my experience was in Cubase) there would be a “Novation wrapped” sub-menu in the plugin choice menu (probably not that name, but you get the idea) with every plugin it had wrapped contained therein. iirc you had to run a special program to scan your plugin folder to generate these wrapped plugins, which would need to be run every time you had a new plugin. Not sure how any of this helps, just proves that what you’re trying to do is at least possible I guess
