csound.h supports BOTH linking with Csound, and calling csoundXXX(...)
functions; AND using the interface pointer, and calling
csound->XXX(csound...) functions.

In retrospect, this seems to have been confusing. If I were doing it all
over again, I would have only csoundCreate and csoundDestroy as library
functions, and all the rest would be interface function pointers in GLOBALS.

It happened that way because I started with csoundXXX, then Richard Dobson
made the suggestion to put the interface function pointers in GLOBALs, and
I liked this idea and adopted it. I probably should have dropped the
csoundXXX functions at that time.

Original Message:
-----------------
From: Matt J. Ingalls ingalls@mills.edu
Date: Wed, 19 Nov 2003 11:57:13 -0800 (PST)
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3413] Re: Csound API Split, design



> And in regards to pushing everything into csound.h, wouldn't that cause
> all the trouble with linking against the host API functions and
> requiring libcsound.a?  It seems that the API for hosts and plugins then

but all the functions you call from csound.h are via a pointer, so you
have no linking issues, or am i not understanding what you are saying?
-m
>
> On Wed, 2003-11-19 at 06:38, gogins@pipeline.com wrote:
> > What you are suggesting works -- but ONLY if Csound ITSELF is a DLL. In
> > other words, the scheme you suggest would work for CsoundVST or some
other
> > DLL version of the Csound API, but it would NOT allow plugin opcodes to
> > automagically link with a statically linked Csound APPLICATION.
> >
> > I would prefer, indeed, that the base object in the Csound world be a
> > Csound API DLL or shared library! And that the command-line version of
> > Csound link dynamically to the API library! But as long as that is not
> > ALWAYS the case, the function pointer scheme IS the lowest common
> > denominator method that WILL work in all cases.
> >
> > Furthermore, linking directly with a DLL across versions, as we
require, is
> > only possible on Windows through the use of a .def file to define
ordinal
> > numbers, which introduces another unnecessary complication. So the
function
> > table scheme is actually simpler (which is why Microsoft adopted it for
> > COM).
> >
> > I considered all these issues when I designed the API, and I took into
> > consideration advice from other Csound developers. As far as I know, the
> > function table scheme is the simplest, most foolproof way to get plugin
> > opcodes that can talk back to Csound across version and across
platforms.
> >
>
>


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

> csound.h supports BOTH linking with Csound, and calling csoundXXX(...)
> functions; AND using the interface pointer, and calling
> csound->XXX(csound...) functions.
>
> In retrospect, this seems to have been confusing. If I were doing it all
> over again, I would have only csoundCreate and csoundDestroy as library
> functions, and all the rest would be interface function pointers in GLOBALS.
>
> It happened that way because I started with csoundXXX, then Richard Dobson
> made the suggestion to put the interface function pointers in GLOBALs, and
> I liked this idea and adopted it. I probably should have dropped the
> csoundXXX functions at that time.

and i was using function pointers in my own code originally [in
its own structure and not including GLOBALS] and ended up
conformed to your way - but i think more time is wasted if i try to
argue issues over email than if i just rewrite my code.

-m


>
> Original Message:
> -----------------
> From: Matt J. Ingalls ingalls@mills.edu
> Date: Wed, 19 Nov 2003 11:57:13 -0800 (PST)
> To: csound-dev@eartha.mills.edu
> Subject: [CSOUND-DEV:3413] Re: Csound API Split, design
>
>
>
> > And in regards to pushing everything into csound.h, wouldn't that cause
> > all the trouble with linking against the host API functions and
> > requiring libcsound.a?  It seems that the API for hosts and plugins then
>
> but all the functions you call from csound.h are via a pointer, so you
> have no linking issues, or am i not understanding what you are saying?
> -m
> >
> > On Wed, 2003-11-19 at 06:38, gogins@pipeline.com wrote:
> > > What you are suggesting works -- but ONLY if Csound ITSELF is a DLL. In
> > > other words, the scheme you suggest would work for CsoundVST or some
> other
> > > DLL version of the Csound API, but it would NOT allow plugin opcodes to
> > > automagically link with a statically linked Csound APPLICATION.
> > >
> > > I would prefer, indeed, that the base object in the Csound world be a
> > > Csound API DLL or shared library! And that the command-line version of
> > > Csound link dynamically to the API library! But as long as that is not
> > > ALWAYS the case, the function pointer scheme IS the lowest common
> > > denominator method that WILL work in all cases.
> > >
> > > Furthermore, linking directly with a DLL across versions, as we
> require, is
> > > only possible on Windows through the use of a .def file to define
> ordinal
> > > numbers, which introduces another unnecessary complication. So the
> function
> > > table scheme is actually simpler (which is why Microsoft adopted it for
> > > COM).
> > >
> > > I considered all these issues when I designed the API, and I took into
> > > consideration advice from other Csound developers. As far as I know, the
> > > function table scheme is the simplest, most foolproof way to get plugin
> > > opcodes that can talk back to Csound across version and across
> platforms.
> > >
> >
> >
>
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
>