Win-to-OSX VST wrapper/adapter
-
- KVRian
- Topic Starter
- 600 posts since 23 Jun, 2005
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?
- KVRAF
- 7393 posts since 20 Jul, 2004 from Clearwater
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.
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.
You are currently reading my signature.
- KVRAF
- 5948 posts since 19 Jun, 2008 from Melbourne, Australia
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/a ... ation.html
Not tried it myself, but going to download now and have a play when I get the chance.
Peace,
Andy.
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/a ... ation.html
Not tried it myself, but going to download now and have a play when I get the chance.
Peace,
Andy.
- KVRAF
- 7393 posts since 20 Jul, 2004 from Clearwater
Yes, but it doesn't allow you to run windows plugins inside of your native OS X host.
You are currently reading my signature.
-
- KVRian
- Topic Starter
- 600 posts since 23 Jun, 2005
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?
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?
-
- KVRian
- Topic Starter
- 600 posts since 23 Jun, 2005
Hmm this V Machine is also quite expensive...
http://www.thomann.de/gb/sm_pro_audio_v-machine.htm
411 Euro?? Daaaaaamn...
http://www.thomann.de/gb/sm_pro_audio_v-machine.htm
411 Euro?? Daaaaaamn...
- KVRAF
- 5948 posts since 19 Jun, 2008 from Melbourne, Australia
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.
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.
Sure.djanthonyw wrote:Yes, but it doesn't allow you to run windows plugins inside of your native OS X host.
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.
-
- KVRist
- 40 posts since 22 Mar, 2007
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.
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.
-
MeldaProduction MeldaProduction https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=176122
- KVRAF
- 14019 posts since 15 Mar, 2008 from Czech republic
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...
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...
-
- KVRist
- 40 posts since 22 Mar, 2007
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.
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.
-
- KVRist
- 112 posts since 20 Mar, 2004 from UK
Perhaps if you're no longer interested in developing this it would make a good open source project?retroware wrote: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.
Matt
Pi is exactly three
Pi is exactly three
-
- KVRian
- Topic Starter
- 600 posts since 23 Jun, 2005
retroware - would you be at all interested in developing it further? because it sounds like exactly the thing I've been looking for
-
- KVRian
- 871 posts since 24 Jun, 2002 from Berlin
sounds like a great project to me, please release it in some form!
oli
oli
-
- KVRAF
- 4735 posts since 18 Jul, 2002 from London, UK
@ 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.
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.
This account is dormant, I am no longer employed by FXpansion / ROLI.
Find me on LinkedIn or elsewhere if you need to get in touch.
Find me on LinkedIn or elsewhere if you need to get in touch.
-
- KVRAF
- 4735 posts since 18 Jul, 2002 from London, UK
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
This account is dormant, I am no longer employed by FXpansion / ROLI.
Find me on LinkedIn or elsewhere if you need to get in touch.
Find me on LinkedIn or elsewhere if you need to get in touch.