in getNumPrograms() doc : "This value shouldn't be less than 1."
not sure about the strongness of "should" here. is that fine to return 0, as in the plugin example?
As I've got all the presets management file based, and control from within the plugin, I would have returned 0, is that ok?
As well, is it ok if I don't do anything in the following ones ?
So that nobody tries to modify the presets from the host ?
Or would you recommend to implement something even if the presets management is embedded within the plug?
Unless you're going to test it in every host, it's probably safer to just return 1, and act like there's always one program. Most hosts will probably cope with 0, but I couldn't guarantee that.
I just upgraded to the latest tip and now get the jassert (af->getNumPrograms() > 0); message when using the XCode debugger. I have my own preset management file system as well, should it just be fine to override getNumPrograms() even if I don't in fact use or override any of the program methods in AudioProcessor?
Personally, I won't use VSTs that don't report their program lists to the host.
Even if you have all your program management onboard, you should give the host the option to select programs by name. If you don't report to the host, you force the user to select programs from your plugin GUI.
My host is a single window operated via touchscreen. I depend on being able to select programs for any of my host's VSTs in order to layer and effect sounds on the fly. I cannot juggle 16 floating plugin windows while playing.
Of course I realize that I still must open the plugin GUI to save new programs, but that is an entirely different level of engagement. For one thing you need a querty keyboard! That keyboard stays in the case when I'm playing the other one.
Report to the host! It's not that hard, is it?
I don't think it's that easy in all situations.
In the case of plug-ins which have hundreds of programs and implement some kind of complex filtering (with categories, tags, etc.) it's really much easier to use internal plugin's browser.
If plugin relies for example on presets stored in some tree-based structure it can be even impossible to serve them in reasonable way to host which mostly depends on their unique names and plain structure.
Well, I think allowing 2 presets with the same name is bad practice, no matter how you organize them.
Instruments like Massive allow you to construct simple banks, even though all the other preset search algorithms are there. I’m sure I’m not the only person who sometimes needs to get to a preset via a simple MIDI program change command. If you can support that, you can support a list of names.
Synth 1 will expose 1200 preset names to the host, so size is not a limitation.
A simple alphabetical list would be fine for my purposes.
Size is not a limitation, I agree. But plain list of thousands of presets isn’t something I’d like to get through to find something.
If plugin manages large number of presets on its own, user can use dedicated browser with all the features that host can not serve like filtering, tagging, marking favorites, rating, locking ranges of parameters and many more features that are well fitted to plugin and its unique characteristic.
How for example host would nicely deal with preset management when plugin uses not only ‘master’ presets but some number of micro-presets used for some functional modules of a plugin.
In our products we decided to ‘hide’ all presets a long time ago and because of our experience that users don’t complain that host doesn’t know anything about plugin’s presets we never found any reason to even try to come back to previous approach.
The reason was that in our old days many hosts presented really strange bugs even if you tried for example to increase number of presets with plugin updates. Maybe all these bugs have been addressed already, I don’t know - because of the reasons I mentioned above I never had a thought to come back.
Unfortunately, a bunch of unique plugins with unique characteristics mean a bunch of open windows…
And the plug in menus are typically too small to operate from a touch screen.
I like how Massive allows you to set up banks, without compromising all their nice sound-browser search stuff… which is very nice in the studio, but much too fiddly to use live. In the studio I’m thinking ‘what sort of sound might I like?’. Live, I just need to know where soundX is, and press that button.
But I see where you are coming from: 99% of the VST market is for recording work… and keyboardists will continue to shell out thousands for Nord, Roland and Yamaha until VST developers start to think differently.
I agree that using plug-in live you want just to switch from preset A to B without using any GUI. But in my opinion in such situations the better approach is to allow presets to be mapped to MIDI Program Change messages.
Then you are free to define any mapping you need and MIDI seems to be better alternative to VST program changes. Probably every good host can deal with MIDI program changes and most of all, every MIDI controller which can be used in any host. I see that as more flexible solution.
Well, if you are going to create a setup for mapping midi program changes, why not expose the exact same list to the host while you are at it, instead of deliberately not implementing part of the VST spec??
It doesn’t need to be one or the other–you can provide both…
It’s of course only my perspective and I don’t know how other developers see that problem but I told you earlier.
No single user ever asked us about this, but a lot of them asked about midi program mapping.
I found a lot of problems in the past with the hosts when number of programs changed or when programs were reordered or renamed. That’s why we dropped it - and some developers as I remember also went to internal presets management.
I really don’t know how today this could work on various hosts. Maybe others could shed some light on it ?
Midi Program changing is independent on host you use and format (VST/AU/AAX) which makes it better common denominator simply.
The hosts I use that support it are Max/Msp and Usine Hollyhock. I’m pretty sure energyXT does, and I’d imagine that MainStage does.
Neither of the hosts I use has problems with the plugins I use (which are all Native Instruments) so I’m not sure if that’s clever programming on the part of the hosts or the plugins or both.
I don’t believe any of the NI plugins allows the number of programs to change. They are all hardwired to 128. I wish they supported a larger number (the old PRO53 vst supported 512, which seems like a perfect number) but I get around it when needed by loading the plugin data from fxb with a different set of programs…
No fun to do that for every single preset, but it is an option. Maybe in Juce, I could automate that process. A folder full of FXPs would work just as well or better. I have to do that for Kontakt anyway.
Now you got me thinking