Posted: Wed Aug 24, 2005 6:19 pm
I've been watching this little tete a tete with a bit of amusement. As someone who works regularly with Linux and has a reasonable amount of experience with OpenBSD, I find this all a little ridiculous. I hope this will not sound disdainful as I don't mean to, I certainly don't know it all, but here it goes anyway.....
First off, the Muse VST box uses Wine to port the VST libraries over to the Jack and ALSA audio servers. You STILL NEED LINUX DRIVERS FOR IT TO WORK on your soundcard. Moreover, the VST engine is NOT ASIO. It is, like DP, or Modular, a toolkit which sits upon an established platform and framework. Muse's product just takes the work out of it for you.
But you'll note that if you try and recreate the experiment at home (which is not THAT hard to do), you'll find the support page which directs you to Linux drivers for RME, and Sound Blaster cards, etc.. Now I know Phyx is intent on building such a driver, but as I'll get to in a moment, a driver and windows emulator alone do not a working platform maketh. More on this...
But first, Wine definately takes a hit in performance, however, it tends to still perform on par with Windows applications where Linux is more efficient and has control of certain aspects of an app. For instance, any time an app has to do heavy read and write tasks, a UNIX based system will almost always smoke a Windows system and throw the butt out the window as it drives off. A jounaled Tree system of file-management like ReiserFS, XFS, and to a lesser extent ext2 or 3, is far more efficient than Fat32 or NTFS and has a far greater range of file compatibility.
You'll note that the large majority of servers and clusters which host 10k+ users are on usually some BSD, Solaris, and occasionally Linux platform. If Windows weren't such a Frankenstein of different mergers and technologies, there would be no way that a full application running under wine (note I say a FULL app, like if I'm running Photoshop) could compete with native Windows.
But if you're only porting certain libraries to gain access to VST synths (which unless sample-based are usually just .dll files), or video codecs, and the rest of the work is being done natively, you get performance gains to balance out your losses which come from non-native emulation.
Furthermore, getting Nuendo to LOAD in Wine is an enormous difference than getting it to record one single track. The main reason for this is that the only reason Wine works at all is that it fakes windows apps into using Linux hardware and frameworks, but I've yet to see an instance where you could get Wine to make your GeForce 6600GT with Linux drivers to work AS A GeForce 6600GT in a Windows app under the auspices of being Windows drivers.
Transgamer has gotten the closest, but what they've done is to port as much of the DirectX code as they've been able to reverse engineer, and then have it talk to whatever native Linux audio and video engines you can point it to.
But they are a for-profit company with a development team of at least 25, plus volunteers. And they've still got a long way to go. None of the major Windows emulators barring MAYBE VMWare (whose latest version I haven't used), or XenSource (which I haven't used at all) can even figure out how to get USB ports to work in Windows apps under Linux.
Photoshop runs under Wine because you do not need any specialized hardware to get it running. Cubase and Nuendo do not share this luxury.
Not that you would even NEED all of that, as the SFP OS; i.e. GUI, was built (as has been mentioned in several places on the Z including Wsipple's first couple of posts) in wxWidgets, formerly wxWindows, and is already portable to any platform that supports C++, which is I think almost all of them dating back to the mid-late eightees.
What you need in order to use the SFP OS on top of whatever drivers you are able to concoct is a binary which can load the dsp libraries, and push the modules and devices onto the SHARC chips, which as Tom as illustrated, is made quite difficult with great intention.
You see, Linux, or BSD, or whatever is pretty smart. In an old experiment I tried, SuSE, Ubuntu, and Linspire (all using LiveCDs) were able to see my Creamware cards through my old Magma's Cardbus controller (which requires a bevy of drivers and coddling under Windows) and I could mknod and modprobe them all the live long day.
But that doesn't make it a usable solution because, like on windows, until you run "SFP.exe," or in our theoretical case, "./sfp", then there's no means of communication between a driver, and our mecca of aural excitement.
Even if you create a driver for Linux, you'll still have to figure out how Windows would read the driver for it's own purposes, only to be able to load a GUI which is designed to be cross-plaform to begin with.
As Paul Tanti once told me, the driver is really more of a place-holder for the SFP OS than anything else. So when Cubase or Sonar says "Oh Creamware driver, where are your thoughts on ASIO being kept and with what options should it be loaded to suit you best?" and the Creamware driver says, "see SFP.Software.24bit-ASIO".
Now obviously I'm fudging that entirely, but the point is, the driver itself doesn't do much, unless you understand the interplay which is taking place in that encrypted space.
So I recommend that you (Phyx) contact wsippel and sign their NDA, because your BSD experience will help them GREATLY. Really.
Remember, OSX's Darwin core is based on BSD, and BSD is binary-compatible with Linux and most other Unices.
To boil it down, there are so many layers of complexity and hardware abstraction going on under Wine, that while it's already hard enough getting a stable SFP system under Windows natively, given Scope's pickiness with hardware and the basic bugginess of most of the sequencers out there, trying to make that whole lake of mud run semi-intact in a foreign OS is probably not the best approach.
There is already a project in motion which needs you. And I would like to extend my support should you wish to walk it. But you'll likely need some documentation which requires a bit of hoop-jumping to really achieve what you want.
This concludes my off-the-cuff rant, and I hope that those who spot a few factual errors will correct me as I'm not infallible. Flame on.
With love and respect,
Sam
First off, the Muse VST box uses Wine to port the VST libraries over to the Jack and ALSA audio servers. You STILL NEED LINUX DRIVERS FOR IT TO WORK on your soundcard. Moreover, the VST engine is NOT ASIO. It is, like DP, or Modular, a toolkit which sits upon an established platform and framework. Muse's product just takes the work out of it for you.
But you'll note that if you try and recreate the experiment at home (which is not THAT hard to do), you'll find the support page which directs you to Linux drivers for RME, and Sound Blaster cards, etc.. Now I know Phyx is intent on building such a driver, but as I'll get to in a moment, a driver and windows emulator alone do not a working platform maketh. More on this...
But first, Wine definately takes a hit in performance, however, it tends to still perform on par with Windows applications where Linux is more efficient and has control of certain aspects of an app. For instance, any time an app has to do heavy read and write tasks, a UNIX based system will almost always smoke a Windows system and throw the butt out the window as it drives off. A jounaled Tree system of file-management like ReiserFS, XFS, and to a lesser extent ext2 or 3, is far more efficient than Fat32 or NTFS and has a far greater range of file compatibility.
You'll note that the large majority of servers and clusters which host 10k+ users are on usually some BSD, Solaris, and occasionally Linux platform. If Windows weren't such a Frankenstein of different mergers and technologies, there would be no way that a full application running under wine (note I say a FULL app, like if I'm running Photoshop) could compete with native Windows.
But if you're only porting certain libraries to gain access to VST synths (which unless sample-based are usually just .dll files), or video codecs, and the rest of the work is being done natively, you get performance gains to balance out your losses which come from non-native emulation.
Furthermore, getting Nuendo to LOAD in Wine is an enormous difference than getting it to record one single track. The main reason for this is that the only reason Wine works at all is that it fakes windows apps into using Linux hardware and frameworks, but I've yet to see an instance where you could get Wine to make your GeForce 6600GT with Linux drivers to work AS A GeForce 6600GT in a Windows app under the auspices of being Windows drivers.
Transgamer has gotten the closest, but what they've done is to port as much of the DirectX code as they've been able to reverse engineer, and then have it talk to whatever native Linux audio and video engines you can point it to.
But they are a for-profit company with a development team of at least 25, plus volunteers. And they've still got a long way to go. None of the major Windows emulators barring MAYBE VMWare (whose latest version I haven't used), or XenSource (which I haven't used at all) can even figure out how to get USB ports to work in Windows apps under Linux.
Photoshop runs under Wine because you do not need any specialized hardware to get it running. Cubase and Nuendo do not share this luxury.
Not that you would even NEED all of that, as the SFP OS; i.e. GUI, was built (as has been mentioned in several places on the Z including Wsipple's first couple of posts) in wxWidgets, formerly wxWindows, and is already portable to any platform that supports C++, which is I think almost all of them dating back to the mid-late eightees.
What you need in order to use the SFP OS on top of whatever drivers you are able to concoct is a binary which can load the dsp libraries, and push the modules and devices onto the SHARC chips, which as Tom as illustrated, is made quite difficult with great intention.
You see, Linux, or BSD, or whatever is pretty smart. In an old experiment I tried, SuSE, Ubuntu, and Linspire (all using LiveCDs) were able to see my Creamware cards through my old Magma's Cardbus controller (which requires a bevy of drivers and coddling under Windows) and I could mknod and modprobe them all the live long day.
But that doesn't make it a usable solution because, like on windows, until you run "SFP.exe," or in our theoretical case, "./sfp", then there's no means of communication between a driver, and our mecca of aural excitement.
Even if you create a driver for Linux, you'll still have to figure out how Windows would read the driver for it's own purposes, only to be able to load a GUI which is designed to be cross-plaform to begin with.
As Paul Tanti once told me, the driver is really more of a place-holder for the SFP OS than anything else. So when Cubase or Sonar says "Oh Creamware driver, where are your thoughts on ASIO being kept and with what options should it be loaded to suit you best?" and the Creamware driver says, "see SFP.Software.24bit-ASIO".
Now obviously I'm fudging that entirely, but the point is, the driver itself doesn't do much, unless you understand the interplay which is taking place in that encrypted space.
So I recommend that you (Phyx) contact wsippel and sign their NDA, because your BSD experience will help them GREATLY. Really.
Remember, OSX's Darwin core is based on BSD, and BSD is binary-compatible with Linux and most other Unices.
To boil it down, there are so many layers of complexity and hardware abstraction going on under Wine, that while it's already hard enough getting a stable SFP system under Windows natively, given Scope's pickiness with hardware and the basic bugginess of most of the sequencers out there, trying to make that whole lake of mud run semi-intact in a foreign OS is probably not the best approach.
There is already a project in motion which needs you. And I would like to extend my support should you wish to walk it. But you'll likely need some documentation which requires a bit of hoop-jumping to really achieve what you want.
This concludes my off-the-cuff rant, and I hope that those who spot a few factual errors will correct me as I'm not infallible. Flame on.
With love and respect,
Sam
