About CAT

[Music Engineer]

i agree. trying to handle dynamic parameters right seems to create a complexity that gets quickly out of hand. as said, i'd be totally satisfied with a static list of automatable parameters ("automation lanes"), as long as i can dynamically rename them (i.e. have some plugin-to-host "setParameterName" opcode with an index and a new name) and even that is not a must, but nice to have. i wouldn't mind a *simple* addParameter/removeParameter protocol, though. but if that's too complex, let's just leave it out for v1.0 - the nice thing about the dispatcher/opcode scheme is that it can easily be extended later...

I think what people really want is VST2 without Steinberg

sort of. and with some of its quirks straightened out (processEvents? wtf? the only thing that this function ever does is to pointlessly gather and rebuffer the events for the subsequent process call. or am i missing something?)

[Vokbuz]

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.

The only problem with them is the fact that they are not VST2.

[karrikuh]

I can probably live without being able to dynamically add/remove parameters at run-time. However, I absolutely want to be able to change the set of parameters as I introduce new features in plug-in updates. For this, each host parameter needs to be assigned a unique ID by the plugin which the host refers to e.g. in automation data.

One of the biggest flaws of VST2 IMO (not sure if this also applies to VST3) is that host parameters are referenced by position, meaning that the list of parameters presented to the host (including order) is set in stone in the very first release in order to preserve backwards compatibility later on.

[camsr]

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

An automation lane may be linked to more than one parameter. Parameter removal would not delete the automation data, unless the plugin user specifies that function.

[camsr]

A dynamic parameter system can easily replicate the old method of static parameters as well. Plugins would only create parameters on instantiation and remove similiarly. It could function the same as we all know it to currently.

[mystran]

One of the biggest flaws of VST2 IMO (not sure if this also applies to VST3) is that host parameters are referenced by position, meaning that the list of parameters presented to the host (including order) is set in stone in the very first release in order to preserve backwards compatibility later on.

Good point. The desire to separate ID from the ordering would suggest a design where rather than dynamically adding and removing parameters, you would have a list of arbitrary parameter IDs (eg. uint32_t) in the order of logical UI presentation, that you would then tell the host to refresh when you change it. Everything else would use the parameter IDs.

This would provide a unified approach to adding, removing and reordering parameters, while also allowing automation data to remain linked to the correct parameters as long as the plugin maintains consistent ID values. As far as parameter set refresh and threading go in terms of automation events, this could possibly be (at least mostly) solved simply by stating that a plugin must ignore events that refer to invalid (eg. stale) parameter IDs.

ps. VST2 behaviour can also be replicated with a simple list that looks like [0,1,2,3,4...]

[camsr]

So we have an idea for giving the plugin data from the host for parameters. There will be circumstances where the plugin will give the host data about parameter values. I'm seeing parameters as a two-way street, as their usage is so dynamic.

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

An automation lane may be linked to more than one parameter. Parameter removal would not delete the automation data, unless the plugin user specifies that function.

Just to clarify, I'm suggesting removing the automation lane only once its dangling. Not having to manually garbage collect a load of redundant automation lanes is just my preference, but ultimately any host maker would have to make a decision on how to handle clean up.

So we have an idea for giving the plugin data from the host for parameters. There will be circumstances where the plugin will give the host data about parameter values. I'm seeing parameters as a two-way street, as their usage is so dynamic.

I'm still not clear what information you expect the host to give the plugin regarding its parameters?

[matt42]

I liked that vst2 plugins could output events even though Steinberg says this is really an abuse of the specification. Outputting events adds a tone of flexibility at little cost to complexity. Should this be allowed in the spec?

[Vokbuz]

I liked that vst2 plugins could output events even though Steinberg says this is really an abuse of the specification. Outputting events adds a tone of flexibility at little cost to complexity. Should this be allowed in the spec?

How can this be an abuse of the specification if there is a dedicated master callback opcode to output events and opcode to get output midi channel count?

[matt42]

I liked that vst2 plugins could output events even though Steinberg says this is really an abuse of the specification. Outputting events adds a tone of flexibility at little cost to complexity. Should this be allowed in the spec?

How can this be an abuse of the specification if there is a dedicated master callback opcode to output events and opcode to get output midi channel count?

No idea, ask Steinberg

I think someone was, perhaps, defending VST3 not allowing MIDI out having to resort to "well you were never supposed to do that in VST2 anyway".

[camsr]

Imagine generating midi based on audio input in a plugin. There is a non-concurrent dependency if that midi is used to generate audio that goes into the plugin that is generating that midi. It's a can of worms, but not an impossible situation.

[camsr]

I'm focusing on how to generate unique parameter IDs at the moment. If it can't be done in an effective manner, the dynamic parameter creation idea may be cut, at least IMO. The host could use something like requestParameters() in that case.

[Music Engineer]

I liked that vst2 plugins could output events even though Steinberg says this is really an abuse of the specification. Outputting events adds a tone of flexibility at little cost to complexity. Should this be allowed in the spec?

absolutely, yes, please! the events buffer that is passed to the processing call anyway should be used for input *and* output events. and, if i'm not mistaken, that's precisely what mystran's draft proposes (i see comments about emitting events, etc). that way, we could unify audio-plugins with midi-plugins without needing a separate api for the latter. one would have to invent some scheme for how additional memory should be allocated (and de-allocated), in cases, where a plugin wants to emit more events than it receives - but if i'm not mistaken, that was already taken care of (i have to read it again...). one would perhaps have to specify that plugins that consume events in the sense that the next plugin in the chain should not receive the same events also, should clear the buffer after finished - otherwise the next plugin in the processing chain would receive the same events (which may or may not be desirable - depending on the situation - typically, it's probably not - i'm apparently assuming a situation like being on a track/mixer-channel in a daw, where the user plugs in a series connection of plugins - of course, that's not the only possible scenario, but, imho, the most typical)

[matt42]

I'm focusing on how to generate unique parameter IDs at the moment. If it can't be done in an effective manner, the dynamic parameter creation idea may be cut, at least IMO. The host could use something like requestParameters() in that case.

IDs only have to unique per plugin instance. Just start at 0 and for each new parameter add 1, for example.