the "do hosts actually implement..." thread

[citizenchunk]

i often find myself wondering, "why am i implementing this arcane function of the VST SDK? does this really matter?" or perhaps, "couldn't this be accomplished in a smarter/simpler manner?"

i'm sure that everyone here has experienced similar thoughts. so i thought i'd just start a thread for people to dump questions/comments such as these. perhaps i should have titled it: "the 'VST, WTF' thread".

i'll start things off with this:

do hosts actually implement "copyProgram()"? if so, when the hell is it used? also, wouldn't it perhaps be more useful if it were:

Code: Select all

bool copyProgram( long source, long destination );

// instead of...

bool copyProgram( lond destination );

wouldn't this be more useful and forward-thinking?

and what about process() (the accumulating version)? i know the potential performance gains, if the host actually uses it. but do they? does any host nowadays (besides Cubase)?

== chunk

[Borogove]

Obviously the VST spec just implements the things Steinberg needed, and were done in the way that was simplest for their host implementation rather than a way that was generally useful.

It's depressing, really. Every couple of days at work I have to have someone review my code changes line-by-line before I check in, and they have no qualms about saying "it would be better in the long run if you did it this way," and they're generally right. Any of my peers could have written a better API after a two-margarita lunch.

That said, I imagine that process()/processReplacing() is used by a lot of hosts. Personally I would have made it one API with an additional bool parameter saying whether to = or +=.

[thumb]

interesting post Mr. chunk. curious to see how this develops. I wondered these things myself while exploring the SDK.

[steveholt]

I would also add "will ALL hosts implement this callback". If the answer is no and there is a workaround, why not workaround every time and ignore the callback?

audioMasterGetDirectory would be an example.

Steve

[Zynewave]

@citizenchunk: I'll be happy to supply information on how Podium uses the VST spec.

do hosts actually implement "copyProgram()"?

Podium does not call the copyProgram().

and what about process() (the accumulating version)? i know the potential performance gains, if the host actually uses it. but do they? does any host nowadays (besides Cubase)?

All hosts/plugins should support the process() call. It is the processReplacing() that is optional and which can give performance gains in the host. Podium calls processReplacing() if supported by the plugin (the plugin sets the effFlagsCanReplacing). This eliminates the buffer clearing that is otherwise required before each process() call.

Frits

[citizenchunk]

All hosts/plugins should support the process() call. It is the processReplacing() that is optional and which can give performance gains in the host. Podium calls processReplacing() if supported by the plugin (the plugin sets the effFlagsCanReplacing). This eliminates the buffer clearing that is otherwise required before each process() call.

interesting. i never thought of it from that perspective. i just assume that all modern hosts treat plugins as inserts now, meaning, the buffer MUST be replaced with something. but i see your point.

== chunk

[Doogle]

Don't alot (some?) hosts, even when they're calling processReplacing(), still clear the buffer anyway. Something to do with supporting buggy plugins that peform an accumulative action even when they're meant to be overwriting the buffer contents.
Can anyone confirm this?

Doogle

[Zynewave]

Don't alot (some?) hosts, even when they're calling processReplacing(), still clear the buffer anyway. Something to do with supporting buggy plugins that peform an accumulative action even when they're meant to be overwriting the buffer contents.
Can anyone confirm this?

Indeed, some older plugins had this problem. Steinberg solved it in later Cubase versions with an option somewhere in the preferences dialogs that could skip the processReplacing() optimization and always use process(). In Podium I solved it by calling the processReplacing() offline on any plugins claiming they support it, and check the output is not accumulated. No need for a stupid option in the preferences then.

[plastique]

do hosts actually implement "copyProgram()"?

even cubase/nuendo etc. don't seem to use copyProgram() :

http://www.steinberg.net/steinberg/ygra ... pport.html
(a bit outdated by now , but anyway ..)

[deltasp]

It's a good topic. The one thing mising from a lot of plugins is support for saving parameters via offlineread and offlinewrite. For example, eXT could benefit from this feature by saving the eXT setup in the hosts file.

But what hosts actually support the offline interface?

[Angus_FX]

I would also add "will ALL hosts implement this callback". If the answer is no and there is a workaround, why not workaround every time and ignore the callback?

audioMasterGetDirectory would be an example.

Never mind that, with Mac OS FSSpecs, there are several different ways of specifying a directory, and nowhere in the VST docs does it say which one the host should return.. in fact, same on Windows to some extent (unix-style or Win32-style seperators, and terminating / or no?)

[Borogove]

Something to do with supporting buggy plugins that peform an accumulative action even when they're meant to be overwriting the buffer contents.

God, I can't believe anyone writes hosts to be tolerant of ill-behaved plugins. The host should f**king *delete* a plugin that confuses process()/processReplacing().

[Kim Lajoie]

Something to do with supporting buggy plugins that peform an accumulative action even when they're meant to be overwriting the buffer contents.

God, I can't believe anyone writes hosts to be tolerant of ill-behaved plugins. The host should f**king *delete* a plugin that confuses process()/processReplacing().

"xxx plugin is not fully VST-compliant, and has been removed from your system to avoid possible harm. We apologise for any inconvenience."

Forever,




Kim.

[Borogove]

"xxx plugin is not fully VST-compliant, and has been removed from your system to avoid possible harm. We apologise for any inconvenience."

"In addition, a contract has been taken out on the life of the developer responsible."

[GlennO]

Any of my peers could have written a better API after a two-margarita lunch.

I have to admit to the same feelings myself about VST from time to time. But, it meets the big three criteria for success in my book: it's simple, is supported by an amazing number of hosts and plugins, and has evolved to meet many needs that were not known at the time of its original version.

In any case, whether it is good or bad is necessarily a relative question, so all you have to do is compare it to Audio Units (the next host which can properly implement multiple outputs will be the first one) and RTAS (the second RTAS host, DP/DAE, still doesn't work right), both of which fail on at least 2 of the above criteria, to conclude it is good .

- Glenn