Michael Gogins wrote:

> I'm increasingly convinced that Csound is the best instrument on the planet
> at this time;

At least one of the best ;)

> 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.

What I meant here is just a header file with all (potentially
easy-to-use) functions and data structures declared you need to create a
new opcode. This would not complexify but greatly simplify things.

> If one desires a better language than Csound, by all means, use SAOL, which
> is potentially better than Csound.

I think the question is not wether to improve csound as a language, as
it has evolved over the time and seems to have proven to be a quite
flexible synthesis engine, but to improve its flexibility and usability
in its combination with other software and applications. Here you could
make csound into a C++ class as you suggested earlier, or oyu could
leave the current structure mostly untouched and build up some higher
level functions from the existing ones in order to control a csound
library - which would then lack the separation of os dependent and
independent code a.o. of course. The question also arises if such a
thing is desirable at all, since e.g. John ffitch has maintained the
sources for years and seems to be quite into them ...

gruss - regards - stefan.

PS: SAOL might have a design better than csound's, but it surely has its
drawbacks, too; if you want the state of the art, use super collider :)
__________________________________________________________________________
K-Labz [a K-Hornz subdivision] - steve-k@gmx.net - http://w3.to/K-Hornz

--

Gabriel Maldonado's DirectCsound currently implements a dynamic loader for
opcodes (plugin opcodes) that I created. He also distributes a plugin
incorporating Perry Cook's STK instruments as opcodes.

This scheme uses the existing Csound code without change except for
dynamically allocating and reallocating the opcode dispatch table, and
adding the loader routine.

I agree that it would be useful to provide a C++ interface for opcodes, and
also, by the way, for GEN routines. This raises various issues with regard
to ending instrument instances, memory allocation, what access opcodes have
to the engine, and so on. I think it would be better to proceed with the
"Csound class" idea first, and then, if agreeable, produce the plugin spec
for opcodes and GENs.

As you point out, it would be highly desirable to have an abstract C++ base
class for opcodes, so that doing new opcodes would be simplified by deriving
from the base and only implementing the virtual OnInitialization,
OnKontrolSample, and OnAudioSample routines. To this I would add an
OnFinalization call. And I would add that a similar abstract base class for
GEN routines would be desirable.

I think the problem here is that John ffitch, who has done and is doing the
world a great service by managing the canonical Csound code, does not have
the equipment, the knowledge, or the time to manage cross-platform
development on this scale. But if the Csound community could agree on the
abstract interfaces required - something like my Csound class, the
AbstractMonitor, the AbstractOpcode and the AbstractGEN - then the work
could be divided up and done by people familiar with each platform.

As I've pointed out in the past, if something like this isn't done, then in
a few years the torch will pass from Csound to some other synthesizer
implemented in a more flexible, more up to date manner.

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


Michael Gogins wrote:

> I'm increasingly convinced that Csound is the best instrument on the
planet
> at this time;

At least one of the best ;)

> 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.

What I meant here is just a header file with all (potentially
easy-to-use) functions and data structures declared you need to create a
new opcode. This would not complexify but greatly simplify things.

> If one desires a better language than Csound, by all means, use SAOL,
which
> is potentially better than Csound.

I think the question is not wether to improve csound as a language, as
it has evolved over the time and seems to have proven to be a quite
flexible synthesis engine, but to improve its flexibility and usability
in its combination with other software and applications. Here you could
make csound into a C++ class as you suggested earlier, or oyu could
leave the current structure mostly untouched and build up some higher
level functions from the existing ones in order to control a csound
library - which would then lack the separation of os dependent and
independent code a.o. of course. The question also arises if such a
thing is desirable at all, since e.g. John ffitch has maintained the
sources for years and seems to be quite into them ...

gruss - regards - stefan.

PS: SAOL might have a design better than csound's, but it surely has its
drawbacks, too; if you want the state of the art, use super collider :)
__________________________________________________________________________
K-Labz [a K-Hornz subdivision] - steve-k@gmx.net - http://w3.to/K-Hornz

--

it will be hard for me to say this without sounding bitter, which i
don't mean to at all. i really mean that. this is all "free" software,
and we are all welcome to do whatever we want. i am really, really,
really not griping. honest.

what michael is describing is *exactly* what i have tried to do with
Quasimodo. it seems that because i didn't write it for Windows or
Java, michael feels it needs to be done again.

as it stands, Quasimodo is moving toward reliance on a very minimal
set of OS/compiler functionality requirements, cross-platform
compilability, and so forth. i have no doubt that a port to a
non-POSIX-ish OS would be more work than the existing ports to IRIX
and Solaris, but not much more if pthreads are available. such an
effort would greatly benefit quasimodo, just as stephane conversy's
ports to IRIX and Solaris have done by identifying the
platform-dependent parts more clearly so that they can be isolated and
abstracted. our new use of autoconf (still pretty minimal at this
point, but we are using it) makes the prospect of a port to say, BeOS,
much closer than it was a month ago.

The Quasimodo engine has plugin opcodes, plugin function table
generators, plugin language parsers, plugin-just-about-anything-you-want.

it was written with the intent of moving completely away from the
tangled code that Csound's engine itself has become, but keeping
compatibility with the opcode source. it already has a GTK GUI
interface, a Python GUI interface and a TCP/IP server implementation.

yes, it uses more than a base ANSI C++ runtime environment. is that
enough of a reason to do this work all over again ? i would have
thought that the simple presence of a formal language definition (in
the form of a bison grammar) within Quasimodo would be enough to give
it a strong advantage over Csound. perhaps not. there are *many, many*
issues that i have already dealt with as i moved the opcodes into
running in a multithreaded, more formally defined environment. i can
guarantee that most will come up again in any attempt to do this.

michael - what specific aspects of quasimodo lead you to want to avoid
the path it tries to follow ? i can imagine some for myself, but i
would be interested in your feedback.

--p

I'll take another look at Quasimodo. I'm not trying to make anybody bitter.
To answer your question, what kept me from using it:

1. When downloaded it, I didn't seem to end up with the whole source code
base. This was a while ago, and I may have done something wrong, or things
may have changed.

2. When I downloaded it again, I still didn't seem to end up with the whole
source code base. I did note that (a) it did not look like it would compile
straight off on Windows, and (b) it looked like the opcode code had to be
massaged to fit within the Quasimodo engine.

Please understand, I'm not a full time music developer. I have a day job
writing C++ for foreign currency trading systems. In my free time, I want to
spend most of my time writing music, not developing software. If something
looks like it's going to take more than a few hours a week, I don't do it.
That's why I rolled my own ActiveX Csound project back to a shell for the
consound or winsound or DirectCsound programs, instead of continuing to grow
it into an all-in-one, library-based, re-entrant engine like Quasimodo. This
project was going quite well, but when the latest version of Csound came out
I threw up my hands and said, enough, I don't want to keep patching this
thing. It was getting further and further removed from the Csound code base.

Also understand, Windows (C++ or Java) is my platform. I'm not a Linux guy
(yet, anyway). I don't see why this should make you bitter - it's just a
fact about me. Windows PCs are cheap, they don't need any maintenance time
(in my experience), and there's a lot of great Windows commercial software
that I use, like Cool Edit Pro and Cubase VST, not to mention the Visual C++
development environment, which is light years ahead of anything else I've
tried.

As I said, I'll make another stab at using Quasimodo. I'll let you know what
I find. If it meets my needs, I'll use it in a flash, and I'll advise others
to use it also - but one of those needs is that it be easy to use on
Windows.

-----Original Message-----
From: Paul Barton-Davis [mailto:pbd@Op.Net]
Sent: Saturday, November 06, 1999 1:09 PM
To: Csound List; Csound Linux/Unix List
Subject: Re: [Csnd] [CUD] RE: [Csnd] csound library was: line event
problem


it will be hard for me to say this without sounding bitter, which i
don't mean to at all. i really mean that. this is all "free" software,
and we are all welcome to do whatever we want. i am really, really,
really not griping. honest.

what michael is describing is *exactly* what i have tried to do with
Quasimodo. it seems that because i didn't write it for Windows or
Java, michael feels it needs to be done again.

as it stands, Quasimodo is moving toward reliance on a very minimal
set of OS/compiler functionality requirements, cross-platform
compilability, and so forth. i have no doubt that a port to a
non-POSIX-ish OS would be more work than the existing ports to IRIX
and Solaris, but not much more if pthreads are available. such an
effort would greatly benefit quasimodo, just as stephane conversy's
ports to IRIX and Solaris have done by identifying the
platform-dependent parts more clearly so that they can be isolated and
abstracted. our new use of autoconf (still pretty minimal at this
point, but we are using it) makes the prospect of a port to say, BeOS,
much closer than it was a month ago.

The Quasimodo engine has plugin opcodes, plugin function table
generators, plugin language parsers, plugin-just-about-anything-you-want.

it was written with the intent of moving completely away from the
tangled code that Csound's engine itself has become, but keeping
compatibility with the opcode source. it already has a GTK GUI
interface, a Python GUI interface and a TCP/IP server implementation.

yes, it uses more than a base ANSI C++ runtime environment. is that
enough of a reason to do this work all over again ? i would have
thought that the simple presence of a formal language definition (in
the form of a bison grammar) within Quasimodo would be enough to give
it a strong advantage over Csound. perhaps not. there are *many, many*
issues that i have already dealt with as i moved the opcodes into
running in a multithreaded, more formally defined environment. i can
guarantee that most will come up again in any attempt to do this.

michael - what specific aspects of quasimodo lead you to want to avoid
the path it tries to follow ? i can imagine some for myself, but i
would be interested in your feedback.

--p


--
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

>2. When I downloaded it again, I still didn't seem to end up with the whole
>source code base. I did note that (a) it did not look like it would compile
>straight off on Windows, and (b) it looked like the opcode code had to be
>massaged to fit within the Quasimodo engine.

(a) and (b) are both correct. i have a small perl script that takes
care of (b), though clearly (a) is a major issue.

>Please understand, I'm not a full time music developer. 

understood. 

>Also understand, Windows (C++ or Java) is my platform. I'm not a Linux guy
>(yet, anyway). I don't see why this should make you bitter - it's just a
>fact about me

it doesn't! any residue of bitterness comes from having actually
implemented a system that goes considerably beyond what you describe,
yet having failed to do it in a way that makes it clearly the path to
follow, which in turn is a fact about me :)

>As I said, I'll make another stab at using Quasimodo. I'll let you know what
>I find. If it meets my needs, I'll use it in a flash, and I'll advise others
>to use it also - but one of those needs is that it be easy to use on
>Windows.

thats unlikely to happen for some time. i'm guessing that pthreads
exists for windows, but i have no idea where. without it, quasimodo is
dead as a dodo.

--p
--