How do Mac and PC VST plugin formats differ?
-
- KVRer
- 4 posts since 30 Dec, 2003 from Minneapolis, Minnesota / Grinnell, Iowa
Hey folks,
I've been using VST effects on my PC for years now, but recently bought a macbook. I've done google and KVR searches for the answer to this, but haven't found much of an answer yet. I'm wondering: if VST is a "universal" format, why are there both Mac and PC versions of VST plugins? (I mean, obviously they are different machines with different OSs, but how much of a barrier is that really?) I'm especially curious now that Macs use intel chips. It *seems* at least that it wouldn't be out of the question to get "PC" vst plugins working on a Mac platform--or at least that mac apps would be able to read pc .dll type plugins.
Thanks!
I've been using VST effects on my PC for years now, but recently bought a macbook. I've done google and KVR searches for the answer to this, but haven't found much of an answer yet. I'm wondering: if VST is a "universal" format, why are there both Mac and PC versions of VST plugins? (I mean, obviously they are different machines with different OSs, but how much of a barrier is that really?) I'm especially curious now that Macs use intel chips. It *seems* at least that it wouldn't be out of the question to get "PC" vst plugins working on a Mac platform--or at least that mac apps would be able to read pc .dll type plugins.
Thanks!
-
- KVRian
- 1263 posts since 15 Jun, 2004 from hamburg
i can only answer thisNoAlternative wrote:I'm wondering: if VST is a "universal" format, why are there both Mac and PC versions of VST plugins?
the vst sdk is c++ cource code and something like a template. c++ itself is the high-level programming language which gets compiled to system-near machine code. as pc and mac obviously differ when it comes to systems, there has to be one compiled version for pc and one for mac out of the (almost?) same source-code.
but i'm no dsp-programmer, so anyone else will fill in the gaps.
-
Alex@ProgressAudio Alex@ProgressAudio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=58042
- KVRist
- 338 posts since 15 Feb, 2005 from London, UK
Operating systems provide programs with a set of tools for doing standard things like displaying GUI's, accessing files etc. The tools on MacOS and Windows are different and incompatible, and this is why a Windows VST plug-in won't run on the Mac, even with an Intel processor.
You would need some sort of Windows emulation in order to provide the plug-in with all the tools it normally gets from Windows. This would be very difficult to create, and totally not worth it, which is why we stick to creating separate Windows and MacOS versions.
Although Mac and Pc hardware has become very similar, Windows and MacOS software is still as different and incompatible as ever I'm afraid!
Hope that helps,
Alex
You would need some sort of Windows emulation in order to provide the plug-in with all the tools it normally gets from Windows. This would be very difficult to create, and totally not worth it, which is why we stick to creating separate Windows and MacOS versions.
Although Mac and Pc hardware has become very similar, Windows and MacOS software is still as different and incompatible as ever I'm afraid!
Hope that helps,
Alex
-
- KVRist
- 174 posts since 25 Apr, 2006
VST Plugins, regardless of platform, take the form of a shared library that can be loaded by an application. This shared library (in the case of Windows, a DLL) has to have machine code of the type required to run on that platform.
As you may know, C/C++ code gets compiled to machine code that can run on a particular platform. So, for PC vs. Mac VST plugins, the machine code is different, as are the operating system API calls made by the plugin. For example, to memory-map a file a Mac VST plugin would call mmap(), whereas the PC flavor would have to use the CreateFileMapping() (and other) WIN32 API's.
Long story short - PC vs. Mac VST plugins are really very different and can only share metadata (graphics, XML stuff, config files, etc.)
As you may know, C/C++ code gets compiled to machine code that can run on a particular platform. So, for PC vs. Mac VST plugins, the machine code is different, as are the operating system API calls made by the plugin. For example, to memory-map a file a Mac VST plugin would call mmap(), whereas the PC flavor would have to use the CreateFileMapping() (and other) WIN32 API's.
Long story short - PC vs. Mac VST plugins are really very different and can only share metadata (graphics, XML stuff, config files, etc.)
- KVRAF
- 12615 posts since 7 Dec, 2004
since we already have the required emulation and wrapper libraries in linux, x86 macs can also already run windows vst dll files without modification. just follow the instructions available online. you'll need all the compatible software, though.
-
- KVRer
- Topic Starter
- 4 posts since 30 Dec, 2003 from Minneapolis, Minnesota / Grinnell, Iowa
thanks for the well-informed answers. Having switched to a MacBook, obviously there are a lot of plugins I use on the Windows side that I'd like to quickly and easily re-use (thankfully some of my favs like destroyfx are free and come in both flavors...nice to have those available still.) Pipe-dreaming aside, aciddose's idea was the kind of thing I was wondering could be possible. I mean, if Parallels can emulate windows natively on an intel mac, why not wrap the pc vst plugins in that kind of emulation as well? Obviously I'm not a coder, so I really don't go much beyond the purely theoretical/conceptual level of understanding here...but assuming you have a wrapper that could understand the windows libraries (or vice versa), would it theoretically be possible?
-
- KVRer
- Topic Starter
- 4 posts since 30 Dec, 2003 from Minneapolis, Minnesota / Grinnell, Iowa
Bump, just because I'd like to see what others have to say about aciddose's idea.
- KVRAF
- 9600 posts since 17 Sep, 2002 from Gothenburg Sweden
Parallels does'nt emulate Windows.It is Windows running at the same time as OSX (or Linux or whatever).
-
- KVRAF
- 2058 posts since 23 Sep, 2004 from Canada
You'll want Universal Binary VST's or AU's for your Macbook though if you want optimal host performance I might add.
- KVRAF
- 12615 posts since 7 Dec, 2004
i was NOT suggesting emulation. i said if you have a x86 based mac, you can run native x86 software. there are wrappers available for the windows systems (gdi, etc), you should have heard of 'wine'.
there are wine/vst->jack and other types of wrappers available, so all you need to run windows vst dlls natively will be wine and a host capable of using one of the available wrappers.
macos is already just a flavor of bsd with some custom software running on top. you do not need to modify any code to get it to run between linux/bsd on x86 and macos on x86.
there are wine/vst->jack and other types of wrappers available, so all you need to run windows vst dlls natively will be wine and a host capable of using one of the available wrappers.
macos is already just a flavor of bsd with some custom software running on top. you do not need to modify any code to get it to run between linux/bsd on x86 and macos on x86.
-
- KVRer
- Topic Starter
- 4 posts since 30 Dec, 2003 from Minneapolis, Minnesota / Grinnell, Iowa
I've been trying to research this stuff on my own--There's a program that lets GNU/Linux users use windows x86 dll VSTs with seemingly great results. Apparently the libwine component of wine is what make it possible...As for OSX there's Darwine, which is wine for osx, and a an osx version of jack as well, but I'm at a loss to figure out how to mimic the Linux process on a mac. There's got to be a way to make this happen on an intel-based mac...It just seems so conceptually plausible.
Still trying to learn more about this stuff...
Still trying to learn more about this stuff...
- KVRAF
- 12615 posts since 7 Dec, 2004
basically what you need is
1) wine which is configured exactly as in the official distribution
2) jack
3) jack vst wrapper plugin
4) host capable of using jack plugins
the only thing that might be a problem would be darwine in this case. if darwine isnt configured the same (same paths, same options, same behaviours) the jack vst wrapper might not work correctly with it.
it works like:
host -> jack -> jack vst wrapper -> wine -> wine vst wrapper -> vst plugin
the host uses jack, jack loads up the vst wrapper plugin. the vst wrapper plugin executes a special host using wine which can communicate externally with the jack plugin. the host in wine loads the windows vst plugin and starts sending the communications between the vst plugin and the jack wrapper plugin.
i'm sure you can get it to work on an x86 mac, you might have to do some coding yourself though if you have to reset some modified behaviours in the mac versions.
1) wine which is configured exactly as in the official distribution
2) jack
3) jack vst wrapper plugin
4) host capable of using jack plugins
the only thing that might be a problem would be darwine in this case. if darwine isnt configured the same (same paths, same options, same behaviours) the jack vst wrapper might not work correctly with it.
it works like:
host -> jack -> jack vst wrapper -> wine -> wine vst wrapper -> vst plugin
the host uses jack, jack loads up the vst wrapper plugin. the vst wrapper plugin executes a special host using wine which can communicate externally with the jack plugin. the host in wine loads the windows vst plugin and starts sending the communications between the vst plugin and the jack wrapper plugin.
i'm sure you can get it to work on an x86 mac, you might have to do some coding yourself though if you have to reset some modified behaviours in the mac versions.
