Michael Gogins mounted his soapbox on the limitations of Csound.  He
seemed to be focused on a Windows-based patchable-synthesiser view of
software synthesis.

Here's the view from my particular soapbox.   

There is much more to software synthesis and Csound than being like a
Moog modular on MIDI, but such a thing would certainly be a marvel and
would be widely used, including by me!

There are those of us who do not want to run things on Windows if we
can help it.  (I find Windows a seriously unreliable and frustrating
operating system, despite its creature comforts which I know and
love.  I have no interest in owning a Mac - too expensive and weird.) 
We want open-source free software which runs on an open-source
operating system - most obviously Linux.  We want all the compilers
etc. to be open-source too.

See these sites for more on "free" and "open-source" software:

  http://www.fsf.org/philosophy/philosophy.html
  
  http://www.opensource.org

With a sufficiently motivated user community, the tools evolve well
and are typically the best available at any price.

This way, unless the code base is badly writen, we can modify and
extend the programs as we choose, and feed those improvements back
into the mainstream versions of that program.  This is what has been
done with Csound in recent years (with John Fitch doing a lot of the
work), but there are limits beyond which it cannot be improved or
changed.

Don't even think about any significant changes to the Csound code
base.  Many who have looked closely at it have come away shaking their
heads.  It works at what it does.  In many respects it is an elegant
and unbeatably fast system.  Parts of it can be tweaked.  However it
is not sufficiently well structured or well documented to allow any
major conceptual change in its operation - internally or in terms of
score, orchestra file, or unit-generator sructure.  Although the
unit-generator concept is a highly object oriented approach, the code
itself is written in plain C (originally not ANSI C) to low standards
of internal documentation.  Csound's copyright is more restrictive
than the the full GPL open-source arrangement which is being adopted
for many of the most significant software projects today.

The only attempt I am aware of to produce a Csound-compatible
real-time graphic and MIDI controlled software synthesis system is
Paul Barton-Davis' so-far solitary work on Quasimodo:

  http://www.op.net/~pbd/quasimodo/

It is early days yet.  I did get a sound out of it two days ago -
real-time GUI control of instrument parameters.  This can be done via
MIDI too, and it can output MIDI and input sound too . . .  Paul is
making rapid progress. We have just established a mailing list for
those who are interested.  It is a "hackers only" source code release
- you have to compile it yourself, and there is a list of things you
need to install beforehand.

Quasimodo does not run on Windows or Mac and probably never will.  It
is a multi-threaded application ready for symmetrical mulitprocessing
dual CPU machines (enabling the DSP stuff to run on one CPU and the
user interface to run on another).  It uses the latest techniques in
C++ programming, including STL (Standard Container Library).  My
initial impression is that the structure is sound and the code-writing
and documentation values are high.


There seem to be types of people who are interested in investing the
immense effort required to develop a usable software synthesis
language / GUI real-time-synth:

1 - People like Paul Barton-Davis, a few other people and probably me
    who would only consider doing this in a purely open-source
    arrangement, and therefore not to sell the program on the 
    shrink-wrap market.  We rely on collaboration and other sources
    of funds.

2 - Those who are prepared to develop their own products alone, 
    in Windows or Mac environments, and sell them to the masses
    who currently typically prefer these types of computer.
    These people need to raise capital, work alone, keep their
    source code secret and be concerned about musicians pirating
    their software.  Their environment for software is not so 
    flash in many respects.  They are generally dependent on 
    commercial compilers.  Is the Mac ready for multiple CPUs?
    Windows NT supposedly is - but it is a crash-prone as
    Win98.  They can only occasionally release updates to their
    software, while open-source people can release updates
    without any significant cost, delay or impediment.
 

Only two of Michael's suggestions seem practical to me:

> Csound gets low-latency MIDI and audio input and output that works 
> more or less the same on its major platforms.

Hasn't this already been achieved by Gabriel Maldonado and John Fitch
in the standard version of Csound?  What latency problems are there? 
Csound is very tighly coded in its central loops.  Maybe Windows
ActiveX (I don't really know what this is) can provide sufficiently
finely-diced and reliable CPU resources to make it run reliably with
short buffers.  


> Adapting Russell Pinkston's PatchWork program (16 bit Windows 
> program) to Java as a unit generator wiring form.

I guess such a patching system can be done in any language - but I
would much rather write orchestra code than muck around with a GUI on
that level!  Patching instruments together, as Quasimodo does, with
the GUI interface for each instrument defined it its part of the
orchestra file . . . . yes I think can be very useful.


Personally I think the Csound orchestra and score language should be
left behind.  If I was writing a system from scratch it would not use
any special language at all - it would be a special framework for
writing C++ to get on with real-time sound synthesis and all I/O and
GUI things you might like to hang of that.  It would do non-real-time
work as well, and the same principles would probably apply to
generating video images too.  The C++ core elements would interface to
things in other languages, for instance novel score languages or
whatever you liked to create.

I have a name for it: Topsy.  I don't expect to start on it for some
years to come - because I am involved in other things, and the
knowlege I would require is immense:  C++, STL, CORBA, GTK, SMP,
P-Threads, not to mention some more DSP theory . . . . 

So I suggest looking at Quasimodo (and hence at Linux), or going
against the flow on Windows and Mac and attempting an open-source
project there.

For those who make bold proposals about super-charging Csound itself
with major changes to its functionality . . . did you ever see the
movie "Repo Man"?  Remember what happened shortly after the policeman
is told "No . . . you don't want to look in the trunk!"?

- Robin


===============================================================

Robin Whittle    rw@firstpr.com.au  http://www.firstpr.com.au
                 Heidelberg Heights, Melbourne, Australia 

First Principles Research and expression: Consulting and 
                 technical writing. Music. Internet music 
                 marketing. Telecommunications. Consumer 
                 advocacy in telecommunications, especially 
                 privacy. M-F relationships. Kinetic sculpture.
                  
Real World       Electronics and software for music including:
Interfaces       Devil Fish mods for the TB-303, Akai sampler 
                 memory and Csound synthesis software. 

At 9:53 AM -0600 6/16/99, Robin Whittle wrote:

>I guess such a patching system can be done in any language - but I
>would much rather write orchestra code than muck around with a GUI on
>that level!  Patching instruments together, as Quasimodo does, with
>the GUI interface for each instrument defined it its part of the
>orchestra file . . . . yes I think can be very useful.
>
>
>Personally I think the Csound orchestra and score language should be
>left behind.  If I was writing a system from scratch it would not use
>any special language at all - it would be a special framework for
>writing C++ to get on with real-time sound synthesis and all I/O and
>GUI things you might like to hang of that. 

Computer music software can be a lot more than just a synth engine
of statically allocated ugens attached to a GUI. This framework is
just too limiting compared to what is possible. 
If this is the vision of what is ideal then I think you have not brainstormed
enough about what the real interesting problems are. 
There is a lot more I want to "hang on" my DSP engine than a GUI.
Once you get your ideal system how will you attach interesting behaviours 
to it? Using C++ to write intelligent players or gesture mappings, or
list processing score manipulation would be very painful. 

I think many people do not still grok the kind of things you can do
with a dynamic system like SC or Kyma which is why so many of the same 
kind of system keep coming out: GUI+DSP but no brains. 
In SC, you can write an algorithmic process to build your patch in real 
time, e.g. mapping velocity to how complex a patch you build. 
Values in your score can themselves be patches that plug into your 
instrument input. For example you could have a note in your score 
be a patch of ugens. Then that voice's patch will get built with that 
sub-patch plugged into its input instead of just a float value. 
Instruments can spawn sub patches recursively to any depth. etc.. 

That is why I think having a language is important. There is only
so much you can do with a static framework. Static frameworks are not
much better than just having cheap sound hardware. A powerful language
gives you a lot more ability to do what computers can be good at which
is manipulating abstractions. And C++ is just not a very highly abstract 
language.


   --- james mccartney     james@audiosynth.com   http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:






dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html