I'm glad to have your response, but let me clear up some misconceptions.

I'm calling for Csound to become an engine built in COMPLETELY
cross-platform, lowest-common-denominator, plain old C. Only runtime library
calls, no system calls. There is an abstract interface for each of (1) MIDI
in, (2) MIDI out, (3) audio in, (4) audio out, (5) plugin function tables,
(6) plugin unit generators, and then (7) VST service for clients, and
finally (8) programmatic control.

All graphical goodies are done in Java and use the abstract interfaces to
get at the kernel. If JavaSound is good enough, all the abstract interfaces
above except (5), (6), (7), and (8) are service provider interfaces for
JavaSound - we don't have to implement the other side of those interfaces at
all.

Threading issues can be dealt with by ignoring them, for the most part; the
Java host can spawn a new thread to render a Csound job, but the engine need
only be single-threaded as it now is.

I would repeat my rant as something to do for SAOL - if an efficient
complete implementation existed. Csound exists, and it's DEEP.


-----Original Message-----
From: rdbr03035 
Cc: music-dsp ; CSOUND 
Date: Wednesday, June 16, 1999 10:32 AM
Subject: Re: Csound and other synthesis systems


>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