About CAT

[Music Engineer]

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

...which could become especially tricky, if one wants to avoid dynamic memory allocation within the process call - something one definitely should want. ...maybe that's the reason for the separate "processEvents" call in vst2? hmmm...but if you are not supposed to emit events according to steinberg, than probably not? or maybe it was the initial idea but than they realized that they always call processEvents on the same thread right before process anyway and deprecated the idea? hmmm...i'm just speculating

[mystran]

if i'm not mistaken, that's precisely what mystran's draft proposes (i see comments about emitting events, etc).

In my draft there's two pointers in process info: inEvents and outEvents.

When calling a plugin, the inEvents should be a pointer to an array of pointers to the event and outEvents should be a null-pointer.

What I'd propose for output is that if a plugin wants to send events, it should (pre-)allocate space for the events and space for the array of pointers internally and build the whole event list internally (just like the host is doing) and then just store the pointer and number of events back into the processInfo.

[Music Engineer]

What I'd propose for output is that if a plugin wants to send events, it should (pre-)allocate space for the events and space for the array of pointers internally and build the whole event list internally (just like the host is doing) and then just store the pointer and number of events back into the processInfo.

aha! sounds good! edit: yeah - actually, much better than what i said. if the plugin wants to pass the events through, it would have to explicitly copy the content of the inEvents to the outEvents buffer. that seems to make a lot more sense than what i was babbling about "implicit pass-through unless clearing"

quoting myself again:

otherwise the next plugin in the processing chain would receive the same events

..actually, that was a rather naive view. the host could want to send its own events to the next plugin as well, and if it wants, it would first have to merge (and re-sort) the event-list emitted by the plugin with its own

[Vokbuz]

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

I never heard this before, so I doubt it is really the case. Do you have links to this statement by Steinberg?

[matt42]

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

I never heard this before, so I doubt it is really the case. Do you have links to this statement by Steinberg?

From the Steinberg forum: https://sdk.steinberg.net/viewtopic.php ... t=10#p2378

Hi,
your frustration comes from the misunderstanding that you can build MIDI plug-ins with VST. VST describes an audio plugin API. That you could misuse version 2 for building MIDI plug-ins was not intended. You need a MIDI plug-in API which does not exist across hosts. And for key switching support in VST3 see : https://steinbergmedia.github.io/vst3_d ... witch.html

Cheers,
Arne

Possibly just Arne's unofficial opinion of course

[camsr]

maxEventBlockSize may be useful also

[matt42]

Edit

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

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

The plugin instance could very well be the root of identification for the dynamic scheme. Assume the spec does not allow plugins to create parameters for other plugins (this was never a consideration, it's important to be thorough).

I think S0Lo has the best use case example, a modular plugin. The plugin is instantiated on some preset, and the user links a few controls. Now, if the preset is changed, those prior links may or may not be relevant. We need common ground to say whether this is the expected behavior or not.

I much like the suggestion of meta-parameters. A (possibly) static list of control links is provided by the plugin, then the plugin does the remapping for what they do. The plugin may remap controls over preset changes, internally. There is still the same issue of controls becoming unlinked at some point, but now the burden of linking is exclusive to the plugin.

In this scheme, the host is absolved of loose links, and any method to coordinate this behavior lies solely on the plugin. Every plugin doing the same thing is a "duplication of concerns" IMO, and I propose to allow the spec to interface host and plugin to achieve centralized coordination on issues such as this.

[Music Engineer]

A (possibly) static list of control links is provided by the plugin, then the plugin does the remapping for what they do. [...] any method to coordinate this behavior lies solely on the plugin. Every plugin doing the same thing is a "duplication of concerns" IMO, and I propose to allow the spec to interface host and plugin to achieve centralized coordination on issues such as this

i can't see, how a host could possibly be able to coordinate such remappings in a centralized way without the api for that being horribly complicated. we do one-to-many mappings, the target-range must be specified for each target parameter individually, we can even have mapping curves (defined by breakpoints), etc. i don't even want to think about, how to communicate such things to the host - let alone having it be controlled by it. the plugin has no other choice than doing such stuff itself. well..maybe in simpler cases, it's a different story. ...but then the api would perhaps be only moderately complex but not useful enough to be actually used - dunno

[camsr]

we do one-to-many mappings, the target-range must be specified for each target parameter individually, we can even have mapping curves (defined by breakpoints), etc.

AFAICT the host to plugin interface is still only passing a normalized parameter value. Things like you mention are unique to the plugin instance at the lowest level, what the plugin does from there is it's own concern, and may not be communicated to the host. I am suggesting a way to link modulation data external to the plugin in an organized manner.

For example, start a filter automation channel, change to a preset with no filters... change to another preset with a filter and it comes back! Your idea can be used to accomplish this, but the number of entries for modulation data into the plugin is static. Maybe this is the easiest way, but like I noted earlier the dynamic parameter creation can replicate the behavior of the static way.

I think the dynamic way will allow more possibilities for control linking. The cost is increased processing overhead to manage more complex structures. And that is only when links or parameters change.

[mystran]

i can't see, how a host could possibly be able to coordinate such remappings in a centralized way without the api for that being horribly complicated. we do one-to-many mappings, the target-range must be specified for each target parameter individually, we can even have mapping curves (defined by breakpoints), etc. i don't even want to think about, how to communicate such things to the host - let alone having it be controlled by it. the plugin has no other choice than doing such stuff itself. well..maybe in simpler cases, it's a different story. ...but then the api would perhaps be only moderately complex but not useful enough to be actually used - dunno

I agree. What you want to do is let the plugin (that actually knows what is needed) figure out what to do, then provide the host for hooks for presenting the information it wants to present.

The host needs to know what parameters there are (ie. and ID for each), it needs to know the names (string) of those parameters and it wants to know how values map to strings and back, so it can show something more intelligent than normalized values to the user. There might be something else (eg. maybe integer/enum parameters should be a separate concept), but that's really most of it. It might also be useful to have a way for the plugin to say something like "please create automation track for this parameter" or "please open your controller-assignment dialog for this parameter" so you could put such options in your custom right-click menu, but as far as the semantics of a parameter, the host just shouldn't care.

The only thing I'm worried about here is that people overthink it and try to come up with some intelligent parameter ID encodings even for simple plugins where really the parameters should still be a simple list of incrementing small integers. If the simple approach works, just use it. If it doesn't then it's probably up to the specifics of what you actually need in a given design to figure out how to do it.

The whole idea that a generic host can somehow understand the semantics of what the parameters actually represent in a complex plugin is completely nuts, because by the time you write the spec, you really don't know all the possibilities yet. At best you can make a huge list of everything that has been done previously and then it takes a week and someone comes up with something new they want to do and then you're back to the starting point. What you want to do instead is to leave things open ended and separate the concerns of the host and plugin, such that people can later come up with new ways to use your API, without having to change the API itself.

Also what the host should do when a parameter is removed is really up to the host. It could destroy the automation track, it could unlink it. In some hosts such an automation track might be a property of a parameter while in other hosts it's just an automation track that can be linked to any parameter (of any plugin, or the host itself) that currently exists and you can change it in the properties of the track itself.

In my opinion, the main design goal of an API is to figure out "are there important use-cases that cannot be implemented on top of this API" and "can we simplify the API without reducing the functionality" rather than to try and put every high-level concept into the low-level API directly. Otherwise your API eventually reaches Turing-completeness.

[camsr]

The whole idea that a generic host can somehow understand the semantics of what the parameters actually represent in a complex plugin is completely nuts.

Yes it is, and thank you for bringing attention to this! Yet we make all kinds of generalizations in practice, based on this uncertainty. I just hope that the spec can make considerations for this uncertainty, maybe a few years from now it looks like a good idea. Remind me why we are fledging a new spec in the first place? The old, well defined spec can not change.

[syntonica]

There's no reason the plugin can't stuff a struct with all sorts of goodies--name, rank, serial number, number of parameters, parameters about those parameters, which may be automated, their names, current values, etc. and pass that pointer on construction. The plugin can either use a separate entry for each possible parameter, or replace entries as needed, depending upon the programmer's whim. The host will always have the current values at its fingertips, no reason to do 5000 queries... I realize that this is probably evil in the whole threaded nature of things, but the host access will be read-only and will send automation events or any other changes along in the usual manner and properly let the plugin deal with it.

I'd also like to put an end to the zero-centric view of parameters as well. Values should have a low value, high value, step size/continuous, as well as precision. I have knobs that go from 0.5 to 32.0. Some from -12.0 to 12.0. Some are linear, some exponential, some split duty. Steinberg seems to think everything starts at 0.

[mystran]

I'd also like to put an end to the zero-centric view of parameters as well. Values should have a low value, high value, step size/continuous, as well as precision. I have knobs that go from 0.5 to 32.0. Some from -12.0 to 12.0. Some are linear, some exponential, some split duty. Steinberg seems to think everything starts at 0.

Wrong. The normalized parameter is not the "value" of the knob, but it's a fraction of it's range in terms of the "perceptibly useful" parameterization. This is precisely what you want, so that you don't need to worry about all the complications with the actual value ranges or mapping curves on the API level. Stepped (or enumerated) parameters are another thing, I agree those are useful, but for continuous parameters anything other than normalized is just silly.

What you do need is a way to convert those normalized fractions of parameter range into human-readable strings and preferably back. This way the actual user doesn't need to worry about the normalized values, not on the host side and not on the plugin side. Users don't see what binary values are used by the API, they see formatted strings and if you simply let the plugin deal with the string formatting, you're set.

If you actually want the host to understand the actual parameter mapping, then what you really need is a full mathematical expression evaluator built into the API (so that you can actually describe your custom curves) and nobody wants to do that when the same thing can be done with a simple callback to convert to strings and back. Personally I just don't see any use-case where anything else would be useful at all.

If you go the mathematical expression evaluator approach, then it would also need the ability for one parameter to refer to the value of another parameter, because in some cases what is simple [0,1] in a normalized scheme can end-up being a complex inter-depencency in terms of the actual values.

[syntonica]

Wrong. The normalized parameter is not the "value" of the knob, but it's a fraction of it's range in terms of the "perceptibly useful" parameterization. This is precisely what you want, so that you don't need to worry about all the complications with the actual value ranges or mapping curves on the API level. Stepped (or enumerated) parameters are another thing, I agree those are useful, but for continuous parameters anything other than normalized is just silly.

I just meant their useless convenience methods. Of course, the actual values should be stored as 0 to 1, whether float or double. I'm just saying that when it comes to displayed values, how I describe it covers the vast majority of possibilities.