Forgive me if this has been shot down in flames before, but I'm just wondering whether anything like this is at least technically possible?

Yes, it's possible. It's not going to be easy, but can be done.

Also check out, jVSTwRapper: http://www.kvraudio.com/get/925.html

Another option would be using JUCE, which is what Andrew Simper uses to wrap "The Glue".

I believe both options are open source.

Do you mean for development purposes, or run-time purposes i.e. to use in conjunction with your host?

In the latter case the folks behind the V-Machine (SM Pro Audio) have a free tool based on Wine which will run Windows audio plug-in DLL's on OS X. This was posted on the Apple site a few days ago, sounds quite promising:

http://www.apple.com/downloads/macosx/audio/vfxapplication.h tml

Not tried it myself, but going to download now and have a play when I get the chance.

Peace,
Andy.

Yes, but it doesn't allow you to run windows plugins inside of your native OS X host.

I mean for run-time purposes... as in, something to take a DLL and allow it to be run on OS X as a VST plugin.

That V-Machine thing looks great but having a hardware box is kind of annoying... if there were a purely software solution that would be ideal. Is a purely software solution impossible? Or perhaps too CPU intensive to be feasible?

Hmm this V Machine is also quite expensive...

http://www.thomann.de/gb/sm_pro_audio_v-machine.htm

411 Euro?? Daaaaaamn...

You do not need to own a V-Machine to run this software only solution, it is completely free. The V-Machine plug-in hardware, on the other hand, which is for hosting plug-ins outside of your computer, and taking a load off the CPU, is what costs.


Sure.

You could always use Jack OS X or Soundflower to route the audio back in to your host. Presumably the V-Machine app accepts a MIDI connection, so as long as the latency is OK it is a slightly inconvenient solution to a mega-problem. Well, mega if you really need to run a Windows plug-in. Can't think of anything I really need from the Windows free- or pay-ware world ...

Peace,
Andy.

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.

Whau Guys that's interesting!

I don't think that emulation would solve the problem since we are talking about high-speed processing. But most macs are now running on Intels, right? So technically it differs only in the libraries & subsystems and the executable format. I think many developers would be willing to pay for such a solution, that would take source DLL and convert it into Mac OS X format (others may be grateful for the other way). Yet I don't know if it is feasible... But if so...

The wine emulator basically does what you are suggesting. It runs your code natively using the intel instruction set. The "emulation" part comes into play when you issue a call to a Windows library function. These get vectored off to native code that performs the same function as the corresponding windows library call. Most of these emulations are actually faster than the corresponding windows implementation. In theory, a plugin running under wine should run almost as fast as the same plugin on Windows.

My wrapper runs the wine emulator as a separate process from the host DAW and as such requires some interprocess communication to get data back and forth between the two processes. This makes the whole setup more stable but adds some overhead. In my experience, this overhead has been low and I've been able to run a range of windows VSTs without appreciable slowdown.

Perhaps if you're no longer interested in developing this it would make a good open source project?

retroware - would you be at all interested in developing it further? because it sounds like exactly the thing I've been looking for

sounds like a great project to me, please release it in some form!

oli

@ 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).

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.

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.

Cheers,
Angus.

p.s. you can of course already run any Windows VST host (I'd suggest Forte or Minihost perhaps) with Crossover and an ASIO MME driver, but the latency blows hard; it looks like the shipping version of Crossover is still based on X Window System, so while it's better than running Parallels Desktop, it's still very very unMac. I had a quick google and unfortunately it looks like QuartzDrv (the OS X native, non-XWindow driver for Wine and Crossover) hasn't moved on much in the past two years. Shame