Kasper Souren wrote: > > > Well, I admit that I don't know SuperCollider... So... If you like > > SuperCollider so much, why not buy a Mac? This is not intended to be a > > flipant question, I am curious why you have choosen to use Linux over > > Mac? > > Ok, this question wasn't asked to me, but I can answer it for myself. I > had an iBook, but I couldn't work with MacOS 9. I felt like I was thrown > back 10 years in time, only to be able to control the thing with a > mouse, and a very crappy multitasking environment. I find even Windows > 2000 much nicer to use than MacOS 9.
Hi Kasper, Here you are just offering opinion, I personally like any Macintosh product over any Windows product... And, I have worked with all of them over the past ten years... My reason for asking Paul why he is using Linux over Mac was not intended to be an "OS-war" question, but more to the point that if SC is such a wonderful program, then why not just buy a Mac and be done with it? I am sure that he has other reasons for choosing Linux. > > Could you offer some comparisons here? What things are possible in > > SuperCollider that are either not available or are more difficult in > > SAOL? > > AFAIK SuperCollider is much more object oriented. I think it's even > 'completely' OO, more than C++ or Java. And OO is a completely > different way of working, and of concepts than structural programming. Well, if SuperCollider is based on SmallTalk, then yes it would be OO. SmallTalk is considered to be one of the first OO languages, from whence most others model themselves. I think the only thing that makes SmallTalk more "OO" than Java is that it also abstracts all of the primitive data types into Objects. Yes, OO is different that "Structural Programming", but is it better? For some tasks it is, but I wonder if Algorithmic Composition requires OO. I could see the argument that the program used to process the Composition would be better written using OO, as it is easier to maintain large programs. > > Could you please explain why SuperCollider is so excellent? What > > features does it have that other languages should have? > > - it's object oriented I am sorry, but I don't think this is a compelling argument... > - quite flexible (not as rigid as C++) Java is a wonderful OO language, and it too is much better than C++. I personnaly don't know SmallTalk, but I have heard others comment that Java is fairly comparable... (once again, opinions abound) > - it's realtime, and it 'knows about time' This is a good point. But, if you are using 'sfront' to compile your orchestra files, then the resulting programs can be used in real-time. > - it has an interpreter There are a couple of projects that are working on Interpreters for SAOL, I wonder how soon they will be releasing their programs... > - it's easy to learn (probably because of the 4mentioned features) > > > Could you please expand on your thoughts here? What things are needed > > that are missing in the Music N line? I am assuming from this statement > > that the language should be a complete programming language. What things > > require this? How "complete" does the language need to be? > > - it's not a Music N language. If you want (and you probably want that) > you can completely forget about orcs and scores. (There is an OrcScore > object available though :) I know that SC is not a Music N language, I was asking for a comparison with SC that describes what Music N features are not needed. Is it just a matter of being able to "forget about orcs and scores"... > I think there isn't anything missing in the Music N line, because Music > N is a certain paradigm. A Music N language is not meant to have OO, nor > an interpreter... otherwise it's not Music N anymore. Yes, it is a paradigm that was created on Time Sharing Computers back in the 60's, and you had to "batch" process your files. But how does this prevent Csound or SAOL from being used with an interpreter? And why does that all of a sudden make them "not Music N"? > Yes, with a musical programming language you should be able to do > anything any programming language can do. So why not just take the GNUSmallTalk and use it. What other things are required by your "musical" language that are not in other languages? You mentioned the "real-time" and knowledge of time, are there others? > Maybe some things are not as > easy to implement as in languages meant for other purposes, but > definitely possible. (It would be nicer if there WAS a GNUcollider, and > you could easily interface to stuff in C++, C, Pascal, ...) Well, if this language that you are creating is already a complete programming language, why do you want to "easily" interface with other languages? This just seems like the same problem that Csound is suffereing from (yes, I know it is not a complete programming language, but the point is Code Bloat and having different code bases to work with). This is one of the things that I like about SAOL, things that I have done with Csound required that I write my "algorithmic" stuff in C (or some other language), then I had to write the instrument code, and create a score file. With SAOL, I can write all of the stuff (except for the score, which in this case is reduced to a simple statement) in SAOL, and not have to switch back and forth to generate the score from the Algorithmic program, and then run it thru Csound. > I don't know how complete a musical language exactly has to be, i.e. > what would be the minimum requirements. But I think that's not the way > to think about it, it doesn't have to minimally complete, it has to be > sufficiently complete. Well, SAOL is sufficiently complete. What is missing? It is not a complete programming language, but it does allow you to write all that you need in SAOL without having to write stuff in a higher level language and then "recompile" your interpreter (as in Csound). > And you definitely need classes (and methods, inheritance, ..), > functions, control structures, basic mathematical functions. Well, this is just more opinion, while I agree with that last three items, the first (the OO stuff) I wonder if it is needed. > And, which > is probably the hardest part, internally there has to be a notion of time. Hum, I guess I don't really know what you mean here. Could you explain a little more? Thanks, Mike
