Login / Register 0 items | $0.00 New @ KVR
z15
KVRian
 
757 posts since 21 Mar, 2002, from fi

Postby z15; Wed Jan 23, 2008 1:18 am

nixim wrote: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 :wink:
never stop loving music.
jpommier
KVRer
 
16 posts since 30 Apr, 2005

Postby jpommier; Wed Jan 23, 2008 1:22 am

Blue Cat Audio wrote: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...
User avatar
Aleksey Vaneev
KVRAF
 
3486 posts since 7 Sep, 2002

Postby Aleksey Vaneev; Wed Jan 23, 2008 1:40 am

jpommier wrote: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.
Image
pavouk100
KVRer
 
14 posts since 2 May, 2007

Postby pavouk100; Wed Jan 23, 2008 2:18 am

Aleksey Vaneev wrote:
jpommier wrote: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.
User avatar
Aleksey Vaneev
KVRAF
 
3486 posts since 7 Sep, 2002

Postby Aleksey Vaneev; Wed Jan 23, 2008 2:45 am

pavouk100 wrote: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.
Image
jpommier
KVRer
 
16 posts since 30 Apr, 2005

Postby jpommier; Wed Jan 23, 2008 2:53 am

pavouk100 wrote: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
KVRAF
 
4604 posts since 17 Jul, 2002, from London, UK

Postby Angus_FX; Wed Jan 23, 2008 3:37 am

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?
ROLI | FXpansion
FX Twitter | FX YouTube
pavouk100
KVRer
 
14 posts since 2 May, 2007

Postby pavouk100; Wed Jan 23, 2008 4:58 am

jpommier wrote:
pavouk100 wrote: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 :hihi:. 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
KVRer
 
14 posts since 2 May, 2007

Postby pavouk100; Wed Jan 23, 2008 5:06 am

Aleksey Vaneev wrote:
pavouk100 wrote: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. :wink:
jpommier
KVRer
 
16 posts since 30 Apr, 2005

Postby jpommier; Wed Jan 23, 2008 5:14 am

pavouk100 wrote: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
KVRer
 
5 posts since 8 Nov, 2005, from London

Postby nixim; Wed Jan 23, 2008 6:01 am

Angus_FX wrote: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
KVRAF
 
4604 posts since 17 Jul, 2002, from London, UK

Postby Angus_FX; Wed Jan 23, 2008 6:16 am

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.
ROLI | FXpansion
FX Twitter | FX YouTube
Kitchen Sink
KVRist
 
110 posts since 15 Sep, 2005

Postby Kitchen Sink; Wed Jan 23, 2008 6:40 am

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. :D
jwatte
KVRist
 
280 posts since 12 Jan, 2008

Postby jwatte; Wed Jan 23, 2008 9:35 pm

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...
Apparently, there are some legal, mostly non-controverisal subjects you can't talk about on KVR, or even mention in your sig. Unfortunately, the guidelines don't actually talk about them, so the only way to find out is trial and error.
hibrasil
KVRian
 
764 posts since 23 Jun, 2002, from Huddersfield, UK

Postby hibrasil; Tue Apr 17, 2018 5:39 am Re: Specific technical questions about VST3, and info for users

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
My Website | WDL-OL | Web Audio Modules - WAMs | Oli Larkin Plugin's Facebook
Available for Audio Dev tuition via Skype (IPlug/JUCE/C++)
PreviousNext

Moderator: Moderators (Main)

Return to DSP and Plug-in Development