How important is VST3 support for you as a customer

[Elektrobolt]

not if you give up certain functionality to be compatible with vst3. this is a lowest common denominator approach.

Please, I'd like to know what certain functionality you would have to give up.

[aciddose]

well the midi cc issues for example, pointers shared with the gui <-> audio thread, the simplicity of a c struct / function pointer interface.

i've always suggested that the best interface would be based upon function pointers and strings, similar to vst's "cando", but not exactly. what they did for vst3 is just madness.

[Urs]

Hmmm, I wouldn't say madness. I'd say they just moved from a low level approach that invited developers to all sorts of bugs into an object oriented approach with a high level of encapsulation and less buggy prone operation. E.g. they removed pointers from gui to dsp, which are a really bad design.

They also harmonised the event model so that MIDI and Parameters are now the same thing. Very good IMHO.

And they added string based messages, much more flexible than the old and hilarious candos.

[Elektrobolt]

Thank you, Urs!

MIDI is an ancient technology and VST3 is encapsulating it with newer technology, so that we are not limited to MIDI with our plug-ins. It has been tried before but is only now being realized.

Separating GUI from core threads is more or less becoming the de facto standard. Operating Systems, like UNIX has done it for years, Windows Server 2008 can be installed with CLI only, etc. HTML was and is being further pushed into smaller technology components, separating GUI, data, behavior, etc.

C/C++ is still around, and still ancient, but in lack of a better alternative, often a language of choice. I agree with simplicity of course, but these programming languages yield far too much margin of error in the hands of programmers that cannot or do not follow system rules.

Some coders see this as a way that they are being "controlled" or that the cannot "realize some imaginary full potential" of a system (or themselves) and don't like it. But the truth of the matter is that this is really the reason why it has come here. Most application problems experienced while using a system are not systemic, but applications not following system rules.

It all comes down to *some* human not being BC (Binary Correct, lol) somewhere, whatever the reasons.

[Big Tick]

Hmmmm.... You may be right, but still, looking at the vst3 sdk compared to 2.4, makes me think that someone at Steinberg forgot to follow this wise guy's advice:

Simplicity is the ultimate sophistication.

[aciddose]

when i refactor code, my goals are always:

1) smaller resulting code, easier to follow and faster to work with
2) more manageable code, less "secret laws" needed to be kept in mind when using
3) more efficient code, never sacrificing efficiency in size or speed

all three at once of course, to the best of my ability. otherwise re-factorization is just a bad idea and unjustifiable.

one problem with vst3's methods is that the requirements for interoperability come into conflict with copyright on the interface modules (classes). normally a header is not considered copyrightable due to the fair-use for interoperability, and the fact that it does not contain original content but is rather a technical description of a thing, rather than the thing being described itself.

now, because the implementation is mixed with the interface and it's description, either the copyright on the entire sdk isn't valid, or you're absolutely forced to agree to an additional contract in order to accomplish inter-interoperability. clearly the first case is the fact of the matter, however most people wouldn't feel comfortable without having this already specifically verified in court.

so vst2 is better in a legal sense as well.

[Urs]

so vst2 is better in a legal sense as well.

But still a mess. We had the fall out before and I stand my point that you can't legally open source VST2 plugins no matter what because you're not allowed to post derivative work. Same for VST3.

Which on the perspective of a *customer* (as opposed to a cheapskate) does not make any difference.

[aciddose]

yes you can. the struct outlined in the aeffect.h header is an interface, not an original work but a technical description of something. therefore it isn't under copyright. also, it's possible to make a new version via having one party write a technical description of the interface, and having another implement it based upon that description.

doing so with vst3 would be a nightmare if not impossible, similar to rtas or au.

since it isn't under copyright, i like many others obtained versions of the interface privately and did not agree to a license, assuming such would be enforceable or provable in the first place.

you might want to check up on the definition of derivative.

it's going to be putting you at risk if you yourself look at the original code and re-implement it based upon the functionality, but not the code itself. technically though your work unless it used specific portions of the original wouldn't be derived. for example i can write a novel about a girl who follows a turtle through a closet, eats a biscuit and has her head grow, then eats a turnip and has it shrink back to normal size and not be sued by the producers of recent film versions of through the looking glass.

i've seen the films, i've read the novel. i can quote various lines directly or from memory with ease. my own work although remarkably similar would still not be a derivative.

a late rabbit, a "mad hatter" and playing cards painting white roses red or as soldiers might be, assuming the original work was still under copyright, an issue.

[Urs]

Similar to AU? Excuse me, but AUs can be open sourced without any problem. It's a BSD-like license.

Also, in order to publish VSTs you have to sign a license agreement. It's usually sent back and forth between you and Steinberg via fax, but you can also post it. Everybody who doesn't sign that agreement and yet publishes VSTs technically infringes Steinberg's copyrights.

[aciddose]

http://en.wikipedia.org/wiki/Interoperability#Software

copyrights on what?, this?

Code: Select all

struct vst_aeffect
{
 vst32 id;
 vstptr (VSTCALLBACK *dispatcher)(vst_aeffect *effect, vst32 opCode, vst32 index, vstptr value, void *ptr, float opt);
 void (VSTCALLBACK *process)(vst_aeffect *effect, float **inputs, float **outputs, vst32 sampleframes);
 void (VSTCALLBACK *setParameter)(vst_aeffect *effect, vst32 index, float parameter);
 float (VSTCALLBACK *getParameter)(vst_aeffect *effect, vst32 index);
 vst32 nPrograms;
 vst32 nParams;
 vst32 nInputs;
 vst32 nOutputs;
 vst32 flags;
 vstptr resv1;
 vstptr resv2;
 vst32 latency;
 vst32 real_flags;
 vst32 offline_flags;
 float io_ratio;
 void *aexptr;
 void *userptr;
 vst32 uid;
 vst32 version;
 void (VSTCALLBACK *processReplacing) (vst_aeffect *effect, float **inputs, float **outputs, vst32 sampleframes);
 void (VSTCALLBACK *processDouble) (vst_aeffect *effect, double **inputs, double **outputs, vst32 sampleframes);
 char padding[56];
};

typedef vstptr (VSTCALLBACK *hostCallback) (vst_aeffect *effect, vst32 opcode, vst32 index, vstptr value, void *ptr, float opt);

i don't believe you can copyright an arbitrary arrangement of data. patent yes. copyright? no.

(is AEffect a trademark? is VST? i'm not really sure if it applies inside code anyway, i'm pretty sure not, but tried to rename such variables just incase. on second thought i'm pretty sure having an enum os_vendors { microsoft, apple, ... } isn't a problem so using the same variable names as anyone else isn't either.)

if you're referring to their wrapper classes of course that's copyright to them - but it's also crap code and i'd never use it.

AUs are licensed yes but the format of the code creates a copyright issue with interfacing as well. implementing all the additional wrappers, classes and most importantly implementation without violating their copyrights is quite difficult. unlike vst2, which is entirely defined by a header filled with structs, enumerations and function definitions - not under copyright.

(example of "implementation"; the "vstsdk" wrapper classes audioeffect/x and so on have functions that actually do something in them. for example they don't just define an access point like getsamplerate, they actually call the function as well. they even include string manipulation functions, functions to load specific data into structs and so on. that code does indeed fall under copyright and can't be used without a license. it's bad code anyway though, and could be written by just about any fool in a few minutes too, so why use it?)

[ObsoleteAcc99]

[DELETED]

[soma]

The reason people don't care is because they don't know what they are missing because hosts are too lazy to implement all the cool features.

[Urs]

copyrights on what?, this?

Gosh. Nevermind.

[shamann]

The reason people don't care is because they don't know what they are missing because hosts are too lazy to implement all the cool features.

Like what?

[aciddose]

copyrights on what?, this?

Gosh. Nevermind.

this is tested in court already in most of north america (united states case law can apply in canadian courts iirc) in a case where a telephone company put fake numbers into their book in order to catch cases of what they deemed was plagiarism. a company printing phonebooks was caught via this method and extorted to pay a licensing fee. they refused and the case went before a judge.

the finding by the judge stated that since the book was filled not with creative content, but rather with technical information that didn't even have a human hand in it's arrangement (it was alphabetical, of course, printed by computer) it was not protected under copyright. although fake entries were added, these still were not protected under copyright (i don't remember the specific reason, look it up if you care, but it seems obvious in a non-legal sense.)

the finding stated that the layouts and arrangement of data such as the particular order of types of data in each row, the spacing, the type faces, special icons or images, color schemes and margins in combination formed a work protected under copyright. however, the company being sued for copying the entries used their own layouts, type faces, color schemes and imagery.

the case was dismissed.

i know there are specific cases relating to header files, interoperability documentation, file formats and so on but i don't know of any specific cases although i do know they exist. you'd have to look that up on your own if you're so concerned or desire to know.

in those cases, although there is often a human hand in the arrangement of information in a header file for example, fair use for the purpose of interoperability over-rides that.

comments and other creative content _do_ fall under copyright and so must be removed. a document containing partially creative content and non-creative content, having had the creative content removed is not a derivative of a copyright protected work as the non-creative content is not considered in the first place.

just take a look at the recent BS sentational blog posts some people wrote about "issues" with android including linux headers. these just don't fall under copyright (internationally, apparently) with the comments removed and so the articles are either entirely BS produced by incompetents, or intentional FUD.