In the perfect world we will have a DSP program that has good
"real-time" performance, a GUI front end, and a very strong and powerful
back end language that is structured, objectified, and extensible and
that also covers not only the DSP-audio rate instrument design but
includes support for embedded control-rate performance oriented code.
Something that brings together the idea of the instrument and how it is
performed in one script or program. Max/MSP and SuperCollider are the
closest to this idea in my opinion. I cant stand brain dead GUI music
apps that dont give the user any control for doing music or sound design
other than pop - retro - dance related compositions or factory preset
midi music. At the same time I dont want to have to learn 500 different
languages. But I am more inclined to learn the languages than use
something that I cant control.

Michael


Paul Barton-Davis wrote:
> 
> James McCartney writes:
> 
> >SuperCollider is a dynamically typed, real time garbage collected,
> >fully object oriented language like Smalltalk with support for true closures,
> >coroutines, positional or keyword arguments, variable length argument
> >lists, default argument values, etc.
> >It has a class library of 341 classes including a full set
> >of Collection classes like Dictionary, Set, SortedList, etc.
> >There are currently over 200 unit generators.
> 
> While I share your conviction neither Csound nor C++ are the right
> language to write complex algorithmic processes/patches/whatever, that
> doesn't mean that I think that the same language should be used for
> both those complex algorithmic processes and the specification of what
> is essentially a DSP program.
> 
> There is no justification for a DSP program to contain concepts such
> as a Dictionary or a SortedList; on the other hand, there is no
> justification for a sophisticated algorithmic language to be
> constrained by the execution model embodied in a DSP program.
> 
> Furthermore, I don't want to have to be stuck with only a single
> language to program a DSP with - Csound is bad enough, and I don't
> believe that any other language is perfect for this. What's really
> important is not the visible language but the inner parse tree that is
> used to represent DSP programs written in any language. Quasimodo has
> the basic structure to support multiple DSP languages by compiling
> them all down to the same internal form, and these different languages
> are themselves intended to be "plugins".
> 
> But to return to my point: I don't *want* a dynamically typed, real
> time garbage collected, fully object oriented language to write DSP
> code in. I *do* want such a language to write higher level
> abstractions in, and possibly to have it automatically generate DSP
> code. From what I could read of SuperCollider, this separation doesn't
> exist. This is not necessarily so bad if one can use the language
> simply. But its important to take a lesson from the history of Csound:
> things that are cool and useful ultimately end up as opcodes, not as
> things written in Csound's orc language. This means that many cool
> "modules" consist of very little more than a couple of opcode
> calls.
> 
> I also don't understand anything of what you said about note on
> velocity controlling the complexity of a patch. I think you must be
> describing something rather different than what I think of as a patch,
> which is essentially the specification of what things are connected
> together. The best I can imagine is that velocity is used to
> essentially choose one of a particular set of possible
> interconnections before any actual sound is generated, but there is no
> particular reason for this to be part of the language, and in fact,
> its a lot less flexible than doing this switching visually, via a
> velocity zone map that acts as a switch to route note information to a
> particular patch. This can be modified without editing a program, and
> in theory, the velocity can be patched through something else (e.g. a
> limiter, or an expander, or whatever) before being used by the zone
> map. Modular synthesis did have a point to it :)
> 
> --p

-- 
----------------------------------
Michael A. Thompson
[IRIX - NeXTStep - Linux - MacOS - Windows]

Home: (940)382-2086
E-Mail: mat0001@jove.acs.unt.edu