Thanks for your summary and thoughts.

I see no need for PortAudio version 19 if it is hard to build or use; I
suggest we use version 18 instead.

I vote for libsndfile, with which I have had excellent results; no prejudice
to Dobson's code, just that I know libsndfile has worked for me and appears
to have much functionality.

I like the idea of trying to use PortMidi.

I suggest that I/O be defaulted to PortAudio, libsndfile, and PortMidi
implementations, but allow plugin replacement implementations.

About the bus idea, do you think that ftables could serve this purpose with
the addition of some new API functions to read and write them?

    MYFLT *csoundGetFtable(int tablenumber);
    int csoundGetFtableLength(int tablenumber);
    MYFLT csoundReadFtable(int tablenumber, int index);
    void csoundWriteFtable(int tablenumber, int index, MYFLT value);
    void csoundSetFtablePin(int tablenumber, int index MYFLT *pin); //
updates *pin with value of indexed table slot at krate
    void csoundClearFtablePin(int tablenumber, int index, MYFLT *pin);

By convention, table 0 or -1 or something could be 1024 slots and
pre-allocated as a bus that would not need to be declared in orc code; its
slots could also be aliased with global variable names such as "bus_0",
"bus_1", and so on.

Or is this too clunky?

I suggest we use wxCsound as the front end; it should not be too hard to
port to FLTK; CsoundVST also could be used as a front end (it runs
standalone and already uses FLTK) but has additional dependencies (boost,
Python).

I think you underestimate the importance of configuration. Once we have
achieved a stable GNU build system, Csound will be much easier for most
developers to build and install than it has been; also, adding new files or
new targets to the Csound build system will be much simpler.

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: 
To: "Csound Developers Discussion List" 
Sent: Tuesday, December 16, 2003 8:23 AM
Subject: [CSOUND-DEV:3776] REVIEW


> As the year is ending I really think we need to review where we are on
> the csound5 project.
>
> In Jun I wrote the following list of tasks:
>       a) Parser -- expected to start work in mid July
>       b) Sound file library
>       c) Completion of Portaudio v19
>       d) Software bus
>       e) Check mac build
>       f) Check Windows build
>       g) Reorganisation of opcodes again
>       h) separation of API
>
> Current state:
>
> a) has had little effort (I lost the summer in MSc students) but I
> think it is getting worse.  I have the design for the parser which can
> have user-supplied opcodes but I have not have space to build it.
>
> b) We still need to have a consensus on the sound library.  Options
> include de Castro's sndlib and Dobson's PortSF
>
> c) I backed off portaudio v19 as I could not get the blocking output
> to run.  At present v18 is working at least in part.  This needs to be
> fixed.
>
> d) The need for a software bus is getting stronger, but I have no
> proposals of a design, let alone any code.  I really want to remove
> the FLTK widgets and the controls outside the main system, and replace
> by generic bus opcodes
>
> e) I can build csound5 on OSX so at present I consider this closed
>
> f) I find the Windows situation confused.  I use MSVC on Windows, but
> there seems to be a move towards gcc.  I am trying to keep out of
> this!
>
> g) Moving of opcodes to loadable is largely done, but there still
> remains examples that can be moved
>
> h) The API seems to have had some development, and the loadable opcodes
> all now use a single interface.  I need to move the base code to
> position of re-entrance.
>
> I will also add
>
> j) Replacing all the MIDI by PortMIDI would be a good idea.  I am not
> a MIDI user except rarely, so I am looking for a MIDI person to look
> into this.
>
> k) I want to build a Linux version which uses a separate front end,
> probably FLTK-based, to show the shape of the system.  Ideally I would
> like Csound to exist only as a DLL/.so with a simple command line and
> a simple GUI as part of the main distribution.
>
> I am not very happy with the current state.  A great deal of effort
> seems to have been given to configuration, and comparatively much less
> to creating a system
>
> ==John ffitch
>

"Michael Gogins"  writes:

> I think you underestimate the importance of configuration. Once we
> have achieved a stable GNU build system, Csound will be much easier
> for most developers to build and install than it has been; also,
> adding new files or new targets to the Csound build system will be
> much simpler.

Let me sound a note of optimism by predicting that the configuration
task can be completed fairly quickly.  There must be some silly trick
I'm missing, which will enable the building of DLLs with Cygwin in the
csound module.  I'm sure someone will figure it out the trick real
soon now, and I plan to keep at this until the problem is resolved.

The incorporation of an automake-based GNU build system into the
csound5 module need not wait until we've figured out how to build DLLs
with Cygwin.  Once a directory structure has been selected and
implemented, it will be easy to adapt the configure.ac and various
Makefile.am in the csound module to serve the needs of the csound5
module.

After completing any duties assigned to me during the csound5
configuration task, I promise to carefully investigate moving wxCsound
to FLTK.  I guess this program should be named flCsound, right?  As I
stated before, I see advantages in using FLTK over wxWindows too.  For
example, in wxWindows, one should use wxString's instead of ANSI C++
strings.  There is too much wx'isms, so code cannot easily be used
elsewhere.

John

> > g) Moving of opcodes to loadable is largely done, but there still
> > remains examples that can be moved

While the moving of opcodes is largely done, I want to reiterate my
proposal for the mechanism of loading libraries by using an import
statement and load paths versus using the current --opcode-lib
commandline flag.  (I can repost that email if requested).   Using
import statements and not using system-specific library names (.so,
.dll, .dylib) will allow for greater portability of CSD/ORC files, and
explicitly listing what opcode libraries are imported I think makes for
easier figuring out for end-users which opcodes are coming from what
library.  

steven

I would just like to repeat my suggestion that if opcode libraries are 
loaded this way, which I 99% agree with, that if the current i/o opcodes 
are also moved into library, as has been suggested, an exception is made 
here so that backward compatibility is maintained. In other words, 
"import csoundio" (or whatever its called) is assumed, unless there is 
some directive to the contrary.


Richard Dobson



stevenyi wrote:
>>>g) Moving of opcodes to loadable is largely done, but there still
>>>remains examples that can be moved
> 
> 
> While the moving of opcodes is largely done, I want to reiterate my
> proposal for the mechanism of loading libraries by using an import
> statement and load paths versus using the current --opcode-lib
> commandline flag.  (I can repost that email if requested).   Using
> import statements and not using system-specific library names (.so,
> .dll, .dylib) will allow for greater portability of CSD/ORC files, and
> explicitly listing what opcode libraries are imported I think makes for
> easier figuring out for end-users which opcodes are coming from what
> library.  
> 
> steven
> 
> 

how about an auto-import directory?

this could be for both opcode libs and user-def opcodes.
backwards compatibility opcodes could be implemented either way.

On Wed, 17 Dec 2003, Richard Dobson wrote:

> I would just like to repeat my suggestion that if opcode libraries are
> loaded this way, which I 99% agree with, that if the current i/o opcodes
> are also moved into library, as has been suggested, an exception is made
> here so that backward compatibility is maintained. In other words,
> "import csoundio" (or whatever its called) is assumed, unless there is
> some directive to the contrary.
>
>
> Richard Dobson
>
>
>
> stevenyi wrote:
> >>>g) Moving of opcodes to loadable is largely done, but there still
> >>>remains examples that can be moved
> >
> >
> > While the moving of opcodes is largely done, I want to reiterate my
> > proposal for the mechanism of loading libraries by using an import
> > statement and load paths versus using the current --opcode-lib
> > commandline flag.  (I can repost that email if requested).   Using
> > import statements and not using system-specific library names (.so,
> > .dll, .dylib) will allow for greater portability of CSD/ORC files, and
> > explicitly listing what opcode libraries are imported I think makes for
> > easier figuring out for end-users which opcodes are coming from what
> > library.
> >
> > steven
> >
> >
>
>

On 12/17/03 6:34 PM, Matt J. Ingalls etched in stone:

> 
> 
> how about an auto-import directory?
> 
> this could be for both opcode libs and user-def opcodes.
> backwards compatibility opcodes could be implemented either way.

I think that this is a very good idea.  Most of the old opcodes being
converted into plugins could then be installed by default in the auto-import
directory to maintain compatibility.  This would not deny a user the freedom
though to move them elsewhere and import as needed.

Anthony Kozar
anthony.kozar@utoledo.edu