Don't know if anyone noticed... VST3

[Concretefx]

Ohh , if I had only read that Spolsky article a long time ago , I would have saved myself a lot of work

And VST3 , so far ughh with a meh attached.

[arakula]

What I really, truly, personally hate about this VST 3 SDK is that it isn't compatible with Visual Studio 6 any more.

Please tell me this isn't true.

Wish I could...

I tried, but couldn't get the aGain example compiled. The vstvalidator sample was possible, with some simple command line things such as /D "__wchar_t unsigned short", but the goddamn f***ing ivory-tower egghead multiple inheritance stuff renders the aGain example uncompilable.

Here's the set of things that don't work out:

Code: Select all

#define QUERY_INTERFACE(iid, obj, InterfaceIID, InterfaceName) \
if (memcmp (iid, InterfaceIID, 16) == 0)                       \
{                                                              \
	addRef ();                                                 \
	*obj = (InterfaceName*)this;                               \
	return kResultOk;                                          \
}

class IPluginBase: public FUnknown
{
...
};

class IConnectionPoint: public FUnknown
{
...
};

class ComponentBase: public IPluginBase,
	                 public IConnectionPoint
{
...
}

...
    QUERY_INTERFACE (iid, obj, FUnknown::iid, IPluginBase)

leads to the following errors (amongst others):

Code: Select all

<base>\public.sdk\source\vst\vstcomponentbase.cpp(65) : error C2385: 'ComponentBase::FUnknown' is ambiguous
<base>\public.sdk\source\vst\vstcomponentbase.cpp(65) : warning C4385: could be the 'FUnknown' in base 'IPluginBase' of class 'ComponentBase'
<base>\public.sdk\source\vst\vstcomponentbase.cpp(65) : warning C4385: or the 'FUnknown' in base 'IConnectionPoint' of class 'ComponentBase'

Ha. Ha.

[arakula]

Aleksy, wtf, it's called the same here! Didn't expect that. What is the Russian word for it? The Swedish is "björntjänst", where björn of course is bear and tjänst is service.

In German it's "Bärendienst", BTW...

[Aleksey Vaneev]

Ha. Ha.

Ooohhh, yeahhh! So, they stomped into that piece of shit. What they are thinking about when using multiple inheritance in C++? It should be used with extreme care, in rare occasions.

[aMUSEd]

Very good. How I wish Jorgen had read this before rewriting Energy XT (or NI when they brought out KORE 2). If it ain't broke....

While I wholeheartedly agree with the article, I don't think it's completely fair to apply that view upon what Jorgen did. As it would seem to me, it wasn't mainly a complete rewrite, it was mainly a change of programming language, and there's a huge difference in the reasoning behind it.

yes you're right. I suppose I'm more bothered by the fact that in both cases significant usability features found in the original versions have been left out of the rewrite.

[pavouk100]

Ha. Ha.

Ooohhh, yeahhh! So, they stomped into that piece of shit. What they are thinking about when using multiple inheritance in C++? It should be used with extreme care, in rare occasions.

Multiple inheritance of implementation classes is really a can of worms. But the example above shows only multiple interface inheritance, which is considered OK and safe.
[/b]

[haydxn]

Ha. Ha.

Ooohhh, yeahhh! So, they stomped into that piece of shit. What they are thinking about when using multiple inheritance in C++? It should be used with extreme care, in rare occasions.

Multiple inheritance of implementation classes is really a can of worms. But the example above shows only multiple interface inheritance, which is considered OK and safe.
[/b]

Multiple inheritance is certainly not something to be afraid of or dismiss. There are i'm sure times when it can be dangerous, but generally there's nothing wrong with using multiple inheritance at all, and some libraries are better off for using it.

[Aleksey Vaneev]

Multiple inheritance of implementation classes is really a can of worms. But the example above shows only multiple interface inheritance, which is considered OK and safe.

But it does not compile under the said compiler. So, it's not a talk about pure virtual functions (there are no 'interfaces' in C++ - do not mix terminology please). But in either case 'two way' inheritance (like the one shown) - be it a class with pure virtual functions only or not - is wrong, because in C++, each class has default constructor, copy constructor, operator= and destructor: these elements can't be defined 'pure virtual'.

[dasdeck]

what about a new "VST" API constisting of two basic classes.
a "Host" class, wich is to be implememtned by the host,
and a "Plug_in" class wich is implemented by the plug in,
wich interact with each other.
i think it should be a modern 100% object oriented API.
like juce (ok, juce is a framework , but i mean the java alike imho very clean coding style).
i would prefer a object oriented well structured API
(with maybe some custom types (String, File) thrown in (so it would rather be a little SDK)) over a high speed bare bone C API these days.
Dont get me wrong. the API i think of is not bound to dictate coding style or architecture of the plugin in or host at all (or at least not too much). just code your host or plug in with some simple principles in mind, throw in an instance or iherit form the API Plug_in or Host class, implement some virtual methods, done.

maybe the Host class could than manage order of method calling, so there are no confusions when wich mehtod gets called by the host, couse every host the implements Host class would do it the same way.while im thinking of its, it may be better to stay with a simple FX-Host API and offer an additional plug-in SDK, wich can do a lot the plug in loading etc stuff,and provides a standart way things are done to avoid communication erreors.

i'm just thinking loud here. my main point is the two classes approach, but it may it may be a bad idea either.

peace

D3CK

[quikquak]

I haven't looked at it yet - too busy doing DSP and GUI coding.
How do they propose to include GUI into this seemingly bloated (jobs for the boys) dev kit?

Dave H.

[Aleksey Vaneev]

I haven't looked at it yet - too busy doing DSP and GUI coding.
How do they propose to include GUI into this seemingly bloated (jobs for the boys) dev kit?

You have to define an editor class and a controller for this class. DSP part embeds controller itself. It's not that hard - shown in AGain. What bothers me more is backwards compatibility and GUIDs which are pure evil IMO (almost like a sign of a beast - designed to enumerate all things in this universe). I also dislike "version.h" files much because I store version information in my own XML structures - so, I may need to patch the SDK (unsure on that, though).

[Aleksey Vaneev]

what about a new "VST" API constisting of two basic classes. ...

It's not a problem to design a decent API considering VST2.4 is almost decent. What's more problematic is to get it implemented by major pro audio vendors in their hosts. I think we should start collecting 'agreements of principle' from them first. After we get consent from ten major host developers we may start working on an API. I believe the main idea is to create a 'similar/competing to VST' API that is licensed freely under something like LGPL (but it's better to create own license, just not to make commercial vendors afraid of association with GPL).

As for the plug-in developers, I'm in for sure, especially if a couple of my own ideas get into the API.

Please, no CStrings and similar things in this API, it should be plain C++ with standard types.

[Angus_FX]

Actually, any API needs to be 'C' not C++, as the C++ ABI is not guaranteed between compilers and compiler versions.

Aleksey - drop me a line on email (angus _at_ fxpansion _dot_ com)

[Aleksey Vaneev]

Actually, any API needs to be 'C' not C++, as the C++ ABI is not guaranteed between compilers and compiler versions.

Aleksey - drop me a line on email (angus _at_ fxpansion _dot_ com)

Sure, it should be "extern "C"", but it's an inner part of an API. The outer part should be C++, like in VST.

[asseca]

Actually, any API needs to be 'C' not C++, as the C++ ABI is not guaranteed between compilers and compiler versions.

Agreed, the API should be purely structure based, leaving it open to use it with any compiler / OOP implementation ...