Re: [linux-audio-dev] SuperClonider

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] SuperClonider
From: Michael J McGonagle (fndsnd_AT_rcnchicago.com)
Date: Sat Apr 20 2002 - 20:14:28 EEST


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Apr 20 2002 - 20:10:00 EEST