Perhaps you could sketch out what you have in mind in
terms of module structure and where things will fit in.
That way it will be clear for us how this is going to pan
out.

Victor

>
> I am happy to discuss the matter in what I hope is a
> reasonable way.
>
> As software grows, it becomes more complex. This makes it
> more powerful, and it also makes it more difficult to
> build, to learn, and to use. These difficulties are
> fundamental and must constantly be fought.
>
> Csound 5 is an excellent example. A decision was made to
> rely on 3rd party libraries for what had been builtin
> soundfile IO, MIDI IO, and graphics. This has made Csound
> considerably more difficult to build. For those who do
> build Csound, however, it has freed us up to make new
> contributions to the musical functionality of Csound.
>
> The complexity of the build results in a situation where
> the identity and functionality of Csound is somewhat
> unclear to users. To clarify the situation, there ideally
> should be a default or canonical installation with a
> well-defined set of capabilities, and with a minimal,
> widely available set of 3rd party dependencies.
>
> 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.
>
> Unfortunately, the Csound build system now sports one of
> the largest and most complex sets of options that I have
> seen in an open source music project.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Regards,
> Mike
>
>
>
>
>
>
> -----Original Message-----
> From: Victor Lazzarini 
> Sent: Oct 21, 2005 9:35 AM
> To: csound-devel@lists.sourceforge.net
> Subject: [Cs-dev] wrappers, frontends etc
>
>
> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
>
> -------------------------------------------------------
> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------
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