Hi. Thanks of the responses (I only just got the linux-audio-dev digest). As some people have noticed, my queries are at an early stage. No, I don't yet know too much about the way that the SC code works. (i) Yes, the gui is going to be the major problem. However, while I have only used the demo version, and not the latest version, I don't remember *that* much complexity in the gui. The graphic version may be more tricky. (ii) What I meant by a source code to source code cross-compiler is this: I don't want to be in the situation where I port one version of SC (providing that this ever happens, I'm still asking questions on the SC-dev list to find out the status of any linux port), and then have to do the same work for a later port. What I wanted to do is the following: Find the Mac-specific OS calls in the SC code, and understand what they do (sound, gui, and other). Then, write an extra module of code declaring the same functions, with linux specific code to achieve the same effect. Yes, I know this is likely to be complex, and may require the creation of a fairly large number of objects. Then, for things that cannot be so easily fixed, like OS and/or gui toolkit #includes, write a program that will modify the source code into a form so that any more missing bits can be fixed. If I can do this, then hopefully the effort in porting future mac OS releases would be much easier. I.e. unlike a traditional source code to source code cross-compiler that would compile (e.g.) fortran to C, I'll be compiling max-os specific c/c++ into linux c/c++, hopefully eased by the creation of a set of libraries of 'faked' mac os x calls. (iii) Basic linux audio code samples will be of use, as I need to understand both systems to do the patching described in (ii). So, I'll look some up. And, (iv), though I should have mentioned this more explicitly in my first email, I'm also interested to know if someone's doing this already. Cheers, Ross-c