Hi Michael,

I'll answer inline below:

> I personally am not terribly interested in a new "engine" for Csound.
>
> It seems to me that it is good to continue to refine and extend the current
> engine, with or without parser, for the sake of the body of work invested in
> Csound -- not only the Csound code, but also instrument definitions, pieces
> that can be studied, books, and so on and so on. Arguably, the richest body
> of computer music based on a particular software sound synthesis system.

By new engine I was implying just the parts underneath the hood; the
language would not change (though other languages could be built on
top or parts of the engine really could be used programatically).  So
completely backwards compatible to the user coding in ORC/SCO.

> It also seems to me that it is good to invent something quite new, if
> possible, that does not even share the Csound languages or concepts.
>
> I am afraid putting a lot of work into the internals of Csound will not
> provide as much "bang for the hour" as adding new opcodes, refining the code
> (nobody has used a profiler on it, or have they?), and of course actually
> making music.

I'm certainly enjoying my daily composition time lately and haven't
been coding much on Csound as a result, but I see a need to get the
engine reworked as an investment in the long term.  Plus if a cleaner,
easier to understand engine will attract more curious developers to
experiment with Csound, that would be a very good thing.

> Or, as much "bang" as writing a new synthesis system from scratch. I know
> from experience both with computer music, and with trading systems, that
> writing a new system from scratch is generally much easier than rewriting an
> existing system.

Every once in a while I've thought about all the synthesis systems out
there and I keep finding that Csound has many of the important parts
"right". I don't see a need for a new synthesis system from scratch,
but a new engine will really open up a whole lot of things in my
opinion that writing a new system might cover, but it would have the
benefit of all of the existing opcodes and history. (Will discuss more
about this below).

> If anyone is interested, I have been experimenting with new synthesis
> systems for years. I would write a new system as a framework for an existing
> language, rather than creating a new language designed for music. That way,
> nobody has to write any code except for making sounds or scores. At the
> moment, I am not quite sure just what language.
>
> I have written working prototypes of such systems in Java, C++/Tcl,
> C++/Python, C++/Lua, and C++ with embedded compiler (this last one based on
> SAOL). OCaml, Lisp, Lua, Python, Java, C#, and F# would all work. So, for
> that matter, would embedding a C or C++ compiler right into the synthesis
> system. At the moment, I think writing a new system from scratch for Steel
> Bank Common Lisp would be a good approach, or writing a new system from
> scratch in C++ with Lua wrappers generated by SWIG. OCaml is very well
> suited to the task, but not that many musicians know it.
>
> Whatever language is chosen, it needs to be able to run routines written in
> C or C++, and it needs to have either a native compiler, or a just in time
> compiler. All the languages I mentioned meet this criterion.

I have thought about this too.  I am pretty interested in frameworks
too versus a dedicated language.  Csound in many ways is already a
framework or well on its way, and the new engine proposal would I
believe take it all the way there.

I do think that what is going on with the Java Virtual Machine, where
you find now so many libraries compiled to Java bytecode but able to
be used *without* recompilation by any of the languages implemented on
top of the JVM (python, ruby, tcl, javascript, etc.), is very
important for future-proofing code.  I can say I am still able to use
binary jar's from 7 years ago on any platform I work on (win, linux,
osx).  Microsoft has expanded the number of languages on top of its
CLR I think for some of the same benefits.  I thinking generating
wrappers will soon go away altogether.  (Python ctypes, the JNA
library for Java allow for dynamic loading of native libraries, I
imagine this will be the way to go forward).

But that's all a digression; I think that a lot of the ideas I'm
thinking about for a Csound6 is not anything that hasn't been
mentioned here before and also sort of where Csound5 is heading
anyways.  I think though there's a need for a big number change as the
changes would break binary compatibility quite a bit.

If we can implement the following:

-programmatically building of instruments
-holding map of variables names to memory allocated
-clean up structs
-remove any "hidden globals" like curevtblk

we can then do:

-build instruments piece by piece in any language that uses csound
(thus, create instruments without having to use ORC language and
bypass parser if wanted)
-dynamically create and change instruments in realtime
-(general cleanup)
-make Csound parallizable (well, makes it easier to do so!)

The changes above are not nearly as extensive as creating a new engine
and can be done in steps, but each step will break binary
compatibility and might as well group the changes all at once.

steven

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net