VST plugins on OS X (Apple)

[AlexanderOMara]

VeSTige is not present on the Mac builds. It would be great if we could use VST plugins on the Mac builds in the same way as on Linux builds, through Wine. Currently the only way to use VST plugins in LMMS on Mac is to run the whole LMMS in Wine (with some symlink trickery to get the plugin paths to resolve properly).

[tresf]

Disclaimer
Please note that our Apple Build is still unofficial because it is buggy and incomplete. :) That said, please do use it and submit bugs reports as you find them.

Edit: Our apple builds have stabilized quite a bit since originally writing this.

VST on Mac

Edit: Please see @rhunter's work below. #698 (comment)

There's an open issue with the winegcc compiler on OSX. If you can hunt someone down with experience, we'd be happy to resolve this. It may need to be fixed by the Clang/llvm team. For that reason, we intentionally disable Windows VST support in our CMakeList.txt file.

At this time, I believe this issue is out of our hands as we did not write Clang. If there is a change to the winegcc command that corrects this we'll happily add it but currently when we build it tries asking for MVC headers (Microsoft only stuff) that would never be on an Apple computer. This suggests clang doesn't have proper winegcc support, however this may also be due to a missing #ifdef or a header that we use. Any and all help is appreciated.

Edit: I'll leave this open as we should definitely track it. Here's the research so far:

http://portingteam.com/topic/10062-winegcc-clang-51/page__pid__101465

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130826/087093.html

Edit: Link updated: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20130826/087031.html

-Tres

[rhunter]

I managed to get Wine-based VST support compiled on MacOS X. It still doesn't run properly, but first things first :-)

In summary

The most important workarounds are additional wineg++ parameters: -U _WIN32 -D USE_WS_PREFIX.

Deep dive

Mac OS X 10.9 "Mavericks", the default C++ compiler (clang) uses the C++ standard library called libc++ by default.

wineg++ (1.6.2) and libc++ (1.0) are not friends right now.

• wineg++ defines _WIN32.
• libc++ uses _WIN32 and some other #ifdef checks to decide whether the Microsoft's Visual C Runtime (MSVCRT) is available.

The problem is that we want wineg++ to build with _WIN32 and without MSVCRT. There's a special case in the libc++ code for MINGW32.

I expect, although I haven't confirmed, that the exact same problem occurs on Linux when using the clang compiler and its default options.

Possible fixes and workarounds

• Fix libc++ so that _WIN32 works for wineg++ (external project change, but probably the right answer in the long term)
• Change wineg++ to not define _WIN32 (external project change, and probably wrong: there's probably a reason that it defines _WIN32 in the first place)
• Work around the problem by undefining _WIN32 when we run wineg++ (LMMS change, a little unsightly and perhaps confusing)
• Explicitly use a different C++ standard library (GNU's libstdc++, the same one that GCC uses and that clang used to use) is still available (LMMS change, may stop working if Apple stop distributing it).

Small test case

You can replicate the problem in a small, self-contained manner without the LMMS code base using the following code:

// example.cpp: demonstrates wineg++ vs libc++ problem
#include <windows.h>
#include <vector>

int main(int argc, char **argv) {
  return 0;
}

$ wineg++ example.cpp
...
.../include/c++/v1/limits:115:10: fatal error:
      'support/win32/limits_win32.h' file not found
#include "support/win32/limits_win32.h"
         ^
2 warnings and 1 error generated.
winegcc: /usr/bin/clang++ failed
$ wineg++ example.cpp -U _WIN32
...
/usr/include/sys/_select.h:39:6: error: conflicting types for 'select'
...
1 error generated.
winegcc: /usr/bin/clang++ failed
$ wineg++ example.cpp -U _WIN32 -D USE_WS_PREFIX
...
2 warnings generated.
$ wineg++ example.cpp -D USE_WS_PREFIX -stdlib=libstdc++

The warnings are from Wine's macro-based min/max definitions (coming from windows.h), which libc++ detects and undefines.

Other things

The "libc++ vs wineg++" problem is the main issue. There are some additional build and code issues that we'll need to address before Wine-based VST support works (or even tries to build) on non-Linux platforms. I've made some headway with some of that locally, although nothing ready to share just yet.

(By the way, one of @tresf 's "clues" above has since become a dead link. I found a replacement here:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20130826/087031.html )

[tresf]

[pipermail link] has since become a dead link

Fixed, thanks.

The "libc++ vs wineg++" problem is the main issue

Thanks for this research. I've made some comments on the cmake stuff in your PR.

In regards to Possible fixes and workarounds:

• I agree with bullet #1 (upstream is always ideal), although...
• I like bullet #3 (A.K.A. "unsightly and confusing") as it may fix this right away and wouldn't be the first hack we've had to introduce so this would be OK so as long as we comment it well in our source.
• Not sure about bullet #4 (change standard library) for the reasons you've mentioned... might be worth investigating but the risk of leaving the code to fall victim to Apple pulling the plug makes #1 and #3 our best options IMO.

The most important workarounds are additional wineg++ parameters: -U _WIN32 -D USE_WS_PREFIX

👍 Since there seems to be such little documentation surrounding wineg++ on the internet -- and even less when working on Mac, many others could benefit from putting some code-comment explanations around these.

This is tremendous work, thanks for the hard work so far on this.

[PhysSong]

BTW, Is it still worth supporting Windows VST on macOS?

[tresf]

BTW, Is it still worth supporting Windows VST on macOS?

Not officially, no. I guess we could close and offer to reopen if someone has more to share?

[tresf]

BTW, Is it still worth supporting Windows VST on macOS?

Update... possibly yes. WineHQ offers fantastic support for Wine now, even on Apple Silicon. At time of writing this, winegcc and winebuild need to be compiled from source. I'm not sure how well it will work, but it should be possible and may be a good idea now that Wine is so capable.