Selling VST2 after October 2018: Steinberg agreement

[Vertion]

Is it possible to create a 'KVR standard' or open standard which can wrap any of the other formats (Steinburg, Apple, etc)? Someone with a VST2 license could create a wrapper, one for 32 and one for 64. It seems to me someone can create an abstraction layer to free us from the bonds of these companies and create a new open standard that agrees with everyone. The Xhip standard perhaps?

A universal wrapper that also can load ASMJIT scripts would be absolutely wonderful.

[ghettosynth]

Is it possible to create a 'KVR standard' or open standard which can wrap any of the other formats (Steinburg, Apple, etc)? Someone with a VST2 license could create a wrapper, one for 32 and one for 64. It seems to me someone can create an abstraction layer to free us from the bonds of these companies and create a new open standard that agrees with everyone. The Xhip standard perhaps?

A universal wrapper that also can load ASMJIT scripts would be absolutely wonderful.

I don't know the details because I'm basing this off a very short google search and view of the tool, but, I believe that there's something like this for LADSPA plugins. At least in Reaper they seem to appear as native plugins. I could be completely wrong, it was just a passing thought and I meant to get back to it but it's not that important to me at the moment.

I'm sure that someone will correct me if I have this wrong, but free bump anyway, woot!

[Aleksey Vaneev]

Nobody cares about your opinion or feels when we're discussing the facts.

"... but I don't wanna use that feature!"

Then don't.

Some features open "can of worms", bad design decisions I would say. From marketing point of view, creating a single DLL with 30 plugins is tempting, but will that make users happy to scroll through plugins they do not need or even know and have no ability to remove (plugin standards do not have a feature to remove individual plugins exposed by the DLL bundles)?

[audiothing]

Is it possible to create a 'KVR standard' or open standard which can wrap any of the other formats (Steinburg, Apple, etc)? Someone with a VST2 license could create a wrapper, one for 32 and one for 64. It seems to me someone can create an abstraction layer to free us from the bonds of these companies and create a new open standard that agrees with everyone. The Xhip standard perhaps?

A universal wrapper that also can load ASMJIT scripts would be absolutely wonderful.

[ghettosynth]

Is it possible to create a 'KVR standard' or open standard which can wrap any of the other formats (Steinburg, Apple, etc)? Someone with a VST2 license could create a wrapper, one for 32 and one for 64. It seems to me someone can create an abstraction layer to free us from the bonds of these companies and create a new open standard that agrees with everyone. The Xhip standard perhaps?

A universal wrapper that also can load ASMJIT scripts would be absolutely wonderful.

LOL, right!

It seems that there's quite some interest in bringing LV2 support to the major OSes, but, of course, mostly that interest is from fellow nerds. This is one of those situations where the perfect is the enemy of the good. LV2 might not be perfect, but it does have some traction and if one wants to move towards an open standard for plugins then that seems like a better investment of time and thought energy than imagining new standards that solved ill-posed problems, no?

[george]

Funny because it's true

[Vertion]

Let me clarify. Blue Cat's PnS covers VST for Win32/64 and MacOS. It runs compiled binaries or scripts, effectively decoupling the requirement to get a Steinburg license. Since Steinburg is going insane, this is obviously one way to circumvent this issue. KVR is the place where the real developers meet. This is the only community with the power to dig itself out of this hole forever. It does not need to be a standard rather a wrapper. PnS effectively created a new standard by its interface to binary calls itself, this should be self evident. Developers are problem solvers, here is one proposed solution.

[Xenakios]

Blue Cat's PnS covers VST for Win32/64 and MacOS.

Too bad it costs 99 euros/USD. It's not a very appealing thing to tell one's potential users "Oh, by the way, you need to get this $99 thing from another developer before you can even demo my product."

[audiothing]

Let me clarify. Blue Cat's PnS covers VST for Win32/64 and MacOS. It runs compiled binaries or scripts, effectively decoupling the requirement to get a Steinburg license. Since Steinburg is going insane, this is obviously one way to circumvent this issue. KVR is the place where the real developers meet. This is the only community with the power to dig itself out of this hole forever. It does not need to be a standard rather a wrapper. PnS effectively created a new standard by its interface to binary calls itself, this should be self evident. Developers are problem solvers, here is one proposed solution.

I'm not familiar with Blue Cat's PnS, but there are already several plugins that can host other plugins.
JUCE can also easily be used to create a plugin effect/host.
Developers are indeed problem solvers, but the real problem to solve here, IMO, is in the hands of DAWs developers, not plugin developers.

[ghettosynth]

Blue Cat's PnS covers VST for Win32/64 and MacOS.

Too bad it costs 99 euros/USD. It's not a very appealing thing to tell one's potential users "Oh, by the way, you need to get this $99 thing from another developer before you can even demo my product."

Both your comment and the previous comment aren't quite getting the full picture here. First, P&S exports a VST dll so your customers don't need plug-n-script to run your plugin. That said, it has severe limitations such that it is not a viable substitute for traditional development.

This highlights the problem though with any "too simple" solution to this problem. If you make the API too limited, it will not meet people's needs, as soon as you make the API more complex, you have the same complexity issues that translate to a need for more large scale testing that all of the other standards have.

That's why, IMO, if you're going to invest much energy into this, even just thought energy, it's better focused on asking how other established and open standards can be shoehorned into the VST hole.

[camsr]

typedef struct Shoehorn

[Skupje]

Is it possible to create a 'KVR standard' or open standard which can wrap any of the other formats (Steinburg, Apple, etc)? Someone with a VST2 license could create a wrapper, one for 32 and one for 64. It seems to me someone can create an abstraction layer to free us from the bonds of these companies and create a new open standard that agrees with everyone. The Xhip standard perhaps?

Pff, and I thought the move from x86 was hard enough.. Assuming that went smoothly.

[Vertion]

Could make a KvR community DAW, and let the leaders here take control of the market.

We have code competitions regularly, even unofficial ones. The devs could offer prizes since it's in their interest.

If there is interest, I'll help get everyone together. Get the attention of all the Titan devs.

[S0lo]

VST2 has major flaws. Some of them include lack of constness, the most obvious example is process(const T ** const inputs, const T **outputs, ...)

First, You don't need const at the output otherwise you'll not be able to write anything!!

Second, You can do that with overloading the original processReplacing() function without breaking old code compatibility.

Third, those const keywords are only going to protect the programmer at compile time. He can do whatever he wants at run time, he could corrupt the whole address space of the DAW (if not bridged). Any one who thinks that he is doing good protection by just using const should go back to college.

but using strncpy(buffer, ...) is another clear idiot move.

First, I've searched the whole VST2.4 code and they always send the size of the buffer with strncpy!!. May be I missed some thing. Which is by the way the maximum buffer size. strncpy will stop at null characters.

Second, A programmer can still wrongly send the wrong size and it will still cause an access violation if it's more than the reserved memory for it (provided it's not null terminated before the buffer runs out). To think that your protecting any thing by sending the buffer size, is just short sighted.

Third, Allot of these strings have to be acquired using dynamic entry from the user (or like a file name). The only way your going to know the right buffer size is by using something like strlen() which essentially depends on null termination, not your maximum buffer size. Using static large strings for everything is just a waste of memory.

Other problems include the structures lack size/version members: this means these structures are entirely static and can't be replaced entirely.

That is true. But you can very easily wrap the old structures into new structures that includes all old functionality as an old version while adding new features only at the end. (The compiler is already assumed to preserve order for "C" interfaces in the ABI otherwise it will never work even with existing code in VST 2.4, the whole industry is depending on this. Primitive type sizes are assumed to be preserved too). At compile time there should be no conflict. If you need to pass those pointers to structures at run time between DAW and plugin, you would have no problem either since old code will assume old format which lives inside the new format (at the beginning). If you want to pass whole structures without a pointer (which I see no point of) between DAW and plugin. It will still work since old code will see only a subset of the structure.

Code: Select all

struct VstMidiEvent
{
//-------------------------------------------------------------------------------------------------------
	VstInt32 type;			///< #kVstMidiType
	VstInt32 byteSize;		///< sizeof (VstMidiEvent)
	VstInt32 deltaFrames;	///< sample frames related to the current block start sample position
	VstInt32 flags;			///< @see VstMidiEventFlags
	VstInt32 noteLength;	///< (in sample frames) of entire note, if available, else 0
	VstInt32 noteOffset;	///< offset (in sample frames) into note from note start if available, else 0
	char midiData[4];		///< 1 to 3 MIDI bytes; midiData[3] is reserved (zero)
	char detune;			///< -64 to +63 cents; for scales other than 'well-tempered' ('microtuning')
	char noteOffVelocity;	///< Note Off Velocity [0, 127]
	char reserved1;			///< zero (Reserved for future use)
	char reserved2;			///< zero (Reserved for future use)
	VstInt32 struct_version		///< Newly added
	VstInt32 blabla1			///< Newly added
	VstInt32 blabla2			///< Newly added
//-------------------------------------------------------------------------------------------------------
};

As long as the compilers ABI preserves the order and primitive type sizes (which it seams it did for the last 15 years). The added fields will always lay at the end in memory which allows old code to read the old structure as it is. For example processDoubleReplacing() was added latter to the END of the AEffect struct, and things are still working. And if you assume that the ABI is going to break, then there is no point of making VST API from the beginning since any thing can happen that will destroy the whole system. Even the current VST2.4 wont work with future builds of plugins and DAWs.

And even if for any other reason this doesn't work. You can still overload the functions that send these structures using the new better declaration while keeping the old declaration but marking them as deprecated so at least new code uses the new declaration.

In addition as I've already mentioned function pointers should never be included along with data: they should have used getProcAddress(...) or similar and getProcDefinition(...) to specify calling convention, parameters and so on. enumerable functions would also be very useful: rather than just vstmain(...) the exported interface should include bi-directional communication to allow something more like vst_get_types() and vst_create_instance(type n). There are multiple possible definitions although I prefer again c-strings like the effect names: "synth1 (st)" or "synth1 (m)". To deal with sub-types simple token rules can be used: "comma is to be used as a token to separate sub-types and must not appear": to solve for disagreement as to the most applicable token "get_token_string()" could be used!

First, GetProcAddress() for every function there is, needs exporting every function there is. This has to be done with extern "C" in some compilers/platforms otherwise you would end up with compiler name decoration, obviously. No one knows how this C naming convention would go in future as the compiler evolves. So I'd rather be stranded with only one entry point instead of relating tens of functions to it.

Second, whatever you will get from GetProcAddress() you will STORE somewhere. so same thing!!. Otherwise if your suggesting GetProcAddress() every time, thats just a waste of CPU for something that will almost never change.

Third, No matter how abstract and general purpose the API becomes you would still have to ASSUME a minimum point of agreement without prior communication.

Fourth, I can go ten levels of generalization and abstraction more than what you described here. Yet 98% of programmers will still be using 2% of the feature set. For many, Thats just wasted development and design time. At a certain point why even call it a plugin API. It could be an airplane or rocket interface, who knows. If thats fine with you, then thats fine. But it's definitely not fine with every programmer I know of.

What you call facts are facts only in your opinion. And as you've stated before:

Nobody cares about your opinion or feels when we're discussing the facts.

Point is, what you see as fact others may see as opinion and vise versa.

Code: Select all

typedef const char_t *string_ptr_t;
string_ptr_t delimiters = get_token_delimiter_string();
const int sub_units = get_sub_units();
smart_array<string_ptr_t> sub_unit_types(sub_units);
for (int i = 0; i < sub_unit_types.get_length(); i++) {
 sub_unit_types[i] = get_sub_unit_identifier(i);
}
smart_array<interface_t> instances(sub_unit_types.get_length());
for (int i = 0; i < instances.get_length(); i++) {
 instances[i] = create_instance(sub_unit_types[i]);
}

As above. You can go even beyond that. Yet, generalizing too much would end up over-bloating the API and communication, adding confusion for no real practical value. "May be someone will use it, so lets drop 15 years of code because of that someone.". If it was done 15 years back, I'd take it. Now it's too late.

Lets say I'm wrong. If your proposed API is a generalized form for an API then it should be able to handle the old existing code as a special case. It shouldn't be impossible to do. Unless some one wants to deliberately prove a pointless point.

Another flaw: the callback function should not be passed to the constructor! It should be passed to initialize(instance, ...) since the callback can't possibly provide full functionality during construction (does get_sample_rate() make sense when there is no audio processing and multiple I/O at different rates?) There should be no "get_blah()" in the host callback interface. set_sample_rate(), set_maximum_block_size() and others should be host->plugin commands only. Not having a sample-rate should be a valid condition: if the host never sets the sample-rate, coefficients should never be computed.

First, a constructor by definition can be used for initialization. read here: https://www.programiz.com/cpp-programming/constructors
https://en.cppreference.com/w/cpp/langu ... lizer_list

So it doesn't have to be initialize() that does the job.

Second, The callback function does NOT HAVE TO provide full functionality during construction. It's more like, "Take this, Prepare your self for further processing".

Third, audioMasterGetSampleRate as far as I know allows the plugin to get the DAW sample rate WHEN IT WANTS to. It's doesn't have to.

Fourth, Those get_blah() functions are useful for CPU usage when the "blah" information changes rapidly. Say if the position (ppqPos) of the project changes rapidly and there is only one or two plugins who are interested in knowing this. Instead of sending the info to all plugins all the time, only the wanting plugins can query it.

Fifth, Who said that having no sampling rate is not a valid condition!! . You are INFORMED of the sample rate change. Doesn't mean you have to comply.

All your babbling about here is micro level details. Child's play to be honest. It takes much more than that to specify a proper API. Macro level design and big picture analyses. Understanding of current requirements of the music industry, and so forth, defining whats relevant and relaxing what isn't, foreseeing the future.


Lets assume for the sake of the argument that all what I just said is absolutely wrong. You can still definitely build a wrapper around your proposed interface to allow old code to work. Dumping 15 years of code just because an old design was weak is irresponsible and will delay development. Big and small names have used VST2.4. still running. If there was major flaws in it, it would have seriously affected all those products. All these have payed engineers who know what they are doing. They have adopted VST 2 both at the time where there was no other alternative and at times when there is.

Lets, assume that I'm wrong again and indeed there are major flaws in VST 2.4 as you said. From Stienberg point of view, I still think it is irresponsible to forcefully dump VST 2 because of flaws that THEY have made. They could at least have provided a reverse wrapper for old code to compile as VST 3 (The wrapper they have does the opposite, i.e. from VST 3 to VST 2). Now you could say that this is my opinion, and surely it is. But I have the right to express it as you do for yours.

[JunSev]

There is a lot said about this issue, can someone just explain to me if steinberg is forcing DAWs to apply these new standards or just plug-ins? this is quite disgusting, many plug-ins are just VST (no 2 or 3) and a lot of projects are depending of those plug-ins, maybe some of those plug-ins can be updated to VST3 and more, but what about those where the company just leave the plug-in as it is, or there is not updates for those plug-ins anymore, the company could be dead and no updates will be delivered to those plug-ins?...

I mean, there is really a lot in risk and loses, this is a really bad practice, if steinberg is forcing DAWs to apply such disastrous law is a serious time to do something about it, maybe contact the DAW's developers or something, but this can't be just like that...