Selling VST2 after October 2018: Steinberg agreement
- KVRAF
- 12554 posts since 7 Dec, 2004
https://www.ladspa.org/ladspa_sdk/ladspa.h.txt
I'm sure there are already abstract interface implementations like I describe out there too, although I can't be bothered to find one (if I put in the effort I could just as easily write one myself.)
Unfortunately these things don't seem to be maintained much. One major problem with ladspa is its outdated c style. The header could use a proper modernization and a number of changes in my opinion. LV2 is just "ladspa++" so suffers from identical issues.
Of course I hate the idea of using "long int" to specify "opcodes" and would prefer strings instead due to extensibility. For example you can always redefine the value of "1" but it isn't going to be trivially compatible.
You can however redefine "get_func_ptr("process")" if you properly define it to begin with right from the start. That's obviously the hard part.
In my own code I've found passing additional parameters to be necessary: for example a voice index, flags or other values beyond the trivial inputs/outputs/blocklength. In addition it doesn't make sense not to abstractly handle different input types such as floating point buffers vs. MIDI event buffers while at the same time the argument can be made that these types should be divided (audio buffers vs. event buffers.)
I believe a modular abstract "i/o pin" system may be a hard sell to those who have grown accustomed to the current concrete method.
Unfortunately I doubt the market exists to support such discussion in the long run anyway. It would have been nice to have had this discussion back in 95 or so and we might have a reliable plug-in interface format that served much more than just the audio plug-in market.
2020? I'm not so sure there is much demand for it anymore.
I'm sure there are already abstract interface implementations like I describe out there too, although I can't be bothered to find one (if I put in the effort I could just as easily write one myself.)
Unfortunately these things don't seem to be maintained much. One major problem with ladspa is its outdated c style. The header could use a proper modernization and a number of changes in my opinion. LV2 is just "ladspa++" so suffers from identical issues.
Of course I hate the idea of using "long int" to specify "opcodes" and would prefer strings instead due to extensibility. For example you can always redefine the value of "1" but it isn't going to be trivially compatible.
You can however redefine "get_func_ptr("process")" if you properly define it to begin with right from the start. That's obviously the hard part.
In my own code I've found passing additional parameters to be necessary: for example a voice index, flags or other values beyond the trivial inputs/outputs/blocklength. In addition it doesn't make sense not to abstractly handle different input types such as floating point buffers vs. MIDI event buffers while at the same time the argument can be made that these types should be divided (audio buffers vs. event buffers.)
I believe a modular abstract "i/o pin" system may be a hard sell to those who have grown accustomed to the current concrete method.
Unfortunately I doubt the market exists to support such discussion in the long run anyway. It would have been nice to have had this discussion back in 95 or so and we might have a reliable plug-in interface format that served much more than just the audio plug-in market.
2020? I'm not so sure there is much demand for it anymore.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
- Banned
- 4021 posts since 7 Sep, 2002
-
- KVRian
- 1265 posts since 9 Sep, 2005 from Oulu, Finland
And one is free to do a C++ wrapper around them with RAII and whatever goodness...stratum wrote:About ladspa's old c-style: These outdated c-style api's are popular for a good reason: They can retain binary compatibility almost forever.
-
- KVRer
- 11 posts since 15 Jan, 2016
With python or even php 7 this will be possible.Xenakios wrote:And one is free to do a C++ wrapper around them with RAII and whatever goodness...stratum wrote:About ladspa's old c-style: These outdated c-style api's are popular for a good reason: They can retain binary compatibility almost forever.
-
Richard_Synapse Richard_Synapse https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=245936
- KVRian
- 1136 posts since 20 Dec, 2010
We also use older agreements without an expiration date. As I understand the new agreement, Steinberg can terminate the contract with a 36 months notice if they want to?Aleksey Vaneev wrote:This is not quite correct. E.g. I use VST2 SDK from 2006, at that time I had a license to use it which had no explicit expiration time. Steinberg simply can't force anyone to stop using older SDKs, as it was a done deal at the time. The new rules may apply to latest SDK version, but who cares about it..
Richard
Synapse Audio Software - www.synapse-audio.com
- Banned
- 4021 posts since 7 Sep, 2002
Do you have a link to the new agreement?Richard_Synapse wrote:We also use older agreements without an expiration date. As I understand the new agreement, Steinberg can terminate the contract with a 36 months notice if they want to?Aleksey Vaneev wrote:This is not quite correct. E.g. I use VST2 SDK from 2006, at that time I had a license to use it which had no explicit expiration time. Steinberg simply can't force anyone to stop using older SDKs, as it was a done deal at the time. The new rules may apply to latest SDK version, but who cares about it..
Richard
-
Richard_Synapse Richard_Synapse https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=245936
- KVRian
- 1136 posts since 20 Dec, 2010
Sure, it's all public & part of the SDK:Aleksey Vaneev wrote:Do you have a link to the new agreement?
https://www.steinberg.net/de/company/developer.html
If you don't want to download the whole thing, use the GitHub link from Steinberg:
https://github.com/steinbergmedia/vst3sdk
Richard
Synapse Audio Software - www.synapse-audio.com
- Banned
- 4021 posts since 7 Sep, 2002
No VST2 agreement as far as I can tell.Richard_Synapse wrote:Sure, it's all public & part of the SDK:Aleksey Vaneev wrote:Do you have a link to the new agreement?
https://www.steinberg.net/de/company/developer.html
If you don't want to download the whole thing, use the GitHub link from Steinberg:
https://github.com/steinbergmedia/vst3sdk
Richard
- KVRian
- 1234 posts since 31 Dec, 2008
It's included in the folder "VST2_SDK" within the full download.Aleksey Vaneev wrote:No VST2 agreement as far as I can tell.Richard_Synapse wrote:Sure, it's all public & part of the SDK:Aleksey Vaneev wrote:Do you have a link to the new agreement?
https://www.steinberg.net/de/company/developer.html
If you don't want to download the whole thing, use the GitHub link from Steinberg:
https://github.com/steinbergmedia/vst3sdk
Richard
www.solostuff.net
Advice is heavy. So don’t send it like a mountain.
Advice is heavy. So don’t send it like a mountain.
- Banned
- 4021 posts since 7 Sep, 2002
-
- KVRian
- 636 posts since 4 Apr, 2010
Download the latest SDK, it's in there:Aleksey Vaneev wrote:Do you have a link to the new agreement?
https://www.steinberg.net/en/company/developers.html
edit: Oops, stale window from earlier, already answered...
My audio DSP blog: earlevel.com
- KVRAF
- 12554 posts since 7 Dec, 2004
I'm referring to lack of use of stdint.h or similar, the assumption that sizeof(long int) == 4 is stupid.Xenakios wrote:And one is free to do a C++ wrapper around them with RAII and whatever goodness...stratum wrote:About ladspa's old c-style: These outdated c-style api's are popular for a good reason: They can retain binary compatibility almost forever.
There are numerous very simple changes that could be made to ladspa to clean up the headers, eliminate abuse of macro functionality and global constants while improving portability, reliability and maintainability.
For example see the modern C style coding practices employed in a project like the Linux kernel.
... and "C++ wrapper", you're kidding right?
You want me to wrap gold foil around that turd?
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
-
- KVRAF
- 2256 posts since 29 May, 2012
That's not only stupid, but also incorrect. Incorrect code usually does not work, but sometimes it does. Do they actually make that assumption? Where, I couldn't see.aciddose wrote:the assumption that sizeof(long int) == 4 is stupid.
~stratum~
- KVRAF
- 12554 posts since 7 Dec, 2004
They pack ints by shifting and they also use ints to store packed flags by masking without knowing for certain what the size of the int is.
That was fine in old style C, but the header really ought to be updated to use stdint.h in the very least. Unfortunately the question becomes "how many derived projects won't compile anymore?" and honestly: probably all of them!
So I'd bet they haven't updated the header for that reason: updating the header would eliminate 99% of the derived software that will likely never be updated. An old LADSPA host won't load new LADSPA plug-ins.
See here for example:
They don't use a structure version variable in the main structs so there is no reliable way to know about any changes: in other words "fixing" LADSPA is now impossible due to original design flaws.
http://lv2plug.in/ns/lv2core/lv2.h
LV2 was implemented and does use stdint.h where they gave up on maintaining any sort of compatibility. At the same time however they used the same structures as LADSPA and so inherited the same foundational design flaws.
That was fine in old style C, but the header really ought to be updated to use stdint.h in the very least. Unfortunately the question becomes "how many derived projects won't compile anymore?" and honestly: probably all of them!
So I'd bet they haven't updated the header for that reason: updating the header would eliminate 99% of the derived software that will likely never be updated. An old LADSPA host won't load new LADSPA plug-ins.
See here for example:
Code: Select all
typedef struct _LADSPA_Descriptor {
/* This numeric identifier indicates the plugin type
uniquely. Plugin programmers may reserve ranges of IDs from a
central body to avoid clashes. Hosts may assume that IDs are
below 0x1000000. */
unsigned long UniqueID;
http://lv2plug.in/ns/lv2core/lv2.h
LV2 was implemented and does use stdint.h where they gave up on maintaining any sort of compatibility. At the same time however they used the same structures as LADSPA and so inherited the same foundational design flaws.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.