I completely agree with your statements below (except maybe with using
C++ as the implementation language), and even more so, if a common
"module" API would also be taken into consideration, so not only the
csound gurus could easily write additional opcodes etc. But doesn't e.g.
Paul Barton-Davis' Quasimodo implement most of the suggested features
(correct me if I'm wrong here)? Then only porting to other platforms
would have to be done, which is mostly the thread- and hardware-stuff, I
assume. Plus, as the various facilities seem to be split into several
libraries, also APIs for audio/midi device/file access would be commonly
available. Anyhow, I'd be glad to lend a hand for making csound into a
library.

Michael Gogins wrote:

> [...]
> Csound changes from an executable program with a main() function, into a
> static library with various functions: sco and orc file readers, audio
> input, audio output, command input, score line input, midi event input, midi
> event output, console message output. This library is written ENTIRELY in
> lowest-common-denominator runtime-library-only C++. The code is re-entrant
> and multiply instantiable (several instances of Csound can run inside the
> same process or address space, at the same time).
> [...]
> Making these changes not only would enable Csound to become all kinds of
> useful goodies, it would also make Csound itself much easier to maintain and
> develop further, because the "engine" would be identical on all platforms.
> [...]

Paul Barton-Davis wrote:
 
> just a quick heads up on what's been going on with Quasimodo.
> 
> prompted by several people and several things, Quasimodo has now been
> completely split into completely independent pieces:
> 
>            * libpbd:    a C++ library of utility functions and classes
>            * libmidi++: a C++ library that uses libsigc++ to provide
>                         rather nice access to a MIDI device
>            * libsoundfile: a C++ rendering of the best ideas from
>                            Bill Schottstaedt's sndlib
>            * libaudiohw: a C++ library abstracting away audio hardware
>            * libquasimodo: the core DSP engine of Quasimodo
> 
>            * opcodes-gpl: Csound opcodes that were released under the GPL
>                           or permission was granted to me to do so
>            * opcodes-non-gpl: Csound opcodes still under the MIT license
> 
>            * gtk-quasimodo: a GTK user interface to a quasimodo engine
>            * server-quasimodo: a TCP/IP server interface to a quasimodo engine
> 
> each of these pieces now comes with its own GNU autoconf/automake
> files so that it can be built on any platform supporting the basic
> functionality that that piece requires from the compiler, standard
> libraries, operating system and hardware. Those requirements are:
> 
>            * libsigc++ ported (true for most mainstream and semi-mainstream
>                                platforms)
>            * C++ compiler that can handle namespaces, exceptions, and
>                                a few other minor modern features
>            * pthreads (POSIX P.1003 standard)
> 
> if your system has these, then implementing the required classes to
> port libmidi and libaudiohw should take about 1 hour each.

gruss - regards - stefan.
__________________________________________________________________________
K-Labz [a K-Hornz subdivision] - steve-k@gmx.net - http://w3.to/K-Hornz

--

What tends to happen here is things go wild. I've made every effort to keep
my ideas as simple as possible and to change Csound as little as possible.
I'm increasingly convinced that Csound is the best instrument on the planet
at this time; I now know that not only can you do so very many different
kinds of synthesis, but you can even get most of them to sound quite good.
So I don't at all want to break this thing or change its basic workings.

To repeat, the single C++ class is absolutely the simplest interface I could
come up with that would separate the "kernel" from the operating system
calls without altering the workings of Csound. Additional modules are
unnecessary complexity.

If one desires a better language than Csound, by all means, use SAOL, which
is potentially better than Csound. I'm interested in both.

-----Original Message-----
From: steve@cs.tu-berlin.de [mailto:steve@cs.tu-berlin.de]On Behalf Of
Stefan Kersten
Sent: Friday, November 05, 1999 11:35 AM
To: Michael Gogins
Cc: Csound List; Csound Linux/Unix List
Subject: csound library was: line event problem


I completely agree with your statements below (except maybe with using
C++ as the implementation language), and even more so, if a common
"module" API would also be taken into consideration, so not only the
csound gurus could easily write additional opcodes etc. But doesn't e.g.
Paul Barton-Davis' Quasimodo implement most of the suggested features
(correct me if I'm wrong here)? Then only porting to other platforms
would have to be done, which is mostly the thread- and hardware-stuff, I
assume. Plus, as the various facilities seem to be split into several
libraries, also APIs for audio/midi device/file access would be commonly
available. Anyhow, I'd be glad to lend a hand for making csound into a
library.

Michael Gogins wrote:

> [...]
> Csound changes from an executable program with a main() function, into a
> static library with various functions: sco and orc file readers, audio
> input, audio output, command input, score line input, midi event input,
midi
> event output, console message output. This library is written ENTIRELY in
> lowest-common-denominator runtime-library-only C++. The code is re-entrant
> and multiply instantiable (several instances of Csound can run inside the
> same process or address space, at the same time).
> [...]
> Making these changes not only would enable Csound to become all kinds of
> useful goodies, it would also make Csound itself much easier to maintain
and
> develop further, because the "engine" would be identical on all platforms.
> [...]

Paul Barton-Davis wrote:

> just a quick heads up on what's been going on with Quasimodo.
>
> prompted by several people and several things, Quasimodo has now been
> completely split into completely independent pieces:
>
>            * libpbd:    a C++ library of utility functions and classes
>            * libmidi++: a C++ library that uses libsigc++ to provide
>                         rather nice access to a MIDI device
>            * libsoundfile: a C++ rendering of the best ideas from
>                            Bill Schottstaedt's sndlib
>            * libaudiohw: a C++ library abstracting away audio hardware
>            * libquasimodo: the core DSP engine of Quasimodo
>
>            * opcodes-gpl: Csound opcodes that were released under the GPL
>                           or permission was granted to me to do so
>            * opcodes-non-gpl: Csound opcodes still under the MIT license
>
>            * gtk-quasimodo: a GTK user interface to a quasimodo engine
>            * server-quasimodo: a TCP/IP server interface to a quasimodo
engine
>
> each of these pieces now comes with its own GNU autoconf/automake
> files so that it can be built on any platform supporting the basic
> functionality that that piece requires from the compiler, standard
> libraries, operating system and hardware. Those requirements are:
>
>            * libsigc++ ported (true for most mainstream and
semi-mainstream
>                                platforms)
>            * C++ compiler that can handle namespaces, exceptions, and
>                                a few other minor modern features
>            * pthreads (POSIX P.1003 standard)
>
> if your system has these, then implementing the required classes to
> port libmidi and libaudiohw should take about 1 hour each.

gruss - regards - stefan.
__________________________________________________________________________
K-Labz [a K-Hornz subdivision] - steve-k@gmx.net - http://w3.to/K-Hornz

>I'm increasingly convinced that Csound is the best instrument on the planet
>at this time; I now know that not only can you do so very many different
>kinds of synthesis, but you can even get most of them to sound quite good.
>So I don't at all want to break this thing or change its basic workings.

I agree with your first statement totally. 

I just happen to think that the brilliance of Csound lies about 99% in
its opcodes, and 1% in the engine. Conversely, 99% of the design
problems with Csound are in the engine, and only 1% in the opcodes.

Its for this reason that I tried to keep almost complete source-level
compatibility with Csound's opcode interface in Quasimodo (*), but felt
comfortable jettisoning the engine. I think that there is very little
lost by doing this, and very much to be gained. But then, you all know
this by now :)

--p

(*) actually, after the long discussion over on linux-audio-dev about
our potential new plugin API, the fact that Csound cannot be sample
accurate without setting ksmps to 1 troubles me a great deal. it might
be enough to move even further than i have moved from source-level
opcode compatibility. right now, a very simple perl script will
convert just about any new opcode's C source code and header file into
a quasimodo script. if i go down the sample accurate path, let alone
decide to support whatever the new API looks like, i don't know what
will happen.