Hi Michael and All,

Just to comment on a few things:

> In my view, CsoundVST contains functionality that belongs in a separate frontend (the VST plugin technology) and functionality that belongs in the core, default distribution of Csound (the language interfaces for LISP especially, Python, Java, and Lua). That is why I am moving the wrappers out of CsoundVST and into "canonical Csound".
>
> If the wrappers are not in the default distribution, composers will not quickly learn about them or learn to use them, and a good deal of musical potential will go unused.

I would like to say that from my point of view, I think that the main
library should be C only, with other wrapper libraries generated
linking to that.  The wrapper libraries can and should be packaged in
with the installer targets. This is I believe Istvan's side of this
argument.

Precedents for having wrapper libraries separate from the main library include:

-Gnome (pygnome, guile-gnome, etc.)
-KDE/QT (pykde, pyqt, ruby-qt)

Host languages such as Java and Python require secondary files in the
host language anyways (Java needs a compiled .class file or .jar,
python needs .py files, your Lisp binding seems to need a .lisp file).
I see no reason why a second .dll or .so would be that much of a
burden.

Also, it doesn't make sense to me design wise to have these functions
in the core library.  The csound engine does not depend on the
bindings to function, while the wrappers depend on the library to
function.  I think the build system should reflect that as well, and
requiring these dependencies complicates unnecessarily in my opinion.


> What I propose is that the language wrappers be built into the core of Csound. They are not "front ends", they are enabling technology for "front ends" and they need to be standardized and universally available, just like we need a standard piano keyboard or standard music notation, and for exactly the same reasons.

I see a difference between the wrappings and the front ends as well. 
I propose a separate wrappings directory that contains only wrappings.
 So:

/csound
  /frontends
  /wrappings

I also think we need to split the Sconstruct into sub files to reflect
this.  The main SConstruct file serves too many purposes IMO.  The
main SConstruct can be made to call sub-SConstruct files.  We could
and I thinks hould build separate SConstruct files for each of the
frontends as well as the wrappings.  Even if some of the logic is
duplicated for dependency checking, I think it will be more orderly.

I would like to see the build do this in order:

-build libcsound as a dynamic *and* static library
-frontend sconstruct files then depend on libcsound to build first,
then the sconstruct files for each frontend can proceed to build only
using API and linking dynamically or statically as desired
-wrappings built in similar fashion, depending on libcsound

If your frontend depends in any way on a wrapping, then that should be
fine as the wrapping would then call on libcsound to build, etc.

> Even more importantly, and even more of a reason to be in the core, is that the language wrappers can be directly used by composers to make pieces -- just like the orchestra language of Csound itself. The language wrappers are thus not a front end, they are a musical instrument.

This should still be fine if the wrappers are packaged with the
installation targets.  If the wrappings are reordered, they should
still be easy to build for users who want to build from CVS and still
use wrappers.

> Other widely used software synthesis systems already provide a composing language (Max/MSP, Common Music/Common Lisp Music, SuperCollider). If Csound doesn't at least provide a standard exposure in languages used by composers, it will not compete successfully with these other systems.
>
> In my experience, these other systems do not provide as much synthesis power as Csound does, but they do provide more composing power. Integrating Csound into composing languages, such as a tighter integration with Common Music or with athenaCL, should provide a system with unequalled power both for synthesis and for composing.

I am not quite convinced that Csound has to have all of this built in.
 I've been using python and java with Csound externally from blue for
a long while now and I know users of blue are using CMask, Common
Music, Lisp, Python, and other languages all from blue in a single
file and in a single work environment. AthenaCL and CommonMusic
already can call Csound in a single run from their respective
environments/work files.

> The 3rd party dependencies involved in the wrappers that I am creating are minimal. They are C++ (we already have it), Python (we already have it), libstdc++, and SWIG. The C++ standard library is found in all compliant C++ compilers, and on all up to date Linux systems. It can and should be statically linked, so there is no install time dependency. There is also no install time dependency on SWIG, which is open source, runs on everything, and works fine. So, the wrappers require one build time dependency and no install or run time dependencies.

In contrast to the above, having the correct SWIG and correct Python
(2.3) for the above have already bitten a number of people building
CsoundVST.  I know I've stopped building CsoundVST on Linux because I
can't for the life of me get it to use Python23 for building and
linking though it is on my computer.

Many Linux users have Python2.4 now on their systems and for those
using older distributions they may have Python2.3 but not have a
correct version of SWIG available in their easy to use package
repositories.

These are not incredibly difficult dependencies to solve, but they're
enough to me be not worth having in the core library.

> My feeling about this discussion is that there are some important Csound developers who don't do a lot of composing, so they may not understand how much time is saved by having a whole project in one file, or not having to "shell" out or fiddle around to render a piece, fix it, and render it again, or having the ability to control Csound from the same code that controls Loris or other software as well.

I agree having everything in one file and rendering is *INCREDIBLY*
useful.  I do not agree that shelling out is difficult or causes many
problems.  It may limit technically some possibilities in regards to
realtime possibilities, particularly the things that MacCsound does
with widgets in a host communicating to the engine, but for most other
uses, there is no techniques which are limited.  (I.e. for the way I
work, I still have to rerender the whole CSD and run Csound from
scratch even if using the API, as I always want all changes to ORC and
SCO to be in sync).

Just a few thoughts from my side.

Thanks!
steven


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net