It would also be possible to keep such opcodes in the main module but not
build them if their dependencies are not present, or to have separate build
systems for them (i.e., another directory with another configure.ac).

Can you give me examples of "libraries against csound5?"

============================================
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: "stevenyi" 
To: "Csound Developers Discussion List" 
Sent: Tuesday, February 24, 2004 2:38 AM
Subject: [CSOUND-DEV:4128] CVS Module Request


> Hi John ffitch and All,
>
> I'd like to request a new module for opcode libraries be added to the
> sourceforge cvs, entitled "opcodeLibraries" for lack of better term.  I
> think it'd be a good time to create a central repository for opcode
> libraries.  This would similar to pure-data's cvs repository for
> externals (see
> http://cvs.sourceforge.net/viewcvs.py/pure-data/externals/).
>
> I would like to move my fluidOpcodes opcode lib to said directory as I
> think it really doesn't belong as part of the csound4 cvs.  I would also
> suggest anyone who is interested in creating opcode libraries then could
> also add their opcode libs as a subdirectory to the main opcodeLibraries
> directory.  The Loris Opcodes would also be a prime candidate to be made
> into an opcode library, also to be put into this branch. (I'm assuming
> this branch would be the place to put any opcode library that has
> dependencies external from the ones that Csound has itself.)
>
> I'd also like to suggest that this repository be for building libraries
> against csound5.  Although things are still in flux, I don't see it
> getting in the way as it would be in a different module and would
> provide extra black-box testing against csound via the API.
>
> Any objections/comments would be greatly appreciated.
>
> Thanks,
> steven
>
>
>
>

Hi Michael,

For "libraries against csound5" I mean to say they are with csound5's
csound.h file and meant to be loaded with csound5.  The fluidOpcodes
opcode lib I built against csound4 and was using with csound4 doesn't
work with csound5.  I haven't spent the time yet to figure it out, but
I'm assuming there is some sort of incompatibility.

I would much prefer to have the opcode libraries outside of the main
module, as it keeps it less cluttered.  If the opcode libraries should
eventually ramp up to a large number, I don't want to have to download
all of those when I want to do a fresh cvs checkout of Csound on a new
system to compile just Csound.  Considering it's wise to give test cases
for each opcode library, which may include wav files and other analysis
files, it could get really big really quick.  

steven


On Tue, 2004-02-24 at 05:03, Michael Gogins wrote:
> It would also be possible to keep such opcodes in the main module but not
> build them if their dependencies are not present, or to have separate build
> systems for them (i.e., another directory with another configure.ac).
> 
> Can you give me examples of "libraries against csound5?"
>