The API client programmer does not have to load csound.so in one context, csound_lisp.so or csound_interfaces.so in another context, and so on.

In some languages, the actual shared library name must be passed on the command line (sometimes this is necessary in Java), again it is simpler to have to remember or specify only one name.

As for a simpler story for understanding Csound and how it works, that's obvious. Once you have the Csound API library, you can call it from C, C++, Python, Java, LISP, and Lua. End of story.

The OS has only one module to fixup, also, so it should load a bit faster this way.

Regards,
Mike 

-----Original Message-----
From: Istvan Varga 
Sent: Oct 21, 2005 4:08 PM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] wrappers, frontends etc

Michael Gogins wrote:

> As for the idea, as I did before we got into this argument,
 > I still think it is better to put everything that can reasonably
 > be interpreted as the Csound API, regardless of language interface,
 > into one library. It is just simpler. A simpler build, a simpler
 > installation, a simpler runtime configuration, and a simpler story
 > about what Csound can do.

In exactly what way does it make installation and runtime configuration
simpler (I admit that the modular way is slightly more complex as far
as build scripts are considered, but not more than the difference between
for example a plugin opcode or a built-in one) ?


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

> In some languages, the actual shared library name must be passed
 > on the command line (sometimes this is necessary in Java), again
 > it is simpler to have to remember or specify only one name.

Well, then you load the wrapper library. It either statically links
against (and thus contains) the main library, or it is dynamically
linked in which case the operating system should automatically load
its dependencies including libcsound. In any case, the only difference
is probably the file name.

> The OS has only one module to fixup, also, so it should load a bit faster this way.

Only if the wrappers link dynamically against the main library, and even
then the difference is not likely to be noticeable. More importantly, if
someone does not want to use the wrappers (a case that, while you seem not
to care about, can easily occur) it also works the other way around: not
having to load the Python library, libstdc++, and whatever else allows for
slightly faster loading times. But then again, this is not expected to be
significant either way, particularly considering the 100 or so plugin
libraries. Or should we move back all plugin opcodes into the API library ?
Following your logic that should be done.


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