Goodbye VST2

Subforum for advertisements. Anything that might be interesting to the LinuxMusicians community is fair game here: hardware or software, Free or proprietary, go wild!

Moderators: MattKingUSA, khz

User avatar
khz
Established Member
Posts: 1648
Joined: Thu Apr 17, 2008 6:29 am
Location: German
Has thanked: 42 times
Been thanked: 92 times

Goodbye VST2

Post by khz »

. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
  • I don't care about the freedom of speech because I have nothing to say.
User avatar
khz
Established Member
Posts: 1648
Joined: Thu Apr 17, 2008 6:29 am
Location: German
Has thanked: 42 times
Been thanked: 92 times

Re: Goodbye VST2

Post by khz »

I don't care about VST3.
  • But it can be a decisive turning point.
I don't care about the decisive turning point.
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
  • I don't care about the freedom of speech because I have nothing to say.
User avatar
Michael Willis
Established Member
Posts: 1451
Joined: Mon Oct 03, 2016 3:27 pm
Location: Rocky Mountains, North America
Has thanked: 69 times
Been thanked: 163 times
Contact:

Re: Goodbye VST2

Post by Michael Willis »

khz wrote:I don't care about VST3.
  • But it can be a decisive turning point.
I don't care about the decisive turning point.
These should be lyrics in a song. I might be willing to contribute a piano or clarinet track.
User avatar
khz
Established Member
Posts: 1648
Joined: Thu Apr 17, 2008 6:29 am
Location: German
Has thanked: 42 times
Been thanked: 92 times

Re: Goodbye VST2

Post by khz »

REF: I use and like the freedom of GNU/Linux! Thanks to all of us!
(Instrument: Digital Hardware Synthesizer)
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
  • I don't care about the freedom of speech because I have nothing to say.
User avatar
wjl
Established Member
Posts: 224
Joined: Fri Mar 17, 2017 12:27 pm
Location: near Frankfurt, Germany
Has thanked: 48 times
Been thanked: 26 times
Contact:

Re: Goodbye VST2

Post by wjl »

Michael Willis wrote:
khz wrote:I don't care about VST3.
  • But it can be a decisive turning point.
I don't care about the decisive turning point.
These should be lyrics in a song. I might be willing to contribute a piano or clarinet track.
Hahaha... where's the "like" button? :lol:
more about me on my blog
User avatar
Michael Willis
Established Member
Posts: 1451
Joined: Mon Oct 03, 2016 3:27 pm
Location: Rocky Mountains, North America
Has thanked: 69 times
Been thanked: 163 times
Contact:

Re: Goodbye VST2

Post by Michael Willis »

wjl wrote:
Michael Willis wrote:
khz wrote:I don't care about VST3.
  • But it can be a decisive turning point.
I don't care about the decisive turning point.
These should be lyrics in a song. I might be willing to contribute a piano or clarinet track.
Hahaha... where's the "like" button? :lol:
The laughing icon will suffice, thanks :lol:
Lyberta
Established Member
Posts: 681
Joined: Sat Nov 01, 2014 8:15 pm
Location: The Internet
Been thanked: 1 time

Re: Goodbye VST2

Post by Lyberta »

falkTX wrote:
khz wrote:Welcome VST3 \o/
No thanks

I hope VST3 on linux does not gain tracktion. LV2 is a much better format, in all points.
You still cannot make GPL-compatible VST3 plugins or hosts.
What's preventing creating a JACK host that routes stuff? JACK is IPC so GPL doesn't apply.
User avatar
mike@overtonedsp
Established Member
Posts: 145
Joined: Mon Apr 24, 2017 5:26 pm
Location: Oxford, England
Been thanked: 55 times
Contact:

Re: Goodbye VST2

Post by mike@overtonedsp »

You still cannot make GPL-compatible VST3 plugins or hosts...
I think you can. The VST3 SDK itself is not GPL, but that's a good thing, because if it were, it would mean anyone and everyone using it would be compelled to release their software as GPL rather than having a choice.
LV2 is a much better format, in all points...
Hmm - it could be better - lets take a look at something which should be trivial, as an example:

http://lv2plug.in/ns/lv2core/#minorVersion
minor version

The minor version of an LV2 Resource. This, along with lv2:microVersion, is used to distinguish between different versions of the "same" resource, e.g. to load only the bundle with the most recent version of a plugin. An LV2 version has a minor and micro number with the usual semantics:

The minor version MUST be incremented when backwards (but not forwards) compatible additions are made, e.g. the addition of a port to a plugin.
The micro version is incremented for changes which do not affect compatibility at all, e.g. bug fixes or documentation updates.

Note there is deliberately no major version; all versions with the same URI are compatible by definition. Replacing a resource with a newer version of that resource MUST NOT break anything. If a change violates this rule, then the URI of the resource (which serves as the major version) MUST be changed.

Plugins and extensions MUST adhere to at least the following rules:

All versions of a plugin with a given URI MUST have the "same" set of mandatory (i.e. not lv2:connectionOptional) ports with respect to lv2:symbol and rdf:type. In other words, every port on a particular version is guaranteed to exist on a future version with same lv2:symbol and at least those rdf:types.
New ports MAY be added without changing the plugin URI if and only if they are lv2:connectionOptional and the minor version is incremented.
The minor version MUST be incremented if the index of any port (identified by its symbol) is changed.
All versions of a specification MUST be compatible in the sense that an implementation of the new version can interoperate with an implementation of any previous version.

Anything that depends on a specific version of a plugin (e.g. a serialisation that references ports by index) MUST refer to the plugin by both URI and version. However, implementations should be tolerant and extensions should be designed such that there is no need to do this (e.g. indices should only be meaningful for a particular plugin instance at run-time).

When hosts discover several installed versions of a resource, they SHOULD warn the user and load only the most recent version.

An odd minor or micro version, or minor version zero, indicates that the resource is a development version. Hosts and tools SHOULD clearly indicate this wherever appropriate. Minor version zero is a special case for pre-release development of plugins, or experimental plugins that are not intended for stable use at all. Hosts SHOULD NOT expect such a plugin to remain compatible with any future version. If possible, hosts SHOULD hide such plugins from users unless an "experimental" option is enabled.
This is what I had to decipher recently in order to understand why I couldn't release V1.0 of a plugin.. This makes no sense - it (should be) just a number - that's almost a page of documentation, just for setting one number, and I'm still not completely sure which numbers I'm allowed to have, or, perhaps more importantly, how they will be interpreted by the host, or presented to the user.

No plug-in format is ideal, but LV2 certainly isn't perfect either.
Luc
Established Member
Posts: 741
Joined: Fri Mar 27, 2015 1:04 pm
Been thanked: 1 time

Re: Goodbye VST2

Post by Luc »

Can LV2 "remember" settings like VST2? I vaguely remember some problem with that. Or was it just in Carla?

Anyway, I won't dump literally thousands of plugins that still work fine and produce beautiful sounds just to appease the upgrade-often-upgrade-early compulsive freaks.
User avatar
mike@overtonedsp
Established Member
Posts: 145
Joined: Mon Apr 24, 2017 5:26 pm
Location: Oxford, England
Been thanked: 55 times
Contact:

Re: Goodbye VST2

Post by mike@overtonedsp »

Anyway, I won't dump literally thousands of plugins that still work fine and produce beautiful sounds just to appease the upgrade-often-upgrade-early compulsive freaks.
I don't think you need worry that VST2 is disappearing - I think Steinberg said they will continue to allow VST2 plug-ins in their host applications, and obviously any developer who has been making VST2 plug-ins should still have an existing SDK to work with (the SDK hasn't been updated for a long while anyway, unless you count some extensions by other hosts - yes VST2 is extensible too...)

In case of open-source applications, I guess it depends how their VST2 support is implemented - when I added the basic VST2 for Linux support in Ardour it was based on the Vestige headers - I'm not sure if that's still the case.

I don't expect to (have to) port any of my plug-ins to VST3 on Linux anytime soon - there just isn't the demand - on any OS - to justify the (un-paid) work involved**. I already have VST3 on other OS.

**Plug-in developers generally hate new formats - it normally works out something like:

1. When a new format is announced, if you don't support it no-one will buy your existing catalogue (because future proofing etc)
2. You spend months of work porting to a new format and fixing new bugs, normally just to get back to where you were before.
3. You have to offer the new format free to your existing customers because 'its just the same plug-in'
4. By definition, at the outset, of a brand new format, there is no market for it.
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Goodbye VST2

Post by fundamental »

mike@overtonedsp wrote:
LV2 is a much better format, in all points...
Hmm - it could be better - lets take a look at something which should be trivial, as an example:
Not specific to this example in particular, but in my opinion LV2 ends up coming off as vastly over-complicated due to sub-par documentation rather than actual complex systems under the hood. There's certainly some weird stuff to how everything fits together (e.g. who else uses RDF?), but fairly simple explanations should be able to remove their novelty relatively quickly. Unfortunately there's not a group of people working on solving this issue at the moment.

In my book it has to be a group (3+ individuals) working for a relatively long period of time to provide clear and consistent documents which make developing LV2 hosts/plugins a pain free process. If that ever exists, then problems like the original example would be highlighted in the documents and hopefully motivate small adjustments to the overall LV2 API.
ZynAddSubFX maintainer
User avatar
mike@overtonedsp
Established Member
Posts: 145
Joined: Mon Apr 24, 2017 5:26 pm
Location: Oxford, England
Been thanked: 55 times
Contact:

Re: Goodbye VST2

Post by mike@overtonedsp »

Not specific to this example in particular, but in my opinion LV2 ends up coming off as vastly over-complicated due to sub-par documentation rather than actual complex systems under the hood...
Agreed - maybe this just reflects my personal bias (not against LV2) but I have always felt that simplicity equates strongly with elegance of design - both in hardware and software. But its important to qualify that - I don't mean oversimplifying at the expense of quality or functionality, I mean distilling the design down to its simplest / purest form, and that, quite often is itself a complex and difficult task.
Often it then becomes easier, and logical, to add new functionality or make changes, which is a reassuring affirmation that you got the basic design right - and equally if you find that trying to do something simple (like set the version number in the example) becomes significantly harder than it should be its a reliable indication that something else is wrong elsewhere either in the design or the approach.
Most of what LV2 or other plug-in formats need to do is just exchange some kind of (atomic) value(s) between host and plug-in (in VST2 / 3, most things are a float between 0 and 1.0) Often I find with LV2 that there are several different ways of doing essentially the same thing and I'm not quite sure which is the 'approved' method to use - which is seldom made clearer by the documentation (LV2 is not alone in this - all plug-in SDK documentation has its quirks). Often a simple example combined with concise explanation is a good way for developers to see how the API is designed to operate.
jonetsu
Established Member
Posts: 2036
Joined: Sat Jun 11, 2016 12:05 am
Has thanked: 10 times
Been thanked: 22 times

Re: Goodbye VST2

Post by jonetsu »

I know nothing about VST3, so I do not know any advantages it got. There must be some. OTOH, from my experience with Biotek 2 I saw that a plugin can freeze a DAW. In this case at load time, Bitwig for 10 seconds and Miuxbus32C(Ardour) for at least 60 seconds. The DAW is made totally unresponsive, no menu works, nothing. Even the spinning dial in Bitwig freezes. So if one aspect of VST3 is to decouple a plugin from a DAW through an asynchronous communication framework, then it's pretty clear that would be a benefit. Or at least decouple the non-critical part of it.

Cheers.
User avatar
mike@overtonedsp
Established Member
Posts: 145
Joined: Mon Apr 24, 2017 5:26 pm
Location: Oxford, England
Been thanked: 55 times
Contact:

Re: Goodbye VST2

Post by mike@overtonedsp »

OTOH, from my experience with Biotek 2 I saw that a plugin can freeze a DAW.
Its perfectly possible to write LV2 plug-ins that do this too - in theory having the .ttl file provide a means for the host to discover information about the plug-in without loading it, might be an advantage, but, in practice its not a guarantee that the plug-in is well behaved, it just means that bad plug-ins will show up ok in your plug-ins list, and then when you come to load them into your session they crash the host and you lose your work.
User avatar
sadko4u
Established Member
Posts: 986
Joined: Mon Sep 28, 2015 9:03 pm
Has thanked: 2 times
Been thanked: 359 times

Re: Goodbye VST2

Post by sadko4u »

The f***ing crazy idea of VST3 is... directly shipping C++ interfaces, there's no C-layer at all. That's disappointing. All other aspects are tolerable.
LSP (Linux Studio Plugins) Developer and Maintainer.
Post Reply