About CAT

[camsr]

I would like to see all the parameters of the plugin exposed to the host

that assumes that the set of parameters is fixed. what about an equalizer with an arbitrary number of bands that are created dynamically? or an envelope generator with an arbitrary number of breakpoints? or maybe it doesn't? ...hmmm...well...you could perhaps create an api that involves callbacks or opcodes like "parameterAdded", "parameterRemoved", etc. this would have to be a plugin-to-host request

Parameters alone won't solve the problem for custom editors though, since not everything you can do in a complex plugin editor is necessarily something that can be made into a parameter, but it would certainly be nice for the purpose of automation.

There's a few complications though, like specifying how to synchronize threads with regards to such changes and also whether to then just go with arbitrary IDs (but maybe the ID should still be used as a sorting key for UI?), given that the set of parameter indexes might not remain continuous anymore.

An ID can be established when the parameter is created (through a paramAdded() for instance). It has to be unique. They could not be indexed unless they are enumerated in a list.

This does add some odd complexity, specifically around save and load of plugin (and host) states.

[Guillaume Piolat]

The XSD thing doesn't look like fun, but surely must have some important purpose, hopefully.

Yes, it makes it very extensible.

Adoption battle is a problem for the acceptance of Linux, isn't it? I'm afraid you're right about LV2 and Opi (CAT). But I'm not sure what I really think about it, I use Windows most of the time.

Ardour for Windows/macOS can host LV2 built for that OS. LV2 can work outside Linux. They can receive a Cocoa or HWND window handle.

But, I see people want to design their own NEW thing, and so will find problems as needed with the OLD thing

[matt42]

But, I see people want to design their own NEW thing, and so will find problems as needed with the OLD thing

I'm not sure how many people really want to see another plugin standard vs how many people are interested debating what a somewhat ideal, or at least half sane, spec might look like.

[S0lo]

I would like to see all the parameters of the plugin exposed to the host

that assumes that the set of parameters is fixed. what about an equalizer with an arbitrary number of bands that are created dynamically? or an envelope generator with an arbitrary number of breakpoints? or maybe it doesn't? ...hmmm...well...you could perhaps create an api that involves callbacks or opcodes like "parameterAdded", "parameterRemoved", etc. this would have to be a plugin-to-host request

Good point, modular plugins can have a dynamic number of parameters too as more modules are added by the user.

[camsr]

If plugin presets were to utilize dynamic parameter assignment, this could be in conflict with preset browsing and just in general a mess. Dynamic parameter assignment also has the potential to leave loose links between automation assignments and plugin state.

I still think it's a good idea, although any user must be aware that the extra burden of managing parameters will be their responsibility.

[matt42]

If plugin presets were to utilize dynamic parameter assignment, this could be in conflict with preset browsing and just in general a mess. Dynamic parameter assignment also has the potential to leave loose links between automation assignments and plugin state.

I still think it's a good idea, although any user must be aware that the extra burden of managing parameters will be their responsibility.

It's really just some extra state information in the preset. The plugin loads the new state and then tells the host it's new parameter configuration, if changed. I'm not sure where the pitfalls such as loose links come into play?

Any system where the user is required to manage dynamic parameters, beyond when they decide to add or remove them, would be a poor design imho.

[camsr]

I'm not sure where the pitfalls such as loose links come into play?

Any system where the user is required to manage dynamic parameters, beyond when they decide to add or remove them, would be a poor design imho.

Assume there is nothing to prevent a plugin from creating a parameter at any time, or removing. If it were removed, and the host had prior assignments of say, automation data, or controller bits, to it, then those things would no longer be linked as the parameter does not exist anymore. But it could very well come back.

[Music Engineer]

what elan and i have done for soundemote plugins is to just report a fixed number (chosen at compile-time) of general purpose parameters to the host, treat them internally as "meta-parameters" and then map them ourselves to one (or more) of the plugin's internal parameters inside the plugin.



i actually always thought that parameter automation is kind of redundant with midi controller messages anyway and took the position that if you provide "midi-learn" for some parameter, you don't need to also have automatability for it - it could even be possibly conflicting: what if cutoff-automation: says: 1 kHz but CC#74 says: 2 kHz? that's why i kinda neglected the vst automation scheme in some plugins and exclusively provided the midi-learn feature instead. sure - midi controllers have lower resolution (that's why i also provided min/max-learn - to at least use the full 128 values for the interesting range) - but should automation not be better thought of as a higher-resolution replacement of that very same idea?

...i guess what i want to say with this is that i'm personally actually totally fine with the state of things in vst2 of having just a fixed and static number of "automation lanes". if more complexity is needed, a plugin could build its own system on top of that without needing to bloat the plugin interface specification for that. the possibility of dynamic renaming would be nice, though.

[matt42]

I'm not sure where the pitfalls such as loose links come into play?

Any system where the user is required to manage dynamic parameters, beyond when they decide to add or remove them, would be a poor design imho.

Assume there is nothing to prevent a plugin from creating a parameter at any time, or removing. If it were removed, and the host had prior assignments of say, automation data, or controller bits, to it, then those things would no longer be linked as the parameter does not exist anymore. But it could very well come back.

I would assume each parameter would have an id, so that the host could keep track of which automation lanes corresponded to which parameters.

If the user removes a parameter then I would imagine most people would expect any associated automation lane to be removed by the host

[camsr]

I am unsure how parameter IDs would be created. If the parameter was created, removed, and then created again for the same use, the original suggestion was to create a new unique ID. That won't work...

[matt42]

It won't work if you are expecting the host to remember previously associated automation lanes and recreate and reconnect them.

I'm just unsure of a case where I'd have a parameter important enough to automate, decide that actually I don't need that parameter to even exist and then expect the host to recall previously associated automation at the point I decide to bring the parameter back. There could be ways to do this, but I think you are correct that it would cause problems. I add a new parameter, for example, and then the plugin and host both need to know if I'm just adding a new parameter, or am I replicating the other parameter that I just deleted. That could be kind of annoying with all kinds of possible edge cases

[camsr]

Yes it would. I think the details need to be worked on before any substancial decision can be made. Regardless, I still like the idea of plugins being "strongly encouraged" to provide parameters as requests to the host, where the host have some say also.

[matt42]

Regardless, I still like the idea of plugins being "strongly encouraged" to provide parameters as requests to the host

"strongly encouraged"? Whether parameters are static or dynamic it should be a requirement that the plugin provides automable parameters to the host, no?

where the host have some say also.

What kind of say is the host expected to have in a plugins parameters?

[Benutzername]

Hmm, if I look at this conversation then the parameter handling alone will get more complex then the entire VST1 API.

IMHO the main problem with VST3 and other alternatives (especially LV2) is that they want to solve all problems in existence and handle every possible scenario for now and for the future. That makes them extremely complex to use and hard to grasp. Things starting to get ambiguous and redundant sooner than later and if you don't establish a very very strict set of rules then everything falls apart eventually.

I think what people really want is VST2 without Steinberg. So please keep it simple or no one will ever use the new format. If it handles 95% of the use cases perfectly fine and another 4% with small workarounds then that should be good enough. Over engineering may get you to 100% eventually but it will scare away potential users a lot and we end up where we started.

[matt42]

I agree simple good. My vote would be for dynamic parameters (nice and flexible) without any wild schemes to keep track of deleted automation lanes (too compelx).