Well this is a kick in the nuts: VST2 plug-ins

[mystran]

Is there a way in LV2 for a plugin to format a parameter for host to display?

[OBSOLETE160530]

[DELETED]

[x42]

Is there a way in LV2 for a plugin to format a parameter for host to display?

yes, http://lv2plug.in/ns/extensions/units#render

[mystran]

Is there a way in LV2 for a plugin to format a parameter for host to display?

yes, http://lv2plug.in/ns/extensions/units#render

No. Just no. If you want something more than [0,1] then you will call a function that I will provide.

I don't really care if the host can display my parameters in a sensible way (that's what plugin editors are for), but .. I was just wondering if there's a method for it.

[x42]

Is there a way in LV2 for a plugin to format a parameter for host to display?

yes, http://lv2plug.in/ns/extensions/units#render

No. Just no. If you want something more than [0,1] then you will call a function that I will provide.

Keep in mind that as opposed to VST, LV2 parameters are not normalized to 0,1.
As for mapping numerics to text, there are scalepoints.

[mystran]

Is there a way in LV2 for a plugin to format a parameter for host to display?

yes, http://lv2plug.in/ns/extensions/units#render

No. Just no. If you want something more than [0,1] then you will call a function that I will provide.

Keep in mind that as opposed to VST, LV2 parameters are not normalized to 0,1.
As for mapping numerics to text, there are scalepoints.

The issue here is that I don't want anything other than simple normalized ranges at API boundary and in some cases I don't even know the mapping except dynamically at runtime. Even where I know it statically, there's probably a non-trivial taper. When I spend a lot of time optimizing my tapers to be as perceptually meaningful as possible, I don't want to give the host any information that it could possibly use to screw up the mapping. As far as the host is concerned, my parameters are "fraction of parameter range" which can be pretty-printed on demand (and for the record, this is how my own GUI treats them as well).

edit: Being able to statically tell how many parameters there are is already a problem. The fact that you can't dynamically change it at runtime is one of the more annoying aspects of VST2. Being able to give them useful names in advance is a bigger problem. Being able to tell how to print them is completely out of the question.

[Music Engineer]

i agree with mystran here. the normalized parameter ranges was something that vst2 did right. it's not reasonable to expect from a plugin api to understand the mapping curve of a particular parameter. sure, many parameters just use a simple linear or exponential mapping - but some others just don't fit into these boxes. but i would guess that it should be easy to bypass that feature of lv2 and just report normalized parameters to the host - right?

as for changing the number of parameters at runtime: i guess, that's where the (as far as i'm concerned - infamous - ) DynamicManifestGenerator enters the stage? but at least, it's possible at all. that's progress. i think, on balance, lv2 is actually quite good - maybe not perfect but better than vst2. i really like that parameter changes are communicated on the audio thread (as events in the "run" function), for example. this is a thing that lv2 does right (and vst2 did wrong...IMHO)

[mr.ardour]

i agree with mystran here. the normalized parameter ranges was something that vst2 did right.

Just for comparison, here's what we came up 15-17 years (I forget the year) during the GMPI process:

• All parameters must have associated metadata (e.g. name, minimum value, maximum value). Metadata will vary depending on the parameter datatype. All parameters must provide a default value. Plugins should handle invalid parameters safely.
• All parameters must be able to use natural values.
• GMPI plugins must be able to provide a parameter-specific method for producing a string representation of a parameter.
• GMPI plugins must be able to provide a parameter-specific method for producing a parameter value from a string.
• GMPI plugins must be able to provide a parameter-specific method for incrementing/decrementing a parameter value from a given value. The increment/decrement operation must return the new value, but not change the current value.
• Parameters must be marked as either hidden or visible. Hidden parameters should not be represented in UIs. This parameter property may change over the lifetime of a plugin.
• Every parameter must be either stateful or non-stateful. This parameter property may not change over the lifetime of a plugin.

[Music Engineer]

[*] All parameters must have associated metadata (e.g. name, minimum value, maximum value). Metadata will vary depending on the parameter datatype. All parameters must provide a default value. Plugins should handle invalid parameters safely.

sounds agreeable to me

[*] All parameters must be able to use natural values.

this could be problematic. how is the host supposed to know, what is "natural" in the general case?

[*] GMPI plugins must be able to provide a parameter-specific method for producing a string representation of a parameter.

agreed. makes perfect sense to me

[*] GMPI plugins must be able to provide a parameter-specific method for producing a parameter value from a string.

is that supposed to be just the inverse operation of the above? what if the host passes a string that doesn't fit the scheme generated by the method above? and also, this sounds to me to place a big burden on plugin implementors to implement various parameter-specific parsers.

[*] GMPI plugins must be able to provide a parameter-specific method for incrementing/decrementing a parameter value from a given value. The increment/decrement operation must return the new value, but not change the current value.

sounds like a lot of boilerplate to write on the plugin side

[*] Parameters must be marked as either hidden or visible. Hidden parameters should not be represented in UIs. This parameter property may change over the lifetime of a plugin.

okay. no big deal.

[*] Every parameter must be either stateful or non-stateful. This parameter property may not change over the lifetime of a plugin.

i don't really understand what that means. isn't the "state" of a parameter just its (current) value? and of course, every parameter has to have a value

...more importantly: was there a way to tell the host that the number of parameters has changed?

[S0lo]

What I'm saying is, any added complexity invites an exponential amount of bugs. Added complexity also makes documentation harder to find, and it requires to read the documentation with a bigger picture of the whole API.

Fully agree

The thing with UI/DSP separation is that it's cool/useful but it's not a common use case. I'd say clearly 95% of plugins don't need it. I have nothing against it, but I have some thing against it being the default and recommended method.

Usually an API should try to help the developer answer the most common cases. MIDI, audio IO, parameters, automation, presets, GUI handling, etc. Those features should be at the front. For the 5% minority who want something special, as say running DSP on separate hardware, they can dive deeper in the API or use OS or external API.

[Music Engineer]

why not? what would be the alternative? trying to convince steinberg to set vst2 free?

I think I missed the "what's actually wrong with VST3" part of this thread ... why isn't that the alternative?

this omission was fully intentional and i wanted people to read between the lines ...i meant it to be understood as: i don't even consider that as an option (i'm hearing the fabulous Dee Snider in my ears, singing "we're not gonna take it....anymore!" ). the whole situation is dissatisfying, to say it politely. well, in reality, i actually do consider the option and maybe i'll (teethgrindingly) do vst3 myself at some point. but there are technical and licensing issues with it. Markus Krause wrote a couple of posts about the former in the early pages of this thread. i guess (and hope), as a juce user, i don't really need to worry too much about them. that said, i want to give a big thumbs-up to steinberg for bringing vst to the world in the first place. but the whole situation how it is dealt with is really not very nice. please, steinberg - if you are reading this, re-evaluate your position. we all just want to make great plugins without hassle

[mystran]

[*] All parameters must be able to use natural values.

I have no problem with this, just my interpretation of a "natural value" is "fraction of the parameter range."

[*] GMPI plugins must be able to provide a parameter-specific method for producing a string representation of a parameter.
[*] GMPI plugins must be able to provide a parameter-specific method for producing a parameter value from a string.

AU supports for both of these (in addition to allowing you to give more meaningful metadata for automatic conversions if you'd rather let the host handle it for you; to be perfectly honest I think it makes sense to support both models, because simplicity is great for simple plugins while flexibility is great for more complex ones), so I'd imagine most plugins that care to do their own string conversions already have the necessary functionality and it's just a matter of having an API to expose the functionality.

[*] GMPI plugins must be able to provide a parameter-specific method for incrementing/decrementing a parameter value from a given value. The increment/decrement operation must return the new value, but not change the current value.

As far as I can see Incrementing and decrementing are ill-defined for a continuous parameter?

[Music Engineer]

[*] GMPI plugins must be able to provide a parameter-specific method for incrementing/decrementing a parameter value from a given value. The increment/decrement operation must return the new value, but not change the current value.

As far as I can see Incrementing and decrementing are ill-defined for a continuous parameter?

as i understand it, the plugin should define an appropriate increment. perhaps it's meant to work with hardware interfaces that provide inc/dec buttons - like, a dB slider increments or decrements in 0.1 dB steps

[mr.ardour]

The thing with UI/DSP separation is that it's cool/useful but it's not a common use case. I'd say clearly 95% of plugins don't need it. I have nothing against it, but I have some thing against it being the default and recommended method.

I think some clarification is needed here. There are at least two levels of UI/DSP separation:

1) both in the same process, but communication between them must be mediated by the host
2) two different processes, with communication mediated by the host

The first one is something that was already clearly necessary back in the early 2000s, which is why the folks in the GMPI working group came up with:

GUIs are not part of a DSP plugin with private access to the DSP internals. All communication between UI and plugin is via standard control signals.

If you're only a plugin author, not a host author, the reasons for this might not be clear, but they've been "discovered" over and over again during the last 20-30 years. The model in which the GUI has its own "special" access to the DSP causes lots of problems for hosts (different problems in different hosts, different problems at different times, different problems in different workflows).

The second one is something that was already in the air during the GMPI process, which is why we came up with:

GMPI must explore a mechanism for out-of-process UIs. Hosts are not required to support this, but are strongly encouraged to do so.

I would wager that no host developer will agree with you or Urs if you insist that your GUI must have direct memory/function call access to the DSP part of your plugins. The question about the synchronous/asynchronous nature of the host-provided mechanisms that Urs has raised are important, and deserve a solid answer.

Finally, the default (not recommended) method with LV2 and VST and AU APIs is that the DSP and UI run in the same process, with only host-mediated interaction.

[Dewdman42]

I think it pretty much boils down to the learning curve of a format. Is it more like VST2 (open example project, build, go) or is it more like VST3 (“what is all this, where is MIDI?”)?

+1000

Part of the reason so many cool VST plugins exist is because its easy to make one. Many people with scarcely any coding experience and more of an interest in music have been able to do so.

scanning all plug-ins in only 0.1s really worth having to learn, deal and debug some obscure looking file format? What advantage does this bring to the platforms that most VST developers work on? I can imagine that a lot of this - extensions, turtle, concurrent concepts - looks like baggage that is somehow related to Linux or the project history to many. There’s just a lot to take in, and there are not many answers to my questions out there.

Exactly.

I think what can’t be neglected is that many plug-in developers are just not interested in “going deep“ about a format, and LV2 might just have too many unknowns to successfully replace VST. Yes it’s already there, it can do everything that we need, but doesn’t it somehow suffer from the same kind of “being too much” that has slowed VST3?

I agree fully.

Nevertheless, while I’d be happy to give LV2 another try, we’re currently evaluating a different solution which we think has more potential to work out, but it doesn’t have a proper name yet. We’ll see.

I hope someone will come up with something like that.

Open Source is really cool in certain ways, it provides a bit of a "democracy" so to speak, and there is just so much code out there now and it has definitely fostered interaction and new ideas to emerge, all cool stuff. but in terms of developing a "standard" so to speak...I personally think the open democracy aspect can become mob rule with a lot of disagreement and chaos as to how it should be done, leading to splintering side versions or at the very least it stalls for a long time while the mob argues about how it should be done, etc..

Anyway, I don't know the right solution, I am skeptical that the two biggest DAW's in the world, arguably. (logicPro and cubase) would let hell freeze over before adopting LV2 or any other open source plugin protocol to take over VST or AU.

All plugin developers need to be able to target those hosts for their plugins, if care about selling it anyway.

I don't have any hope whatever that the LV2 open source democracy will be able to solidify it into a simple, concise, consistent and reliable protocol which would be stable enough, as a protocol, for big DAW players to consider adding it. We're talking mainly today about: Apple, Steinberg, PreSonus, MOTU, Ableton. Everything else is small time and some of them may add it, sure, but as a plugin developer..we have to target those big five if we want to sell anything. Maybe PreSonus would do it eventually, but I have little hope that the others would at this time unless LV2 became 30x more prevalent then it is today...and like I said...a few of them would let hell freeze over first.