I appreciate the work you're doing with Csound, which needs more developers.

What I would prefer is the original solution of defining these functions so
that they can be used both by opcode authors and Csound itself. If you are
agreeable with that, put the functions in their own file and change the
plugin loader to use them. If you don't want to change the plugin loader, or
you don't think this is a good idea, then feel free to remove the functions.
My main goal is that the plugin loader works well. After that, I want the
code in Csound to be consistent, i.e. I want Csound and plugins to use the
same code for loading libraries. In other words, if the functions stay in
the API, then the plugin loader should use them; if the plugin loader uses
native calls, the functions should be removed from the API or permanently
stubbed out and the opcodes also should use native calls.

Please let me know what you think. By the way, do you make a Mac OSX build
of wxCsound?

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
Silence, a language for programming music and sound
Available at http://sourceforge.net/projects/silencevst/
============================================


----- Original Message ----- 
From: "John D. Ramsdell" 
To: "Csound Developers Discussion List" 
Sent: Tuesday, November 04, 2003 2:01 PM
Subject: [CSOUND-DEV:3269] Re: ccsound.c


> "gogins@pipeline.com"  writes:
>
> > If you define LOSE_LOAD_LIBRARY,
>
> It means use the stubs in load_opcodes.c.  I placed the stubs there a
> while ago, but I'll move them if you want.  I'll change the name of
> the defined symbol too.  Just tell me what you prefer.  Then again,
> Steven may be solving this problem as we correspond.
>
> John
>
> >From load_opcodes.c line 159.
>
> #elif defined LOSE_LOAD_LIBRARY
>
> void *csoundOpenLibrary(const char *libraryPath)
> {
> return 0;
> }
> void *csoundCloseLibrary(void *library)
> {
>    return 0;
> }
> void *csoundGetLibrarySymbol(void *library, const char *procedureName)
> {
> return 0;
> }
> #endif
>
>
> > I take it that means dynamically loaded
> > plugin opcodes don't function? Or do they use other functions? If they
use
> > other functions, it would be less confusing to use another name for your
> > macro. If they don't function, they should; you could either move the
> > functions into csound.c or make another.c file with them.
> >
> > Original Message:
> > -----------------
> > From:  ramsdell@mitre.org (John D. Ramsdell)
> > Date: 04 Nov 2003 12:22:07 -0500
> > To: csound-dev@eartha.mills.edu
> > Subject: [CSOUND-DEV:3266] Re: ccsound.c
> >
> >
> >
> > stevenyi  writes:
> >
> > > Hi John R and all,
> > >
> > > Trying out ccsound.c, the linker is missing a few functions.
> > >
> > > oload.o(.data+0x1d0): undefined reference to `csoundOpenLibrary'
> > > oload.o(.data+0x1d4): undefined reference to `csoundCloseLibrary'
> > > oload.o(.data+0x1d8): undefined reference to `csoundGetLibrarySymbol'
> > >
> > > These are available in jpff_glue.c.  What I had done previously to
> > > replace jpff_glue.c with csound.c was to copy these three functions
into
> > > csound.c.  (They're empty stubs, so shouldn't be a big deal).
> > >
> > > These seem appropriate to place in csound.c and not ccsound.c.
> >
> > To avoid this problem, I build my library with -DLOSE_LOAD_LIBRARY.
> >
> > When I build without real time support and without -DLINUX, I also build
> > with -DLOSE_MIDI_TTY.
> >
> > Sorry, I should have not made people guess these procedures.  I just
> > quickly knocked off the code and contributed it as I found it useful.
> > (It's stolen from the looping driver that shows the bug on Windows
> > with MinGW.)
> >
> > John
> >
> >
> > --------------------------------------------------------------------
> > mail2web - Check your email from the web at
> > http://mail2web.com/ .
>

Hi Michael and all,

I realized how I got into all of this, but I'm stuck now.

To get a clarification, there seems to be two sets of files with
analagous functionality:

csound.c
load_opcodes.c

and

jpff_glue.c
dl_opcodes.c

I was using csound.c but using dl_opcodes.c, which got me in a bit of a
mess.  I changed my Makefile now to use csound.c and load_opcodes.c, but
can not figure out where to find the function csoundLoadExternal, which
csoundLoadExternals seems to be dependent on.  Putting in an empty stub
here will allow me to compile but gives a segfault at runtime. 

csoundLoadExternals from load_opcodes.c and the one from dl_opcodes.c
differ in their operation.  The first looks to load from a directory and
takes in a pointer to a csound struct while the second loads from a
comma separated list and takes in nothing.  

[sorry, trying bring up as much information on this to help figure out
what's going on and how to integrate]

Seems to me to get the best integration of the two sets would be to use
load_opcodes.c but replace csoundLoadExternals with the one from
dl_opcodes, but then rewriting csoundLoadExternals to use the functions
from load_opcodes.c, which should get rid of all of the #ifdefs in
csoundLoadExternals.  (yikes, sorry if that's not intelligible!).  

Thanks everyone,
steven



On Tue, 2003-11-04 at 17:06, Michael Gogins wrote:
> I appreciate the work you're doing with Csound, which needs more developers.
> 
> What I would prefer is the original solution of defining these functions so
> that they can be used both by opcode authors and Csound itself. If you are
> agreeable with that, put the functions in their own file and change the
> plugin loader to use them. If you don't want to change the plugin loader, or
> you don't think this is a good idea, then feel free to remove the functions.
> My main goal is that the plugin loader works well. After that, I want the
> code in Csound to be consistent, i.e. I want Csound and plugins to use the
> same code for loading libraries. In other words, if the functions stay in
> the API, then the plugin loader should use them; if the plugin loader uses
> native calls, the functions should be removed from the API or permanently
> stubbed out and the opcodes also should use native calls.
> 
> Please let me know what you think. By the way, do you make a Mac OSX build
> of wxCsound?

Michael,

I have yet to spend any time thinking about or contributing code to
better support plugins.  The only thing I did was provide a compile
time switch that can be used to produce libraries that stub out
undefined references that are created when you try to link in
applications that only define csoundMessage0.  The LOSE_LOAD_LIBRARIES
was added only because I wanted to make the system work with wxCSound,
and did not express an opinion as to whether your interface to dynamic
linking is better or worse that John's.  Steven seems to be more in
tune with the issues.

Having said all that, however, it appears to me all of you are trying
to solve a problem that libtool was designed to address.  It is hard
for me to believe that members of this team can do better job than
what results from the collective effort of developers and users of
libtool.

I do *not* think libtool usage by the Csound project should be
investigated at this time.  It is far easier to employ libtool in a
project that uses automake to create its Makefile.in's.  I'll study
all the existing Makefile.in's in the csound5 module, and report on
the feasibility of generating the Makefile.in's using automake
sometime soon.  My agenda is to make "make install" behave as most
people expect.  My RPM spec file requires standard behavior.  This
agenda explains why I want the top-level Makefile to end up with
definitions for things like $(pkgdatadir) and the like.

> ... By the way, do you make a Mac OSX build of wxCsound?

The only binaries I distribute are for Windows.  Ironically, this is
the only platform on which it has severe memory errors.  I suppose I
should try to build it using Microsoft's build environment, but I'm
loath to install their stuff on my Window 2000 laptop.  Last time I
did that, I ended filling the disk, and one thing led to any other,
and before I knew it, I had to format the disk and reload the
operating system.

In any event, you should be able to easily build wxCSound from its
sources on the Mac.  It's just the usual ./configure followed by make
routine.

I just noticed that I've been writing CSound in various places, and
everyone else writes Csound.  I promise to get with the program, and
rename wxCSound to wxCsound.  Silly me...

John