Win-to-OSX VST wrapper/adapter

[mustgroove]

Thanks for the posts Angus Interesting that you can already run hosts with WINE, but my ultimate aim is rather to "wrap" Windows VST plugins so that they run (hopefully seemlessly) in a native OS X host, as if they were OS X VST plugins in the first place...

I really hope this is achievable... and am actually willing to throw some money at it to see it developed.

[Angus_FX]

Nothing's impossible, but I'd file that one under "very substantially difficult". It's not achievable without WINE/Crossover or some other Windows library emulation layer (that's what SM Pro Audio are no doubt using); for as long as WINE on OS X is dependent on XWindow, it's just not going to work in-process.

If the people developing the native OS X driver for WINE ever get their act together, that'll bring it somewhat closer, but in the mean time, out-of-process wrappers like retroware's are the closest you're likely to get.

The other issue you run in to is getting compatibility between VSTs and WINE better. Both Receptor and V-Machine are WINE-based, and even after quite a few years, big VSTs seem to require special attention to get them working properly on Receptor. SM Pro Audio are actually in quite a strong position here, because they can take the work they do to make WINE compatible with VSTs on their hardware, and translate that in to the software platform too. Looking forward to their V-Rack which actually has a decently powerful chip in it.

[retroware]

@ retroware - I tip my hat to you, sir - very good work! I looked in to this in some length two years ago, even discussed at some length with the guys from Codeweavers; we really wanted to get it running in-process but that seemed like a step too far (getting WINE working as a client dylib in an arbitrary OS X process is scary hard).

Yeah, I thought about trying to get it to run in process as well and was worried about getting Wine to run in the same address space as complex programs such as Logic and Live. Instead I chickened out and went with the out of process approach.

Are/were you using an "OS X Native" port of WINE (i.e. using Carbon-Cocoa-Quartz for UI services), or a "UNIX Native" (i.e. using X Window System) port? We were trying to use DarWine/Quartz as we felt that X was too demanding and too unMac for most potential users, but DarWine/Quartz was too buggy to be useful.

I was using the X windows version of Wine. I agree not the most user friendly approach but I was just trying to get a proof-of-concept to start.

The out-of-process approach has some advantages actually, as long as the latency/synchronization/IPC penalty isn't too bad and provided it can be made to work reasonably reliably against the variety of host buffering/threading models you'll find out there (esp. when running multiple instances.. from the results I've seen, some of the big DAW vendors employ some seriously warped individuals as audio engine programmers ). It's a similar issue the guys developing outboard accelerators and DSP cards run in to (asynchronous, out-of-process VST processing basically) and the variation in host behaviour is the bane of all those guys' lives.

I'm using unix pipes for low-bandwidth communication and a shared memory region for high-bandwidth communication (the results of the "process" call). This seems to give a pretty good latency results. I'm guessing there are all sort of issues waiting to bite me when trying to do this "for real". Nevertheless, I have been able to host fairly sophisticated VSTs such as dbGlitch from within Live.

I have no problem with open-sourcing it but the code is pretty rough right now and would take a bit of work to get it to the point that I'd feel comfortable starting a project. But, I'd be happy to throw together a tarball and send it on its way to someone who was committed to starting a project with it.

Cheers,
Dave

[Angus_FX]

hmm.. are you using locking objects to synchronize all that? Would be interested to see how it scales with 6 or 8 Windows VSTs in a session.

Cheers,
Angus.

[Dewdman42]

Wow. That is really impressive. I agree that IPC is the way to go instead of trying to get the wine stuff in-process of a major DAW. I would really like to try that out sometime.

I have been running Jamstix with Crossover Games for a while now, it works good, but I have to host it inside the windows version of Reaper (under Wine), and use virtual midi ports to get the midi back and forth, and JackOSX to get the audio. Its kind of a pain to get setup and sometimes the midi is flakey due to bugs in Reaper. I can't imagine I'm using less CPU cycles or getting less latency problems this way then I would with what you have done.

But it basically works. By the way, related to a comment Angus made earlier, its possible to use the wineasio driver under CrossoverGames to have low latency audio under Wine. The wineasio driver basically acts like ASIO on the windows side and connects to JackOSX on the mac side. (there is a linux version too). The OSX version had to be specially coded in order to deal with some unix incompatabilities between darwin and linux, I can't remember what it was right now. But if you google for it, the guy did it has it posted on his website, and it works with slightly older versions of CrossoverGames and Wine. I'm using it with CrossoverGames 7.0.0.

I also run OP-X, Glitch and a few other windows only plugins that way.

Anyway, if you're willing to share, I'm willing to try.

[djanthonyw]

About a year ago I started working on a project to run Windows VSTs in a OS X host. I got to the point were I could wrap a Windows VST dll and load it directly via a OS X host (I was using Ableton at the time). The project was based on the open source dssi-vst project and used Wine as the windows emulation engine. I got the project to a point were all of the audio and GUI processing was working correctly across a range of Vsts. Some things that weren't working included parameter save/restore plus the whole wrapping process needed some streamlining.

It was actually pretty cool to see a windows vst running "natively" on an OS X system. Plus, the added latency/overhead didn't seem that bad. At that point I lost some interest in that the VST I was interested in using became available natively for Mac OS X. But, I'd be more than happy to share the somewhat crufty code with anyone who would like to pick up the ball and run with it.

As mentioned before, is there any chance of making this an open source project? I would love to be able to run z3ta natively inside of an OS X host! Possibly even just offer the latest version that you had built?

[retroware]

I've created a sourceforge project for the Windows to Mac OS X VST adapter. It should be accessible at:

http://sourceforge.net/projects/wacvst

It is still very much a work in progress. But, I've been able to get plugins such as glitch and op-x to operate at a somewhat useable level. Your mileage will definitely vary.

There are two released files - the source distribution for those who want to hack on it and a binary distribution for those who just want to give it a spin. In either case you'll need to download and install Wine.

I'll try and get the svn repository populated this weekend. Let me know if you are serious about doing some development work on it.

Feel free to shoot me any questions or use the sourceforge forums.

Good luck!
Dave

[djanthonyw]

Dave, thank you! I'm going to give this a spin!

[djanthonyw]

It's not showing up for me in Live.

[Bryan J]

Ummm... ok... this is kickass. After a few hours tonight and last night I finally got it working... AND... get this... it's ALMOST working in Logic 8 with Messiah running through WACVST running through "VST to AU Adaptor V2.0"... almost... AND it seems to be very low latency too. It almost feels like Christmas in July =) .

So here's what I was able to find... First of all, the GUI comes up in Logic. When you load Messiah in Logic it will look like the plugin crashes. Suffice it to say, it wasn't actually crashing. Rather, the X11 Window immediately get's pushed back behind all of the open Logic windows just after the VST GUI opens making it look as if it crashed. I only emphasize this because it took me about 25 or 30 minutes to figure this out... lol... When it appeared to crash, I'd just close out of Logic which would close the plugin as well, and I'd never see it. Luckily, at some point I moved the Logic Environment window out of the way to find that Messiah had been clandestinely hiding out in an X11 window.

Now here's the real joy.. When I play keys on Messiah's GUI in Logic, Messiah's audio plays *through Logic's mixer*... just like any other native AU. It so cool. Unfortunately there's no MIDI... as of yet.

I currently suspect that this *might* be due to XQuartz and not necessarily with WACVST. Here's why:

I started testing with Quartz 2.3.3.2, and was not able to use my controller to play MIDI Messiah through either WACVST, or VFX, despite the fact my controller works fine in Logic and other regular Mac apps.

I then tried the shareware application VST Host with WACVST and Messiah. Similar to Logic and VFX was that when I played keys on the GUI I was able to get sound, but when I played keys on my controller I got nothing... BUT... what was interesting is that the MIDI activity indicator on VST Host showed that it *was* receiving the data... It just wasn't passing it on to WACVST, or WACVST wasn't sending it to Messiah.

In essence, it was clear that only those applications using XQuartz (VFX and WACVST) seemed to have a problem with MIDI, so I downgraded to XQuartz 2.2.0.1.

With XQuartz 2.2.0.1 I now have MIDI from my controller successfully playing Messiah running on VFX, and successfully playing Messiah running through WACVST on VST Host. I'm just still not able to get MIDI to work through Logic running Messiah through WACVST running through "VST to AU v2.0".

The MIDI problem could also have to do with the "VST to AU" plugin as well, since VST Host and VFX are now working, but I still think that XQuartz is suspect given the fact that downgrading seemed to fix MIDI on the other two apps.

All this to say, Dave, you rock. Thanks for putting this out there. With a little massaging, I think we'll have Windows VSTs running pretty seamlessly through Logic too. How cool is that?

For anyone trying to get this to work, here are a couple of other tips:

1. Don't try using DarWine. I wasn't really aware there was much of a difference DarWine and regular Wine, but it seems there is, and I was unable to get DarWine to work with WACVST at all. Just use regular Wine.

2. I did my Wine installation using MacPorts. The installation I selected was wine-devel . Be aware that Wine will be installed in /OPT directory by default when you use MacPorts instead of /USR. I wasn't sure how delicate the pathing was in Wine (I assume it is), so I just left it there and changed the path in WACVST to reflect this, which seemed to be fine.

I've only just started playing with this, but so far it looks like this could really work well for those PC only plugins... especially if we can get the installation down to a step-by-step procedure, or maybe a script of some sort. Hopefully I can work on this a little more tomorrow and see if I can get MIDI working through Logic on a VSTi.

Thanks Dave!

-Bryan J

[retroware]

Glad to hear that wacvst is working for someone besides myself. I must say that I'm pretty surprised that it somewhat works in conjunction with the vst to au wrapper.

It would be great if you came up with a step by step guide for using it. I sort of suck when it comes to documentation.

You shouldn't expect midi to work - I never got around to implementing the effProcessEvents opcode. It shouldn't be too hard to add. Hopefully, I'll get some time in the next couple of days to add it in.

[Bryan J]

Sweet... I look forward to checking it out. If this works pretty well (as it might seem) then I'll probably start to make the transition from PC to Mac for real.

I'll try to put to together a streamlined procedure for getting this installed in the next day.

For anyone trying to get WINE going already, I also just found out that there's a new GUI interface called "Porticus" that can be used in place of MacPorts, so it should end up being pretty straight forward without the need for anything on the command line (for better or for worse).

[gustavokch]

Sounds really promising, really looking forward to this.

[retroware]

A new version of wacvst has been uploaded to sourceforge.net:

https://sourceforge.net/projects/wacvst/files/wacvst

This new version should support midi events from the host. Plus, there is better support for saving and restoring the state of the plugin.

The source is now checked into svn.

[djanthonyw]

Where can I download the binary of Wine from?