Hi John and all,

(I'm replying from work and don't have the email John sent to reply to 
directly)

The messages you were receiving during render that showed that dlopen 
couldn't open files is from how OPCODE_DIR has been implemented.  When 
csound5 goes to load from OPCODE_DIR, it tries to load everything in 
that directory, regardless of extension.  I'm assuming from your output 
that you've currently set the OPCODE_DIR to the csound5 root dir or 
csound5 also loads anything in the current directory (I don't know if 
this is the behavior).  We could add a check for filename extension 
depending on platform (".dll" for windows, ".so" for linux, and ".dylib" 
(?) for MacOSX).  I don't know what extensions are used on other 
platforms (if any, i.e. MacOS9).

Also, in regards to Matt's email to auto-load User-Defined Opcodes or 
named-instruments, we could modify the OPCODE_DIR check to load all 
shared libraries first, then load user-defined opcodes afterwards, thus 
giving user-defined opcodes precedence should someone want to override 
an existing opcode should a name conflict occur (which would be probably 
bad practice anyways, but at least it makes it predictable).  I'll look 
into this when some times frees up and will try to refactor out the 
User-Defined Opcode parsing code into a function (if it isn't it's own 
function already) and add it to the OPCODE_DIR loading code.

steven

On 3/30/04 4:56 PM, steven yi etched in stone:

> We could add a check for filename extension
> depending on platform (".dll" for windows, ".so" for linux, and ".dylib"
> (?) for MacOSX).  I don't know what extensions are used on other
> platforms (if any, i.e. MacOS9).

Libraries conventionally end in "Lib" (not ".Lib" which is apparently a
problem for scons) on Mac OS 9, but this is by no means _required_.  The
proper way to identify a shared library is by its file type (which is
usually 'shlb') or by searching it for a 'cfrg' resource.  There should
never be an attempt on the Mac to load an unknown file such as
"American.xmg" as happened to John.  (This is one of the many benefits of
file metadata).  

Furthermore, are we planning to handle user-specified loading of plugin
opcodes in a more "platform-neutral" way?  Currently, in order to load the
same library, you would have to specify "--opcode-lib=testOpcode.so" on
Linux, "--opcode-lib=testOpcode.dll" on Windows, and
"--opcode-lib=testOpcodeLib" or "--opcode-lib=testOpcode" on the Mac.  For
portability of csd files, it would be nice if you could just specify the
name of the library without an extension like "--opcode-lib=testOpcode" and
let each platform append the appropriate one.

I would also like to make some proposals for plugins on the Mac.  In
addition to having type 'shlb', we may want to have a standard Mac creator
type for opcode plugins such as 'Csnd' or 'CsOp' to make them more easily
identifiable.  This would also allow a custom icon to be assigned for the
plugins.  

Additionally, since we can store any metadata we want in the resource fork
on the Mac, I propose that we develop a standard resource type to be added
to Mac opcode plugins which would provide information to CsoundLib clients
about the plugin.  Useful information would be a short description, a
"prototype" for the opcode showing its input and output parameters with
human-understandable names, etc.  This information could be used by
front-ends to provide online help to users or to perform syntax checking of
orchestras, etc.  One resource should be added to a plugin library for each
opcode that it defines.

Finally, I should note that the file names of libraries on Mac OS 9 is
irrelevant.  You can rename libraries without affecting the OS's ability to
find them.  What IS important is the code fragment name stored in the 'cfrg'
resource.  We should adopt a standard on the Mac for how to name these code
fragments.  Whether we use "testOpcode" vs. "testOpcodeLib", or "MetroLib"
vs. "metroLib", should be standardized.  Additionally, it is important to
realize that two opcode libraries with the same code fragment name would
probably confuse the OS (it would be difficult to load both).

> Also, in regards to Matt's email to auto-load User-Defined Opcodes or
> named-instruments, we could modify the OPCODE_DIR check to load all
> shared libraries first, then load user-defined opcodes afterwards, thus
> giving user-defined opcodes precedence should someone want to override
> an existing opcode should a name conflict occur (which would be probably
> bad practice anyways, but at least it makes it predictable).

This needs to be true anyways so that udos which rely on opcode libraries
are loaded properly, doesn't it?

Anthony Kozar
anthony.kozar@utoledo.edu