Michael Gogins already proposed, some time ago, the same concept,
developing a Csound version which supports external dll loading. The
external library provided by Gogins includes all original C++ Perry Cook
tool-kit opcodes.
Then I linked Michael Gogins' external library support to Win95 realtime
MIDI Csound version (RTsound 1.9), so even my version supports external
DLL now. The
problem is how to extend the programming interface to all the other
platforms without introducing too many differences, so the sources of an
external
library of opcodes can be ported to all platforms without a too big
effort.

Another thing I believe to be useful, is to open and close orchestra and
scores without having to restart Csound each time. In this case the time
of loading will be reduced and this will help us especially when writing
and testing new osc/scos. Any idea?

-
Gabriel Maldonado

mailto:g.maldonado@agora.stm.it
http://www.agora.stm.it/G.Maldonado/home2.htm
http://www.geocities.com/SiliconValley/Way/7041/home2.htm

Nicola Bernardini wrote:

> Some months ago I remember a discussion about limiting the
> addition of opcodes to avoid the explosion of entry.c and to keep
> the sources manageable.
>
> Now that practically all systems support dynamic library loading
> (yes I know there is still DOS, but we could consider a work-around
> for that),
> maybe a solution could be to distribute the opcodes in several
> dynamic libraries (libxxx.so under linux, .dlls under Win95, etc.)
> and these libraries could loaded dynamically (w/ dlopen(),dlclose()
> calls)
> as requested by the orcs. The entry table could be substituted by
> a linked list of tables (one for each library) and perhaps a
> configuration
> file to define loading paths and priorities.
>
> This could have a number of advantages:
>
> 1) better structuring of opcode code
> 2) smaller in-core runtime executables when few opcodes are requested
>    (which, paradoxically, could help real-time)
> 3) opcode libraries could be maintained separately
>    by different groups, with better sharing of workload
> 4) even if I personally do not like the approach at all, some
> libraries
>    could be distributed in binary form only when the author(s) do
>    not feel like distributing the sources (think, for example, about
>    the famous ambisonic opcode which cannot exist for patent
> problems...)
>
> The disadvantages are obvious but need some consideration:
>
> 1) system is slower (even if it could be argued that it would only be
>    slower in orchestra loading and not during play)
>
> 2) the package requires some quite thorough definition of how to
>    build libraries, how to call them, etc. otherwise everything is
> bound
>    to end up in chaos
>
> I am willing to help in this endeavour if there is a general agreement
>
> that this thing is useful.
>

On Tue, 10 Feb 1998, Gabriel Maldonado wrote:

> Michael Gogins already proposed, some time ago, the same concept,
> developing a Csound version which supports external dll loading. The
> external library provided by Gogins includes all original C++ Perry Cook
> tool-kit opcodes.
> Then I linked Michael Gogins' external library support to Win95 realtime
> MIDI Csound version (RTsound 1.9), so even my version supports external
> DLL now. The
> problem is how to extend the programming interface to all the other
> platforms without introducing too many differences, so the sources of an
> external
> library of opcodes can be ported to all platforms without a too big
> effort.

I do not see where the too many differences would be: as in the
graphics interface (which is far more diversified between X11, win95,
mac, etc.) the thing to do is well known: make interface routines
to dynamic loading (write a version for each platform), then the
rest of the code (linked list of entry tables, etc.) is absolutely
the same for all platforms. That'll make writing 3-4 functions for
each platform, plus the portable code. The other idea would be to use
a config file for csound, to speed up the loading and to let csound
know which opcodes are available, along with a cache of the opcode
libraries already loaded.

> 
> Another thing I believe to be useful, is to open and close orchestra and
> scores without having to restart Csound each time. In this case the time
> of loading will be reduced and this will help us especially when writing
> and testing new osc/scos. Any idea?

well, this would imply running an eval loop and an in-line editor
(a` la lisp, to be clear). Now *this* implies some work, especially
considering the way the parser is presently written (and has always
been, as far as I know): it's absolutely impossible to modify and
maintain that section of code the way it is written. Which brings
me to another subject: is the csound community interested in attempting
a backward-compatible re-write of the parser using decent tools like
lex (flex) and yacc (bison)? This would allow, after rebuilding the parser,
much better possibilities in extending the language for important
things like array variables, better conditionals, sub-patching
(instrument stacking), parameter field passing with strings, numbers,
variables, etc. Can you imagine what csound would be like with these
constructs? It would have the same impact as switching from
fortran-like Music V to csound itself!

I am available to put some effort into this, but I would like to
understand from this list if this is something effectively useful
to the community (I won't do it for the sake of doing it, I don't care).
I see this list spends a lot of bandwith in discerning the intentions
of =cwlabs42! (or whatever her/his name is) or discussing the true
nature of music, but rarely (almost never) replies to these questions.

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.

Nicola Bernardini wrote:
> been, as far as I know): it's absolutely impossible to modify and
> maintain that section of code the way it is written. Which brings
> me to another subject: is the csound community interested in attempting
> a backward-compatible re-write of the parser using decent tools like
> lex (flex) and yacc (bison)?

It's always hard to argue when somebody else says they'd like to
rewrite an unmaintainable body of code. :-)

> This would allow, after rebuilding the parser,
> much better possibilities in extending the language for important
> things like array variables, better conditionals, sub-patching
> (instrument stacking), parameter field passing with strings, numbers,
> variables, etc.

This would certainly be nice.  Another possibility to consider is
finding a system that's got the language you want, and porting
the missing Csound ugens to it.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/

On Sun, 15 Feb 1998, Eli Brandt wrote:

> Nicola Bernardini wrote:
[snip]
> This would certainly be nice.  Another possibility to consider is
> finding a system that's got the language you want, and porting
> the missing Csound ugens to it.

well, I must say I like the csound language enough...

Nicola

------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.