OSX and Linux status update

wsippel · Post by **wsippel** » Sun Feb 06, 2005 10:35 am

DementiaT,

I think there are some things to clear up a little more in-depth?

See, first of all, quite a few companies are indeed releasing the sources for their drivers, or at least support the development of open source drivers by releasing hardware specs and answering questions (eg HP, Intel, RaLink, RME, 3com, SEK'D, TechSource, Atmel, Nokia, Echo, AMD, VIA, Adaptec, Wacom, 3Ware...). Or they develop distribution-independent binary drivers, like Nvidia or ATI do it - with distribution-independant packages, there's no need to offer many different packages, just one per arch (IA32, amd64).

In CW's case, it's quite different. The driver by itself contains no important IP - it's simple and useless, and will most likely become open source. The secret and important stuff is in the Scope operating system, a mere DLL on Windows. Just before NAMM, we discussed the possibility to make SFP completely open source (with a plugin interface), and CW will provide the equivalent to the SIM.DLL as a binary + header, most likely offering three or four flavors (IA32 w/ TLS, amd64 w/ TLS). Some of the plugins would also be closed source, due to 3rd party IP (ASIO driver, GSIF driver, DirectSound driver). The libraries for Linux will be available from CW's website, for those that want to compile SFP on their own, the driver (kernel interface) might be included in ALSA, and, therefore, the 'vanilla' Linux kernel. We don't know if we'd provide binary packages, but I'll most likely provide an ebuild for gentoo Linux...

This concept would help CW in different ways. For example, as you most probably know, CW had to lay off quite a few of their coders, making it harder to improve SFP, or port the software (not only OSX, but also Win x64 - in addition to Linux). With an open architecture, the community could improve the codebase for better portability, improve the user interface code, fix bugs, while independant developers could add interface drivers (like GSIF2 or AU) and provide them as binary plugins. The remaining CW coders could concentrate on ScopeOS and new/ improved devices that way. Since we try to re-use as much of the codebase as possible, a fix written for the Linux version could also improve SFP on all other platforms.

As already posted, CW would _not_ offer tech-support for the Linux release. Maybe PlanetZ will add a Linux support forum or something, but that's it...

And last, but not least, Linux is not UNIX - *BSD is, as is AIX, Solaris and HP-UX, but Linux is not...

[ This Message was edited by: wsippel on 2005-02-06 10:38 ]

CroNiX · Post by **CroNiX** » Sun Feb 06, 2005 9:45 pm

Dont get me wrong...I would love a SFP linux version. Then all we need is a good sequencer to make it all work properly

My only concern is having 30 different versions of SFP floating around because anybody can modify and (re)release the code. Its easy to lose control. This could either be a good or bad thing as there are many extremely talented coders out there who could really do the project justice, or give everybody a nice new virus.

wsippel · Post by **wsippel** » Sun Feb 06, 2005 11:05 pm

There's an easy solution for this problem: don't trust releases you got from anyone except CW...

Maybe we could even provide a nice, distribution independent binary package for Linux, using a nifty GUI installer (Loki, InstallAnywhere, Autopackage...). And if you want to compile SFP on your own, grab the sources from the CW site or an official mirror...

ooo000ooo · Post by **ooo000ooo** » Mon Feb 07, 2005 11:15 am

wow
if the whole system goes open source they'd start selling boards like hot cakes. after all it's a system for hackers.
for me I think I'd end up buying as many as I can fit in one computer.
so when you say SIM.DLL you mean the OS will keep closed right?
but then I guess it would be possible to develop your own plug-ins ... how does this differ from using the SDK? would it be possible with less DSPs?

[ This Message was edited by: ooo000ooo on 2005-02-07 11:17 ]

dehuszar · Post by **dehuszar** » Mon Feb 07, 2005 1:00 pm

On 2005-02-06 21:45, DementiaT wrote:
Dont get me wrong...I would love a SFP linux version. Then all we need is a good sequencer to make it all work properly My only concern is having 30 different versions of SFP floating around because anybody can modify and (re)release the code. Its easy to lose control. This could either be a good or bad thing as there are many extremely talented coders out there who could really do the project justice, or give everybody a nice new virus.

I can't think of a single GNU app that's ever forked more than 2-3 times, and most of those just die off. If you look at the majority of GNU/Linux apps, the codebase never really leaves the grip of the original designers unless they are unable to continue to move the project along.

People can make their own hacks to the code and submit them or keep them for their own use. If CW cooperates in, at the VERY LEAST, keeping the Codebase with a stamp of approval, available as a part of their website (that portion can even be hosted on a foreign server with all the appropriate disclaimers) they'd be able to minimize any risk of letting the direction of SFP away from them by "officializing" whatever package suits their interests.

Sam

wsippel · Post by **wsippel** » Mon Feb 07, 2005 2:53 pm

ooo000ooo,

no, that won't help creating plugins. As the OS handles the decryption of the plugins, you won't be able to encrypt and load them. And, of course, CW wouldn't open-source the DSP files, as they are platform independant anyway.

Other than that, anyone _could_ write software for Sharc DSP's without a SDK, all you'd need is the already available open-source toolchain (rg gcc for Sharc), and EZLite. But this won't allow you to write Scope plugins, as that works a little different. As far as I know, Scope is based on a CSound port Analogue Devices did years ago, with some additional goodies added by CW (like the interface code). And the CW parts, as well as the CSound code, is part of Scope OS, and will stay closed source...

valis · Post by **valis** » Mon Feb 07, 2005 3:52 pm

That's interesting. The csound archives used to refer to a board that u could purchase to run a subset of csound in realtime but since the publication of the Csound book everyone's site structure changed and I was never able to find that again.

Points to an interesting backup plan though should Creamware ever truly run into real problems (perhaps someone could shoehorn Csound onto these boards again).

wsippel · Post by **wsippel** » Mon Feb 07, 2005 6:06 pm

To say it again, I'm not exactly sure about the CSound thing. I remember that there was a port advertised and offered by AD, called XTCSound or Extenended CSound. And there was this rumor several years ago (1999/ 2000), stating that Scope was a XTCSound variant...

There were other companies back then (1997-2000), trying to sell Sharc-based XTCSound cards, like MIRA. And, if memory serves, even AD manufactured such a soundcard, called Sphinx.

The MIRA card was designed by ZP Engineering, and I'm quite sure it's the one at the bottom of this page:

http://www.zpeng.com/Articles/Section1/ ... audio.html

It's not commercially available as far as I know...

valis · Post by **valis** » Mon Feb 07, 2005 8:58 pm

I just know the ones that were talked about on the leeds email list a few years ago (sometime after 96). It appealed to me conceptually since it was realtime, but I generally enjoy working at a higher level than csound when I'm not doing hardcore sound design (and I'm not that great in csound

).

ooo000ooo · Post by **ooo000ooo** » Tue Feb 08, 2005 4:48 am

wsippel
sorry for my lack of understanding
so, with EZLite you mean evaluation boards from A/D? it's not possible to hack with the CW boards and gcc alone? (hey if they provided a driver for my platform I wouldn't be asking this)
and, being csound open source I guess that sharc version should've been delivered with source no? too bad nobody made it freely available, but if it was the base for SCOPE then it's understandable

braincell · Post by **braincell** » Tue Feb 08, 2005 7:54 pm

I'm not an economist but I'm willing to bet that if Creamware made all their software free, they would sell way more boards and make more money than they are now, much more.

wsippel · Post by **wsippel** » Tue Feb 08, 2005 8:46 pm

ooo000ooo,

yes, you'd need an EZlite board. Scope cards can't use unencrypted modules, and you can't encrypt them without the Scope SDK. I don't know, maybe you could also use a ZP board or something like that, but Scope cards won't give you raw access to the DSP's...

And even if CSound is open source, Extended CSound is not...

at0m · Post by **at0m** » Sun Feb 20, 2005 10:46 am

Apparently there's been Linux TripleDAT drivers, unfortunatly the link to the driver page is not available.
http://www.linuxdj.com/audio/quality/#question_multi

astroman · Post by **astroman** » Sun Feb 20, 2005 1:17 pm

On 2005-02-08 20:46, wsippel wrote:
... and you can't encrypt them without the Scope SDK. ...

even with the SDK you cannot encrypte them, as Nikko from DADEV wrote
http://www.planetz.com/forums/viewtopic ... forum=11&4
...which nicely vapourized all my concerns about the vulnerability of the platform

cheers, Tom

phyx · Post by **phyx** » Sat Aug 20, 2005 4:13 pm

On 2005-02-06 10:35, wsippel wrote:

In CW's case, it's quite different. The driver by itself contains no important IP - it's simple and useless, and will most likely become open source. The secret and important stuff is in the Scope operating system, a mere DLL on Windows.

You mentioned before that you have a rudimentary driver.... Could I get that?

I'll run SFP under Wine, I just need the driver.

devo · Post by **devo** » Sun Aug 21, 2005 12:06 pm

I'll run SFP under Wine, I just need the driver.

I think you need a litte more than that - there is probably lots of low level communication to the Scope cards in SFP that does not use the "driver". I don't think Wine manages to emulate that correctly.

phyx · Post by **phyx** » Sun Aug 21, 2005 2:09 pm

On 2005-08-21 13:06, devo wrote:

I think you need a litte more than that - there is probably lots of low level communication to the Scope cards in SFP that does not use the "driver". I don't think Wine manages to emulate that correctly.

shhhh. don't jynx my wishfull thinking.

---

What low-level communication exactly?

How does it access the card if not by the driver?

What other requirements are there if not SFP and the driver?

Isn't SFP an operating system that runs on the cards?

Honestly, I can't imagine why it wouldn't work.

devo · Post by **devo** » Mon Aug 22, 2005 11:43 am

On 2005-08-21 15:09, phyx wrote:

shhhh. don't jynx my wishfull thinking.

well, as I have not actually seen the inner workings of SFP myself, I might just be completely wrong...maybe enough to keep your hopes up? ;o)

What low-level communication exactly?

Well, I'm thinking instructions and data over PCI to make the Scope card do whatever the user configures in SFP.

How does it access the card if not by the driver?

By sending data over PCI. Actually, I don't think the driver communicates with the Scope cards much at all. It probably only communicates with SFP which in turn sends the necessary bits and bytes to the hardware.

What other requirements are there if not SFP and the driver?

I am afraid I can't give you an answer on that one.

Isn't SFP an operating system that runs on the cards?

I can't say if the Scope cards contain their own OS (like some kind of firmware), but to me SFP is the application running in Windows (and MacOS 9) that provides a graphical interface to the user and knows how to manipulate the Scope cards.

The driver provides MIDI and Audio software connection to SFP for other Windows applications to use.

But then again, I am trying to make intelligent guesses here. Maybe someone will step up and set me straight... ;o)

[ This Message was edited by: devo on 2005-08-22 12:45 ]

astroman · Post by **astroman** » Mon Aug 22, 2005 12:58 pm

your guesses hit it pretty well, imho - and since no 'official' details are abvailable anyway, I'm only guessing, too

but something about the operation of a Scope card is rather simple and explains why it's so difficult to make it run under whatever ( compared to arbitrary other cards)

all properties and the routing is defined by DSP code, but the DSPs are empty on powerup - there's probably not even a path between the input and output connectors. Nothing at all.

only after loading the DSPs with their base information (or more), the card is able to communicate with audio/midi ports and converters etc.

ok you may say, upload a simple set of IO definitions by Sharc assembly cannot be such a deal...
Normally not - but there's a fine line to separate the men from the boys

In SFP all and every piece of DSP code is encrypted with an algorithm that's based on the content of a unique part of the hardware.

that protection scheme effectively prevents any peeks into the operation of the card.
If it wouldn't operate at such a rigid level, people would simply order their copy of DP (or SDK), peek at the output of the compiler, save it, and load it on arbitrary Sharc boards. They would have done it long ago - that simple

cheers, Tom

[ This Message was edited by: astroman on 2005-08-22 14:03 ]

phyx · Post by **phyx** » Mon Aug 22, 2005 3:32 pm

I have been awake for a long while researching driver writing...

I now have a rudimentary driver written, or rather a skeleton of a driver for FreeBSD.

The driver is based on the decompile output from the scope.sys and cwScopeProp.dll ...of course my Cards are currently in my XP box not my unix box so no testing has been done yet, nor will i begin to test until i do a little more research into PCI communication.

I have written CW asking for the driver specs, if they are cooperative, I should have some beta drivers written fairly quick.

...now, I have no intention nor the current ability to port SFP to POSIX, so I hope that SFP running under Wine will do the trick...

I need this to work asap, so I have no choice but to do it myself...

---

Devo, Astroman

I do not see how userland software can access hardware directly. What exactly are you two talking about?