Goodbye VST2
Posted: Fri May 18, 2018 6:14 pm
- But it can be a decisive turning point.
Page 1 of 3
Re: Goodbye VST2
Posted: Fri May 18, 2018 7:05 pm
I don't care about VST3.
Re: Goodbye VST2
Posted: Fri May 18, 2018 7:27 pm
These should be lyrics in a song. I might be willing to contribute a piano or clarinet track.khz wrote:I don't care about VST3.I don't care about the decisive turning point.
- But it can be a decisive turning point.
Re: Goodbye VST2
Posted: Fri May 18, 2018 7:30 pm
REF: I use and like the freedom of GNU/Linux! Thanks to all of us!
(Instrument: Digital Hardware Synthesizer)
(Instrument: Digital Hardware Synthesizer)
Re: Goodbye VST2
Posted: Fri May 18, 2018 8:06 pm
Hahaha... where's the "like" button?Michael Willis wrote:These should be lyrics in a song. I might be willing to contribute a piano or clarinet track.khz wrote:I don't care about VST3.I don't care about the decisive turning point.
- But it can be a decisive turning point.
Re: Goodbye VST2
Posted: Fri May 18, 2018 8:18 pm
The laughing icon will suffice, thankswjl wrote:Hahaha... where's the "like" button?Michael Willis wrote:These should be lyrics in a song. I might be willing to contribute a piano or clarinet track.khz wrote:I don't care about VST3.I don't care about the decisive turning point.
- But it can be a decisive turning point.
Re: Goodbye VST2
Posted: Sat May 19, 2018 12:04 pm
What's preventing creating a JACK host that routes stuff? JACK is IPC so GPL doesn't apply.falkTX wrote:No thankskhz wrote:Welcome VST3 \o/
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.
Re: Goodbye VST2
Posted: Sat May 19, 2018 4:21 pm
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.You still cannot make GPL-compatible VST3 plugins or hosts...
Hmm - it could be better - lets take a look at something which should be trivial, as an example:LV2 is a much better format, in all points...
http://lv2plug.in/ns/lv2core/#minorVersion
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.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.
No plug-in format is ideal, but LV2 certainly isn't perfect either.
Re: Goodbye VST2
Posted: Mon May 21, 2018 4:54 pm
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.
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.
Re: Goodbye VST2
Posted: Tue May 22, 2018 10:29 am
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...)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.
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.
Re: Goodbye VST2
Posted: Wed May 23, 2018 2:43 pm
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.mike@overtonedsp wrote:Hmm - it could be better - lets take a look at something which should be trivial, as an example:LV2 is a much better format, in all points...
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.
Re: Goodbye VST2
Posted: Wed May 23, 2018 7:46 pm
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.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...
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.
Re: Goodbye VST2
Posted: Wed May 23, 2018 8:43 pm
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.
Cheers.
Re: Goodbye VST2
Posted: Wed May 23, 2018 9:07 pm
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.OTOH, from my experience with Biotek 2 I saw that a plugin can freeze a DAW.
Re: Goodbye VST2
Posted: Wed Jun 06, 2018 6:23 pm
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.