|
Disregarding completely the flames and rage, I'd like to propose we
discuss the question of wrappers and where they might sit in the
csound 5 distribution, since this seems to be a major issue now.
My suggestion (and the way I have been adding things) is to add
wrappers and interfaces to other languages as csound frontends.
The csoundapi~ frontend is a class in the PD language that
encapsulates (part of, at the moment) the Csound API. It sits
in the frontends directory to be built as an optional component,
and hopefully will be available in the binary distributions. CsoundVST,
seems to work in the similar fashion, providing a csound-aware
python interpreter. Tclcsound is another example, providing extended
a tcl command set that uses the API, for tclsh and wish.
Now the question is: would it be possible to provide all other similar
things, wrappers, etc, in the same fashion? For instance, for
Common LISP, you can build an interpreter/lisp environment, offering
it as a csound frontend. The projects then can be maintained and
kept in sync with csound 5, but at the same time, they can be
optional.
What other options do we have? It would be good to see the alternatives.
For instance, are we talking about two different types of things, language
wrappers/interfaces and frontends, that cannot be treated the same
way in the csound project?
Let's discuss this (and any other matters that may arise).
Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth
-------------------------------------------------------
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 |