aciddose - vsthost

[brambos]

but a majority of plugins still dont work. (most older plugins which do not use newer functions work fine, like neon, vb-1, some older plugs i got off kvr here) and there are a few new which work ok too, including xhip.

Good luck with that (you're going to need it!). I've been down that road recently, and it's a tough one getting every plugin out there to work properly. I know I've cursed certain plugins from time to time because I couldn't figure out how to get around various problems getting them to function consistently...

[aciddose]

its a nightmare for both the coders of hosts and plugins.

vst is so poorly defined..

the single greatest mistake ever made by the original coders:

void *object;

most hosts use typecasts from the void *object into a audioeffect or audioeffectx class, but this means the class objects must match absolutely in the plugin and host. this is such a bad idea to do.. it means these classes cannot be modified!

a correctly functioning host should use only the original dispatcher, process, setParameter, getParameter and processReplacing function pointers and the data in the structure. everything possible with direct access to the classes is also possible simply using the original functions.

the sad part is, it cannot simply be blamed on the lack of documentation. even cubase typecasts these pointers!

it makes me sick because i can not modify the body of these classes. i've stripped as much code as possible and it is still ugly as hell.

oh well. when distributing my own plugin sdk, i will not be making the same mistakes.

the pointer should have been called:

void *DONOTUSEYOUFUCKINGMORONS;

would have worked better that way i think.

[brambos]

[quote="aciddose"]i've stripped as much code as possible and it is still ugly as hell.[quote]

Don't even mention the ugliness of code. Once you've implemented workarounds to get all plugins (including SynthEdit plugins) it'll get much worse. You'll feel ashamed and dirty every time you look at it...

Cheers!

Bram

[LIMITAPROACHINGINFINITY]

I wan't to see what accidose could do with a host. What style of host are you thinking of acidose?

[spacedad]

if your xhip tracker is anything to go by,it should be bloody good.

[arke]

its a nightmare for both the coders of hosts and plugins.

vst is so poorly defined..

the single greatest mistake ever made by the original coders:

void *object;

most hosts use typecasts from the void *object into a audioeffect or audioeffectx class, but this means the class objects must match absolutely in the plugin and host. this is such a bad idea to do.. it means these classes cannot be modified!

a correctly functioning host should use only the original dispatcher, process, setParameter, getParameter and processReplacing function pointers and the data in the structure. everything possible with direct access to the classes is also possible simply using the original functions.

the sad part is, it cannot simply be blamed on the lack of documentation. even cubase typecasts these pointers!

it makes me sick because i can not modify the body of these classes. i've stripped as much code as possible and it is still ugly as hell.

oh well. when distributing my own plugin sdk, i will not be making the same mistakes.

the pointer should have been called:

void *DONOTUSEYOUFUCKINGMORONS;

would have worked better that way i think.

Wait wait wait, I don't get it ....

I've never used the VST SDK but this seems ridiculous - this void* object is either audioeffect, or audioeffectx (whatever the hell that means), but theres no definite way to determine which? Or rather, theres no "standard struct typedef" for them? It sounds ugly but I don't get why

[aciddose]

arke, the void pointer is used internally. basically vst works by having a large number of "opcodes" or numbers which represent what kind of function is desired. there are two sets, the host opcodes, and effect opcodes.

the host has a function which does:

long __cdecl vstcall(AEffect *effect, long opcode, long index, long value, void *ptr, float opt)
switch (opcode)
{
case audiomasteropcodewhatever: dothis(); return something;
...

and likewise for the effect. it needs the pointer to the AEffect struct so that it can call the functions like setparameter, sendeffectopcode (called dispatcher) and others.

so the void *obj is intended purely for internal use by the plugin which will assume it is of the type *AEffect. however, somewhere somebody decided "hey.. instead of aeffect we can make this point to the c++ class AudioEffect, and then have direct class access rather than use the dispatcher and opcodes!

that seems fine to me, however the problem is that the base class AudioEffect was never designed with that in mind. it should have a single disatcher call which can be overridden by new classes, and the calls can go down the chain through the older functions until reaching the base AEffect function.

however, rather than do that the coders who messed this up decided to take the oposite route of using the dispatcher functions, and simply directly access the class instead. BIG MISTAKE. that means any host which assumes those classes will match their own definitions will only work with plugins which use those _EXACT_ matching class definitions and object structure (dependant upon compiler.)

i've argued about how vst's design sucks in the past, and honestly i've said there is nothing really wrong with the dispatcher method. the problem is the combination of both the dispatcher, class functions, virtual functions, and assumtions that are made. once "vst 2.0" was created the entire specification was basically ruined.

if they had used a c++ class for the AEffect instead of a c struct, it would have been possible to mark the *obj pointer as private and specify that it was not to be used externally. keeping virtual functions out of the class definition would have ment basically that the structure in memory of the class would match that of the c struct expected.

so, not only is the problem due to poor documentation for outside developers, but i suspect somebody inside stienberg made this mistake because they didnt know the rules which had been applied in the first versions of the code. this is an extremely common problem inside software companies and is the reason c++ was designed.

anyway, nothing i can do to deal with it now. all i can do is design a host which doesnt make these assumptions, eventually becomming a wrapper for my own plugin format which doesnt suffer from these design flaws.

these are by the way, flaws that will need to be eliminated to ensure workability with new platforms. this is where vst, dx, and au all fail, and it gives the chance for a new format.

i'd be surprised if i'm the only one with this in mind right now. i'd suspect there are several formats in the works.

[aciddose]

as for what kind of 'host' i'm planning to make, i can say this host will make all hosts before it absolutely obsolite. i can also say very little code will be required for the host. everything is a module, an object, hint hint.

the term host is obsolite.
enviroment. audio enviroment.
maybe operating system?
abstraction yields power.

[dover666]

aciddose - said
the term host is obsolite.
enviroment. audio enviroment.
maybe operating system?
abstraction yields power.

you good

[arke]

however, rather than do that the coders who messed this up decided to take the oposite route of using the dispatcher functions, and simply directly access the class instead. BIG MISTAKE. that means any host which assumes those classes will match their own definitions will only work with plugins which use those _EXACT_ matching class definitions and object structure (dependant upon compiler.)

....

You have got to be kidding. Nobody is really that stupid, or ...?

as for what kind of 'host' i'm planning to make, i can say this host will make all hosts before it absolutely obsolite. i can also say very little code will be required for the host. everything is a module, an object, hint hint.

class cModuleSequencer extends cModule { ... }; been wanting to make something similar. With my luck I'll never get around to it.

[arakula]

this host does not assume anything beyond the aeffect structure. no typecasts are used, meaning this will load plugins which will not be loaded by 99% of other hosts which use typecasts to audioeffectx or etc.

Please qualify that marketing hype.

[arakula]

Oh, and...

the single greatest mistake ever made by the original coders:

void *object;

most hosts use typecasts from the void *object into a audioeffect or audioeffectx class, but this means the class objects must match absolutely in the plugin and host. this is such a bad idea to do.. it means these classes cannot be modified!

You have carefully omitted something.
Something really noteworthy.

From V2 to V2.3 (unfortunately, I don't have any older ones since a server hard disk crash some time ago), the complete line in AEffect.h reads:

Code: Select all

void *object;	// for class access (see AudioEffect.hpp), MUST be 0 else!

In V2.4, it's

Code: Select all

void* object;		///< #AudioEffect class pointer

IOW, it is documented what the "stienberg" people intended. This has to be a pointer to an AudioEffect object (or a derivate, but the host can't assume anything about that), or 0 otherwise. If you (or anybody else) use another structure in your plugins and still put it in the object pointer, it's a violation of the VST spec (as badly documented it may be).

Using another class hierarchy (or none at all) should be possible by extending the AEffect structure, putting your own object pointer beyond the original structure. If the host doesn't correctly interpret a NULL pointer, it's the host's problem, just like misinterpreting it as an AudioEffectX object; incorrectly filling the object pointer with something else, however, is the plugin creator's fault.

P.S.: the real VSTHost doesn't use the object pointer

[aciddose]

i've tried filling obj with null and using usr, and other methods. almost all hosts fail.

also, the term 'marketing hype' does not apply to free software.

is the "real vsthost" free?
to my knowlage there are about 100 "real vsthost"s..

if anyone disagrees with the use of the name "vsthost", i'm sorry, but if you attempt to trademark your toaster model made by you company called "toaster makers", "toaster", on a market which already uses the term "toaster" informally, good luck.

"vsthost" is a compound, "host of vst", implied "plugins", "modules", "objects", etc.

i'm simply stating my purpose for using the 'name' vsthost for an executable label. i have absolutely no knowlage of any software called vsthost.

[eidenk]

acidhost maybe. I won't claim any royalties from you if you choose to use this name for your vst host. It's entirely free.

Yes, the "real vsthost" is free and it's a splendid little piece of software IMO. I like it a lot.

[arakula]

i've tried filling obj with null and using usr, and other methods. almost all hosts fail.

Still, you didn't name one. Could you, please, provide a list? It would be really interesting - especially if Steinberg's own software is on that list!

is the "real vsthost" free?

Yes.

to my knowlage there are about 100 "real vsthost"s.. [...] i have absolutely no knowlage of any software called vsthost.

Your lack of knowledge is obvious, yet you state that you know about 100 "real vsthost"s...

Edit: oh, BTW... http://www.google.com/search?q=vsthost