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

Michael Gogins wrote:

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

You somehow always avoid explaining what the major disadvantages of
splitting what you consider the "core" of Csound into two separate
libraries (that can, however, both be included in a binary distribution),
where one contains the wrappers and glue code for external languages.
Others seem to generally not oppose this modular design.

Or do you think it gets more attention by unconditionally forcing it
on everyone whether they want it or not ?

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

These assumptions are both wrong. Or did I miss something here ?
I see nothing other than sndfile and standard system libraries.

if (commonEnvironment['dynamicCsoundLibrary'] == '1'):
   print 'CONFIGURATION DECISION: Building dynamic Csound library'
   csoundLibraryEnvironment.Append(LIBS = ['sndfile'])
   if getPlatform() == 'mingw':
     csoundLibraryEnvironment.Append(LIBS = csoundWindowsLibraries)
     csoundLibraryEnvironment.Append(SHLINKFLAGS = ['-module'])
     csoundLibraryEnvironment['ENV']['PATH'] = os.environ['PATH']
   elif getPlatform() == 'linux':
     csoundLibraryEnvironment.Append(LIBS = ['dl', 'm', 'pthread'])
   csoundLibrary = csoundLibraryEnvironment.SharedLibrary('csound',
                                                          libCsoundSources)


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

On Oct 21, 2005, at 1:10 PM, Steven Yi wrote:

> The main SConstruct file serves too many purposes IMO.

Agreed. I don't think CsoundVST or Loris should build by default even 
though in the current CVS module, they do. I also think that the liblo 
headers should be copied to the Csound5 CVS module and they should be 
linked against and build the OSC opcodes by default. Maybe Steve Harris 
doesn't like this idea though...

When we're talking about "competing" with SuperCollider, MaxMSP, or 
these other systems, the OSC opcodes are the single defining link that 
has the potential by itself, as Csound is today to take the language 
farther than those others have yet to.

Also, does anyone have any of the following working on OSX? I had been 
trying but I got too frustrated with trying to build it that I decided 
just to stick with making music.

>> the C++ STK opcodes, fixed up the Loris opcodes for Csound 5, and 
>> contributed to the Fluidsynth opcode.



-David



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