Well, the best thing would be to look over the code and see for yourself.

But in summary, the whole audio and soundfile I/O setup in Csound has been
simplified by John ffitch, ditching the lower half in favor of PortAudio and
libsndfile. The upper half (transferring from the third party library
buffers to spin, and from spout to the third party library buffers) remains,
sort of, but I guess it might be a little simpler now. I'm sure it could be
simplified further.

The plugin MIDI setup is more correct.

Most opcodes are now supposed to be plugins. I guess about half of them
actually are. The plugin opcode loading system seems to work on Windows,
Linux, and OS X. John ffitch's  csdl.h file enables one to write opcodes
more or less the same old way as before.

If there's a theme here, it's that Csound is more and more a self-contained
library as well as an application, and its interfaces to the outside world
are increasingly well defined.

The FLTK opcodes seem to work on Windows, and I would guess they either work
on Linux and OS X, or could very easily be fixed.

My CsoundVST is integrated into CVS and the build system, and builds and
runs on both Windows and Linux, and works as a VST plugin or as a standalone
frontend with builtin Python scripting.

There is a whole new build system by me that uses SCons and evidently works
on Linux, Windows, and OS X.

There's new documentation by me in csound.pdf on how to obtain. build,
install, run, and program with Csound and CsoundVST - to be used with
existing documentation!

I don't think that the "engine" itself or the opcodes themselves have
changed much. I know John ffitch wants to simplify the engine by using a
real parser. I suppose that would be his next step.

As soon as live MIDI performance is feasible, I'm going to prepare file
releases for Windows and Linux and put them up on SourceForge as a beta
release.

My next steps will be adding some opcodes: Loris, perhaps other
analysis/resynthesis opcodes, all the C++ STK instruments and effects,
Gabriel's Python opcodes. I also plan to have some kind of Mathematica
interface. Built-in Jack would be nice too. Flext could be used to make a
native PD unit out of the Csound API or even CsoundVST.

I'm more interested in the usefulness of Csound for the kind of algorithmic
music I make than I am in the internals.

----- Original Message ----- 
From: "Matt J. Ingalls" 
To: "Csound Developers Discussion List" 
Sent: Thursday, May 06, 2004 3:40 PM
Subject: [CSOUND-DEV:4577] csound5


>
> this bus discussion makes want to bring up something --
>
> am i wrong in thinking that csound5 is an opportunity to 'slash and burn'
> a lot of code and csound language into something less redundant, more
> simple, and hopefully more elegant?
>
> i already alluded to reducing all a-rate and k-rate i/o into just one
> 'out' and one 'in' opcode.  i also think this would be a great time to get
> string parameters implemented wherever possible - i should have
> been making a list, but 'named' functions and then 'named' bus channels
> come to mind ..
>
>
> -m
>
>
>
>