John Fitch, and other Csound developers, please let me know if you agree,
or disagree, or wish to discuss, the following proposals, which I now have
time to carry out. Some of you may already be involved with similar tasks,
or conflicting tasks, so we will need to coordinate. 

I already working on proposals 1 through 3, which as far as I know do not
conflict with any other work.

1. Change the csound5 autotools build system to use automake and libtool.

2. Add a Doxygen target to the build system.

3. Change the autotools build system to make the Csound API as both a
static library and a shared library using libtool, and to build ccsound
using the static API library. 

4. Replace jpff_glue.c with an improved csound.c, which in turn requires
some redesign of the existing Csound API. At a minimum, the QueryInterface
approach will be used to provide for enhanced future extensibility (new
APIs for bus, drivers, etc.).

5. Replace printf, err_printf, etc. with csoundMessage as I proposed
earlier.

3. Change the directory structure as follows:

   csound5
      bin // All applications and shared libraries.
      doc // Doxygen-generated documentation.
      include // Csound API header file or files.
      lib // All static libraries.
      src // Flat directory structure (easiest for autotools):
          csoundlib // Csound API library
          ccsound // Console Csound
          Plain Csound GUI (jpff version or wxCsound?)
          csoundvst
          csoundvstwin
          adsyn
          convol
          lpc
          pvoc
          strings
          cscore
          scot
          sortex
          dnoise
          envext
          exports
          mixer
          pvlook
          scale
          sndinfo
          plugin opcode 1
          plugin opcode 2
          etc....

6. Move the OPARMS structure into the ENVIRON structure.

5. Finish moving Csound to a multi-instancing design by adding an ENVIRON
pointer to all ENVIRON function pointer parameter lists, and changing
internal code as required.

6. Implement MIDI for Csound5 using the PortMidi library.

7. Add an ftable API (design required).

8. Add a bus API (design required).

9. Add plugin driver APIs for audio, soundfiles, MIDI, and network control
(design required).






--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

"gogins@pipeline.com"  writes:

> John Fitch, and other Csound developers, please let me know if you
> agree...

I agree with one minor amendment.  As I said before, please place the
Csound API header file or files in csound5/include/csound, not
csound5/include.  This makes the --place option in csound-config work,
so one can build add-on packages without having csound installed.

Michael, you'll be happy to know I've made a start on flCsound.  There
is a new CVS module by that name.

John

"gogins@pipeline.com"  writes:

> John Fitch, and other Csound developers, please let me know if you
> agree, ...

Michael,

One more comment.  Please be sure to take time to read configure.ac,
csound/Makefile.am, and csound/csound-config.in in the csound module,
and ask me about anything in them you find non-obvious.  The file
configure.ac contains many changes over configure.in in the csound5
module, and the reason for some of them may seem mysterious.  For
example, can you guess why the presence of -lwinmm is not tested for
by using AC_SEARCH_LIBS and AC_CHECK_LIB?

John

Hi Michael and all,

> 4. Replace jpff_glue.c with an improved csound.c, which in turn requires
> some redesign of the existing Csound API. At a minimum, the QueryInterface
> approach will be used to provide for enhanced future extensibility (new
> APIs for bus, drivers, etc.).

I had started on using csound.c and load_opcodes.c in place of
jpff_glue.c and dl_opcodes.c in csound5.  However, in trying to keep
both options usable, I ran up against a wall.  The problem was in
main.c, as it defines csoundCompile, which is in csound.c, and also that
it is now what csoundMain used to be in csound4.  So using csoundMain
from the API functions doesn't quite work if using csound.c.  

These two diverging source codes are incompatible now, and the more they
continue on separately the more difficult it's going to be for
integration, IMO.  I would prefer to use the csound.c/load_opcodes.c
code and perhaps integrating into it whatever is necessary from
jpff_glue.c/dl_opcodes.c rather than the other way.

FYI: I did spend time updating the code in csound.c in csound5 so it is
a little different than csound4.

steven