About CAT

DSP, Plug-in and Host development discussion.
camsr
KVRAF
7020 posts since 17 Feb, 2005

Post Mon Jul 13, 2020 7:45 pm

mystran wrote:
Mon Jul 13, 2020 6:01 pm
Music Engineer wrote:
Mon Jul 13, 2020 3:50 pm
camsr wrote:
Mon Jul 13, 2020 10:45 am
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.

User avatar
Guillaume Piolat
KVRist
211 posts since 21 Sep, 2015 from Grenoble

Post Tue Jul 14, 2020 1:08 am

beginzone wrote:
Mon Jul 13, 2020 8:39 am
The XSD thing doesn't look like fun, but surely must have some important purpose, hopefully.
Yes, it makes it very extensible.
beginzone wrote:
Mon Jul 13, 2020 8:39 am
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 :)
VST/AU/AAX: Couture | Panagement | Graillon

matt42
KVRian
1202 posts since 9 Jan, 2006

Post Tue Jul 14, 2020 1:20 am

Guillaume Piolat wrote:
Tue Jul 14, 2020 1:08 am
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.

User avatar
S0lo
KVRian
774 posts since 31 Dec, 2008

Post Tue Jul 14, 2020 2:40 am

Music Engineer wrote:
Mon Jul 13, 2020 3:50 pm
camsr wrote:
Mon Jul 13, 2020 10:45 am
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
KVRAF
7020 posts since 17 Feb, 2005

Post Wed Jul 15, 2020 3:58 pm

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
KVRian
1202 posts since 9 Jan, 2006

Post Wed Jul 15, 2020 4:59 pm

camsr wrote:
Wed Jul 15, 2020 3:58 pm
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
KVRAF
7020 posts since 17 Feb, 2005

Post Wed Jul 15, 2020 6:40 pm

matt42 wrote:
Wed Jul 15, 2020 4:59 pm
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.

User avatar
Music Engineer
KVRAF
3857 posts since 8 Mar, 2004 from Berlin, Germany

Post Wed Jul 15, 2020 7:08 pm

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.

https://www.youtube.com/watch?v=I0ObB68sZvQ

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.
Last edited by Music Engineer on Fri Jul 17, 2020 6:45 am, edited 1 time in total.
Image

matt42
KVRian
1202 posts since 9 Jan, 2006

Post Wed Jul 15, 2020 8:51 pm

camsr wrote:
Wed Jul 15, 2020 6:40 pm
matt42 wrote:
Wed Jul 15, 2020 4:59 pm
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
KVRAF
7020 posts since 17 Feb, 2005

Post Wed Jul 15, 2020 9:47 pm

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
KVRian
1202 posts since 9 Jan, 2006

Post Wed Jul 15, 2020 10:06 pm

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
KVRAF
7020 posts since 17 Feb, 2005

Post Wed Jul 15, 2020 10:16 pm

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
KVRian
1202 posts since 9 Jan, 2006

Post Wed Jul 15, 2020 10:29 pm

camsr wrote:
Wed Jul 15, 2020 10:16 pm
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?
camsr wrote:
Wed Jul 15, 2020 10:16 pm
where the host have some say also.
What kind of say is the host expected to have in a plugins parameters?

Benutzername
KVRist
402 posts since 23 Jan, 2008 from Hamburg, Germany

Post Thu Jul 16, 2020 5:17 am

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
KVRian
1202 posts since 9 Jan, 2006

Post Thu Jul 16, 2020 6:03 am

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).

Return to “DSP and Plug-in Development”