I have been reading all the messages about the proliferation of plugin types
and looking at the code, I see some things that leave me concerned.

We now have opcode plugins, fgen plugins, rtaudio plugins, and I see that
fft plugins are on the table.  To that list I would like to add cscore
plugins and I can imagine rtmidi and other plugin types will appear in the
future.  It is also clear that sometimes it will be desirable to have more
than one type of plugin code in the same library (eg. opcodes and fgens).

The concerns that I have are where all these libraries will be stored and
how Csound will identify which type of code is in a library.  Also, managing
libraries where MYFLT is float vs double needs to be addressed better, I
think.  Maybe some of this hass already been addressed by recent changes,
but I cannot tell by looking at the code.

Storing all of the types in the same directory seems like a good idea to me
(and is how things seem to be done currently), but then the OPCODEDIR
environment variable seems like a misnomer.  Of course, then Csound has to
have an interface for discovering what types of loadable code are in a
library.  Storing them in separate directories would seem too complicated to
me but would alleviate any need to distinguish types programatically.

What concerns me most right now is the following code in
csoundLoadExternal():

    /* deal with fgens if there are any, */
    /* signalled by setting top bit of length */
    if (length<0) {
      NGFENS *(*nfgens)(ENVIRON*);
      length = length&0x7fffffff; /* Assumes 32 bit */
      nfgens = csoundGetLibrarySymbol(handle, "fgen_init");
      if (nfgens) {
        int allocgen(ENVIRON *, char *, void(*)(void));
        NGFENS *names = (*nfgens)(csound);

Csound 5 is already being compiled on 64-bit integer machines so this is not
a good solution.  And I am strongly opposed to the use of any "magic
numbers" and such.

I think that it would be better to have all plugin modules share a function
that can be called to query their contents.  Something like

int  library_contents( short type );

and define an enumeration of types:

enum library_types {
  OPCODE_PLUGIN = 0,
  FGEN_PLUGIN = 1,
  FFT_PLUGIN = 2, 
  CSCORE_PLUGIN = 3,
  ...
}

Csound would first find the library_contents symbol and then call it for
each value of the enumeration.  library_contents would return true (1) if
that type of code is present and false (0) if not.  Plugins should return
false for any value of 'type' that they do not recognize.

I see the benefits of this system as follows:

*  Clear interface for querying libraries.
*  No machine-dependent code.
*  Easy to add new plugin types without breaking any existing libraries.
*  Not likely to run out of room for specifying types (should be at least
   32768 possible enums).

I had considered having library_contents return a 'long' with different bits
indicating different types, but this method has the disadvantages of being
more complicated to code for the plugin author, 'long' being different sizes
(thus people may make mistakes in the bit manipulation code that assume a
particular size), and we could run out of room for plugin types.

Finally, I think we should add at least one more required function to the
plugin interface:

size_t  myflt_size();

This could be part of the LINKAGE macro:

size_t  myflt_size() { return sizeof(MYFLT); }

Csound should then always check the return value of this function and make
sure that it matches itself before continuing to load any other code from a
library.

Please reply with your comments or concerns.  (But please don't implement
any changes until this has been discussed some more!)

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Anthony,

Istvan already implemented a new plugin format that delegates to the
plugin what to do, passing in the csound pointer and the plugin
calling API functions to append opcodes, fgens, etc.  The functions
called are csoundModuleCreate and csoundModuleInit in the loaded
library.

As for OPCODEDIR, there's already OPCODEDIR64 to differentiate where
to load from.  But OPCODEDIR is a misnomer; perhaps CSLIBDIR and
CSLIBDIR64 would be more appropriate.  Any vote on this?

steven


On Fri, 18 Mar 2005 15:36:45 -0500, Anthony Kozar
 wrote:
> I have been reading all the messages about the proliferation of plugin types
> and looking at the code, I see some things that leave me concerned.
> 
> We now have opcode plugins, fgen plugins, rtaudio plugins, and I see that
> fft plugins are on the table.  To that list I would like to add cscore
> plugins and I can imagine rtmidi and other plugin types will appear in the
> future.  It is also clear that sometimes it will be desirable to have more
> than one type of plugin code in the same library (eg. opcodes and fgens).
> 
> The concerns that I have are where all these libraries will be stored and
> how Csound will identify which type of code is in a library.  Also, managing
> libraries where MYFLT is float vs double needs to be addressed better, I
> think.  Maybe some of this hass already been addressed by recent changes,
> but I cannot tell by looking at the code.
> 
> Storing all of the types in the same directory seems like a good idea to me
> (and is how things seem to be done currently), but then the OPCODEDIR
> environment variable seems like a misnomer.  Of course, then Csound has to
> have an interface for discovering what types of loadable code are in a
> library.  Storing them in separate directories would seem too complicated to
> me but would alleviate any need to distinguish types programatically.
> 
> What concerns me most right now is the following code in
> csoundLoadExternal():
> 
>     /* deal with fgens if there are any, */
>     /* signalled by setting top bit of length */
>     if (length<0) {
>       NGFENS *(*nfgens)(ENVIRON*);
>       length = length&0x7fffffff; /* Assumes 32 bit */
>       nfgens = csoundGetLibrarySymbol(handle, "fgen_init");
>       if (nfgens) {
>         int allocgen(ENVIRON *, char *, void(*)(void));
>         NGFENS *names = (*nfgens)(csound);
> 
> Csound 5 is already being compiled on 64-bit integer machines so this is not
> a good solution.  And I am strongly opposed to the use of any "magic
> numbers" and such.
> 
> I think that it would be better to have all plugin modules share a function
> that can be called to query their contents.  Something like
> 
> int  library_contents( short type );
> 
> and define an enumeration of types:
> 
> enum library_types {
>   OPCODE_PLUGIN = 0,
>   FGEN_PLUGIN = 1,
>   FFT_PLUGIN = 2,
>   CSCORE_PLUGIN = 3,
>   ...
> }
> 
> Csound would first find the library_contents symbol and then call it for
> each value of the enumeration.  library_contents would return true (1) if
> that type of code is present and false (0) if not.  Plugins should return
> false for any value of 'type' that they do not recognize.
> 
> I see the benefits of this system as follows:
> 
> *  Clear interface for querying libraries.
> *  No machine-dependent code.
> *  Easy to add new plugin types without breaking any existing libraries.
> *  Not likely to run out of room for specifying types (should be at least
>    32768 possible enums).
> 
> I had considered having library_contents return a 'long' with different bits
> indicating different types, but this method has the disadvantages of being
> more complicated to code for the plugin author, 'long' being different sizes
> (thus people may make mistakes in the bit manipulation code that assume a
> particular size), and we could run out of room for plugin types.
> 
> Finally, I think we should add at least one more required function to the
> plugin interface:
> 
> size_t  myflt_size();
> 
> This could be part of the LINKAGE macro:
> 
> size_t  myflt_size() { return sizeof(MYFLT); }
> 
> Csound should then always check the return value of this function and make
> sure that it matches itself before continuing to load any other code from a
> library.
> 
> Please reply with your comments or concerns.  (But please don't implement
> any changes until this has been discussed some more!)
> 
> Anthony Kozar
> anthony.kozar@utoledo.edu
> http://akozar.spymac.net/
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

 > rtmidi and other plugin types will appear in the future.

There are already rtmidi plugins, and this is not even a particularly new
feature.

> The concerns that I have are where all these libraries will be stored and
> how Csound will identify which type of code is in a library.  Also, managing
> libraries where MYFLT is float vs double needs to be addressed better, I
> think.  Maybe some of this hass already been addressed by recent changes,
> but I cannot tell by looking at the code.

There are two plugin directories, OPCODEDIR for MYFLT=float and OPCODEDIR64
for MYFLT=double. If OPCODEDIR64 is not defined then plugins with double
precision will also be loaded from OPCODEDIR, but with a warning message.
The environment variables can be renamed if you find some other name
preferable, although this would of course require users to change their setup.
Separate directories for plugins with different MYFLT size is not a new
thing, but you apparently did not follow Csound5 changes.

Also, the new interface defined in csmodule.h does not make assumptions
about the purpose of an external module. The plugin has full access to
the API, and can register new opcodes (csoundAppendOpcode) or GENs (this
one still needs some work), set up callback functions for real time audio
or MIDI, etc. It can even add new command line options.

> What concerns me most right now is the following code in
> csoundLoadExternal():
> 
>     /* deal with fgens if there are any, */
>     /* signalled by setting top bit of length */
>     if (length<0) {
>       NGFENS *(*nfgens)(ENVIRON*);
>       length = length&0x7fffffff; /* Assumes 32 bit */
>       nfgens = csoundGetLibrarySymbol(handle, "fgen_init");
>       if (nfgens) {
>         int allocgen(ENVIRON *, char *, void(*)(void));
>         NGFENS *names = (*nfgens)(csound);
> 
> Csound 5 is already being compiled on 64-bit integer machines so this is not
> a good solution.  And I am strongly opposed to the use of any "magic
> numbers" and such.

This code will actually work without problems on 64 bit machines.
While it does limit the number of GEN routines that can be added,
who needs billions of new GENs anyway ? :-)

> Finally, I think we should add at least one more required function to the
> plugin interface:
> 
> size_t  myflt_size();
> 
> This could be part of the LINKAGE macro:
> 
> size_t  myflt_size() { return sizeof(MYFLT); }

Actually, the Csound API has a function csoundGetSizeOfMYFLT(), which tells
exactly what the name says, the size of MYFLT with which the Csound library
was compiled. The plugin can then decide whether it works with that size or
not, or be able to handle both cases. Of course, with OPCODEDIR64, this issue
is not of critical importance.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net