Specific technical questions about VST3, and info for users

[z15]

I agree that for ultimate low-latency and low-cpu overhead, PCI is the best way to go.
But then of course, sticking sensitive analog circuitry inside an electrically noisy computer case is never going to give the best noise performance!

OTOH, many manufacturers use external breakout boxes for the converters and then transfer the digital data to the PCI interface. I guess that would be the "you can have your cake and eat it too" -solution

[jpommier]

The thing is, writing the interfaces in C is actually the only proper way to ensure binary compatibility. I really do not understand what the Steinberg folks had in mind with this SDK....

I guess that also means that it will be no longer possible to use mingw to build plugins on windows since g++ is not using the msvc abi...

[Aleksey Vaneev]

I guess that also means that it will be no longer possible to use mingw to build plugins on windows since g++ is not using the msvc abi...

Yep, that's true it seems if you are using an old mingw built around GCC 3.4. However, MinGW.org is making some steps to get GCC 4 working. But they do not have a complete setup yet for that, but you can at least hope they get GCC 4 working (together with 64-bit compiler) sooner than later.

[pavouk100]

I guess that also means that it will be no longer possible to use mingw to build plugins on windows since g++ is not using the msvc abi...

Yep, that's true it seems if you are using an old mingw built around GCC 3.4. However, MinGW.org is making some steps to get GCC 4 working. But they do not have a complete setup yet for that, but you can at least hope they get GCC 4 working (together with 64-bit compiler) sooner than later.

I've successfully built VST3 'again' sample using stable stock mingw (GCC3.4). Only a few (cca 3 if I remember) single line no-brain-needed patches in sdk headers were needed. The most complicated stuff was getting gdi+ to work with mingw, but its related to vstgui.sf, not to core vst3. I've no C4/N4, but plugin seemed to work well in vst3sdk plugin test host.

Side note: I personally don't understand this whole VST3/C++ ABI hystery; the only thing from C++ ABI which matters in VST3 world is binary layout of classes with virtual tables and multiple inheritance of pure virtual classes. This is nothing complicated and pretty stable in GCC world for pretty long time. C++ ABI is easy in this area. Troubles come with exceptions, RTTI etc., but none of these 'advanced C++' things are used in VST3 interface. The same can be said for c++ stdlib; its ABI does not matter, because AFAIK nothing from c++ stdlib is used in VST3 interface.

[Aleksey Vaneev]

Side note: I personally don't understand this whole VST3/C++ ABI hystery;

You've caught only a single element of this 'hystery'. There are more questions in relation to VST3 than that exist.

[jpommier]

I've successfully built VST3 'again' sample using stable stock mingw (GCC3.4). Only a few (cca 3 if I remember) single line no-brain-needed patches in sdk headers were needed. The most complicated stuff was getting gdi+ to work with mingw, but its related to vstgui.sf, not to core vst3. I've no C4/N4, but plugin seemed to work well in vst3sdk plugin test host.

How is that possible, did you also build the test host with mingw ? I did not do any test, but as far as I know, the name mangling of mingw is not compatible at all with the msvc one, so mixing a msvc host and a mingw plugin should fail, it is not only a matter of vtables and exceptions. For example, it is stated here:

http://lists-archives.org/mingw-users/0 ... -msvc.html

[Angus_FX]

nixim - OK, I think I understand.. so the granularity of interrupts/transfers on the USB bus is fixed at 1ms intervals, and the problem comes about because audio sample rates don't fit neatly in to those intervals. If you wanted to supply fixed size buffers, you'd basically have to add an extra millisecond of latency, and occasionally not use (or "transfer 0 samples") on a specific timing window?

[pavouk100]

I've successfully built VST3 'again' sample using stable stock mingw (GCC3.4). Only a few (cca 3 if I remember) single line no-brain-needed patches in sdk headers were needed. The most complicated stuff was getting gdi+ to work with mingw, but its related to vstgui.sf, not to core vst3. I've no C4/N4, but plugin seemed to work well in vst3sdk plugin test host.

How is that possible, did you also build the test host with mingw ? I did not do any test, but as far as I know, the name mangling of mingw is not compatible at all with the msvc one, so mixing a msvc host and a mingw plugin should fail, it is not only a matter of vtables and exceptions. For example, it is stated here:

http://lists-archives.org/mingw-users/0 ... -msvc.html

I used the original host, of course, no rebuild is possible because there are no sources for the host . Different name mangling does not matter, because VST3 interface specifies only one named entry point - GetPluginFactory, and it is C function (therefore unmangled), moreover loaded dynamically by the host. The mangling scheme used inside the plugin in its implementation is completely irrelevant, it is not visible to the host.

[pavouk100]

Side note: I personally don't understand this whole VST3/C++ ABI hystery;

You've caught only a single element of this 'hystery'. There are more questions in relation to VST3 than that exist.

Sure, I'm sorry, my bad wording. There are many points raised against VST3, and I consider most of them valid (backward incompatibility, underspecification, missing MIDI parts etc). I just wanted to say that one of the points - building plugin interface on C++ pure abstract classes - IMHO does not cause that big compiler-compatibility issues as it seems from reading KvR threads on this topic.

In case that someone felt offended, I apologize for using the word 'hystery', it is most probably too strong for this context.

[jpommier]

Different name mangling does not matter, because VST3 interface specifies only one named entry point - GetPluginFactory, and it is C function (therefore unmangled), moreover loaded dynamically by the host.

Aaaah great, I understand now ! thanks for the clarification

[nixim]

nixim - OK, I think I understand.. so the granularity of interrupts/transfers on the USB bus is fixed at 1ms intervals, and the problem comes about because audio sample rates don't fit neatly in to those intervals. If you wanted to supply fixed size buffers, you'd basically have to add an extra millisecond of latency, and occasionally not use (or "transfer 0 samples") on a specific timing window?

Basically, yes.

Although it's not just that - with USB, the buffer size changes depending on what sample rate you select, something which is problematic with ASIO since most hosts assume the buffer size will remain the same for different sample rates. Anyway sorry this is getting a bit off-topic!

There are probably other (more relevant) arguments for not dictating that sequencers/hosts use fixed-size buffers. This was just the one that springs to my mind first since it affects me

[Angus_FX]

There are, equally, arguments for using fixed buffers.. don't want to start a religious war here, just to point out that DSP accelerator cards, and certain classes of algorithm, suffer if the buffer size isn't fixed. Also, it makes life a bunch more complicated in a delay-compensated audio engine where a lot of the plugs have "1 buffer" of inherent latency.

Good to have some understanding of the technical issues on both sides though, thanks!

Regarding sample rate - from a plug-in point of view, changing sample rate usually requires a stream stop/start and buffer flush anyway, so they don't really care if the buffer size changes as well at that point.

[Kitchen Sink]

From a user point of view, I'd rather have the host's buffer size dictated by the audio hardware even if it means a dynamically changing buffer size, and not the other way around so that audio drivers (or whatever) have to go through the hoops to create an illusion of a fixed buffer size, if it really isn't fixed. If USB audio runs at 1 ms per buffer, then so be it. ASIO should cater for it! Though I'm using firewire audio at the moment. I'm just so fed up with this latency nonsense. PCs are powerful beyond imagination, but timing is total crap. MIDI timing, audio latency, it's all just total crap. The whole "architecture" is dictated by what is the cheapest possible system put together from best-selling standard bulk components that are not meant for any particular task. Steinberg's ASIO and VST have managed to do an impossibly difficult thing, enabling wide interoperability and at least SOME KIND OF USABILITY on that general-purpose bulk crap platform - AND even Mac and PC at the same time. But thanks to them we now have this huge ecosystem of audio and music software. And KVR.

[jwatte]

The whole "architecture" is dictated by what is the cheapest possible system put together from best-selling standard bulk components that are not meant for any particular task.

Don't forget that the whole thing also has to be tested only until the point where it appears to work when it's on a store shelf. Truly a race to the bottom.

On the other hand, a kick-ass PC costs $1,000, not $100,000 like a kick-ass car...

[hibrasil]

Just going to resurrect this 10 years old thread.

I'm interested...

- How do you all feel about VST3 these days?
- Has anyone seen a properly distributed VST3 in the wild (i.e. with UI and DSP running across a memory gap or on different machines entirely)?

Cheers

Oli