I agree that, taken direfctly in the conext of newer softsynths, Csound
can look 'creaky', and it is indeed a tempting thought to revamp the
whole thing to exploit the best of modern GUI/Plugin techniques. I have
long thought about doing this myself 'as an exercise'. However, one
vital aspect of Csound it it's extremely wide cross-platform character;
and indeed it's core functionality as a console program has advantages
for visually-impaired users.

I don't think this could be done piece-meal. Basically, one would have
to take the score and orc syntax and create a new engine from scratch,
with multiple thread, dynamic libraries, and all the superstructure of a
modern GUI-based application.

Set against this is SAOL, which is ~fully~ public domain, and which is
open for adaptation in any number of ways, has a more up-to-date
language, and even has a means of compiling into a stand-alone
application, thanks to 'cfront'. The legacy of SAOL scores is also
arguably less significant, so compatibility at the command-line level is
scarcely an issue. After all, SAOL is expected to be embedded in set-top
boxes ere long!

In the end, it depends how stronly the moral imperative that Csound
~should~ be at the 'leading edge' as a functioning softsynth, in the
terms described. As it stands, it is a treasure-trove of dsp ideas, of
unique educational value, a feature that I value highly. The issue then
is one of modernity v fragmentation (unless it can be done exclusively
using Java and/or TCL/TK), an issue which simply does not arise for
SAOL. Csound ~is~ it's source code, but that is not strictly true of
SAOL - 'saolc' is merely an example implementation.

If we treat the score and orc syntax similarly, as a specification (as
we can reasonably do), there is no reason why some new program cannot be
written which implements it in a more modern form. The sticking point is
then the title (in the legal sense), as my understanding is that
ultimately this still belongs to MIT and Barry Vercoe.


Richard Dobson


Michel Jullian wrote:
> 
> Michael Gogins wrote:
> 
> > Csound could be put firmly back at the leading edge of the state of the art
> > if:
> >
> > Csound gets plugin unit generators and function tables with a SIMPLE, I mean
> > REALLY simple, API.
> > Csound gets double-precision signal processing (Buzz and Generator use
> > floats).
> > Csound gets low-latency MIDI and audio input and output that works more or
> > less the same on its major platforms.
> > Csound gets an at least semi-snazzy GUI including unit generator wiring.
> > Csound gets an external API for programmatic control.
> > Csound can act as a VST plugin.
> 
> This last point is _very_ good idea (the other points too). The VST 2 sdk,
> featuring full midi control of plugin synths (AFAIK it's the only plugin
> architecture with this feature) and a multiplatform GUI API, is due out any
> day now (watch out for it on steinberg's vst devs list
> ). Furthermore it is open not only to plugin
> developers but also to host developers, which should help it become a standard.
> 
> What would be really nice would be if csound could "compile" orcs as vst
> plugins, somehow, instead of (or as well as) acting as a vst plugin.
> 
> --
> Greetings,
> Michel
> .........................................................................
>   Michel Jullian   Directeur General             email mj@exbang.com
>   Exbang Industries S.A.
>   Mas Chauvain   route de Villeneuve             tel +33(0) 499 529 878
>   Maurin     34970 Lattes     France             fax +33(0) 499 529 879
> .........................................................................

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

>I don't think this could be done piece-meal. Basically, one would have
>to take the score and orc syntax and create a new engine from scratch,
>with multiple thread, dynamic libraries, and all the superstructure of a
>modern GUI-based application.

I sound like a stuck record, but ... exactly what you describe can be
found at http://www.op.net/~pbd/quasimodo :) It uses POSIX P.1003
threads for portability, and a (fast) GUI toolkit (GTK+) that has been
ported to all major POSIX-like operating systems and recently to
Windows as well.

>Set against this is SAOL, which is ~fully~ public domain, and which is
>open for adaptation in any number of ways, has a more up-to-date
>language, and even has a means of compiling into a stand-alone
>application, thanks to 'cfront'. The legacy of SAOL scores is also
>arguably less significant, so compatibility at the command-line level is
>scarcely an issue. After all, SAOL is expected to be embedded in set-top
>boxes ere long!

you refer to its adoption as part of MPEG-4. there are still some
pretty theoretical substantial issues to deal with before MPEG-4
becomes a reality in set top boxes. In particular, there is no method
at this time for MPEG-4 coding of existing music, other than its
implicit use of non-MPEG-4 methods.

>using Java and/or TCL/TK), an issue which simply does not arise for
>SAOL. Csound ~is~ it's source code, but that is not strictly true of
>SAOL - 'saolc' is merely an example implementation.

and, as Eric has freely pointed out, not a particularly fast one. In
my spare moments, such as they are, I have been working on merging the
SAOL yacc grammar into Quasimodo, so that it will support SAOL as
well. Its not terribly hard to do, given that I already have two
languages parsers there already.

>If we treat the score and orc syntax similarly, as a specification (as
>we can reasonably do), there is no reason why some new program cannot be
>written which implements it in a more modern form. 

Which is precisely what Nicola tried to do when he began work on his
Yacc parser for Csound orchestras, and precisely what I finished as
part of Quasimodo. Its worth noting that you *cannot* parse Csound
orchestras without a complete list of known opcodes - a serious
limitation of its Music N inheritance. I got close to getting away
without the list, but some orc's by Russel Pinkston and Hans Mikelson
soon blew that idea out the window.

I have also done some work on the yacc grammar for scores, and it
supports basic scores, but not more complex features such as ramping,
np, pp etc. I also have no plans to ever add the macro systems to the
parsers. There are much better macro processors out there like m4 that
can be used to do the same thing (although they can't do floating
point expression evaluation, but this should be part of Csound itself,
not its macro language).