You are literally re-inventing C++ - your suggestion reminds me of the
CFront compiler, which used macros to implement classes in C!

If we want this degree of convenience, and I certainly do, I think it would
be better to define a simple C++ API that could compile on all platforms.

I have already done this, in the form of the CppSound class in the
CsoundVST directory in SourceForge CVS for csound.

CppSound, however, may provide more than you want in that it also drives
from CsoundFile, a C++ class that manages Csound files and command lines in
memory. Or you may want the file management also (it is required for
anything like a VST plugin). But the CsoundFile class depends on the
standard C++ library and uses templates. Still, I think it would compile on
all current Csound platforms.

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



it probably is possible to create a file of macro definitions or simple
c functions we could distribute as part of an SDK to include in
plugins/hosts sources that wrap the function pointer stuff.

for instance, may a C++ class that would have functions like:

#include csound.h

int Csound::GetKsmps()
{
  return mCsound->csoundGetKsmps(mCsound);
}

and i guess a macro would be

#define GetKsmps(x) x->csoundGetKsmps(x);
???

-m

On Wed, 19 Nov 2003, 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.
>
>
> Original Message:
> -----------------
> From: stevenyi stevenyi@csounds.com
> Date: Tue, 18 Nov 2003 21:11:06 -0800
> To: csound-dev@eartha.mills.edu
> Subject: [CSOUND-DEV:3397] Re: Csound API Split, design
>
>
> > As for linking with libcsound.a at run time, that sort of thing is
> standard
> > on Linux and Unix, but on Windows, you can't link at run time without
> either
> > (a) coding with LoadLibrary and GetProcAddress, or (b) linking with a
> static
> > import library. The Csound scheme should work on all platforms and
> therefore
> > must be a lowest common denominator, which means exporting only
functions
> > and having the host push the function table into the plugin so that
these
> > issues need not arise.
>
> Yikes!  I didn't realize windows dll's were so nuts. I started reading
> into static import libraries and DEF files and __declspec(dllexport) and
> __declspec(dllimport) and it's quite a chore. I did find this though:
>
> http://cygwin.com/ml/cygwin/2000-06/msg00688.html
>
> and if I understand it correctly, we'd be able to get rid of the
> function pointers in the GLOBAL struct and have all the symbols exported
> and imported and linked correctly for windows.  Granted, for windows
> opcode plugin developers they would have to add -DUSEDLL compiler flag,
> but that's nothing compared to having to make the jump to using function
> pointers.
>
> This seems like it would also be as future-proof as your function table
> system, i.e. as long as none of the exported functions are removed,
> you're fine.  It does have the advantage of not needing to rely on
> maintaining the order of function pointers in the GLOBAL struct.
>
> I really hope this will work out as a possible solution.  I think the
> study of building an Opcode Plugin, say, at a University electronic
> music/programming course would be greatly eased if they didn't have to
> deal with function pointers and the syntax that surrounds their use.
> Also, I think this will be much easier to generate doxygen documentation
> for as we could do it per-function as opposed to one large doc that
> would have to explain every entry in the whole GLOBAL struct.
>
> Thanks,
> steven
>
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
>


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

> You are literally re-inventing C++ - your suggestion reminds me of the

no, im USING c++... in the top example.  the bottom macro definion was a
entirely different approach.

> CppSound, however, may provide more than you want in that it also drives
> from CsoundFile, a C++ class that manages Csound files and command lines in

yea, all i was suggesting was a wrapper class for the api for those who
didnt want to see function pointers.  john's macros are fine except for
hosts managing multiple instances [and multiple global structs]

-m

> From: Matt J. Ingalls ingalls@mills.edu
> Date: Wed, 19 Nov 2003 11:45:51 -0800 (PST)
> To: csound-dev@eartha.mills.edu
> Subject: [CSOUND-DEV:3412] Re: Csound API Split, design
>
>
>
> it probably is possible to create a file of macro definitions or simple
> c functions we could distribute as part of an SDK to include in
> plugins/hosts sources that wrap the function pointer stuff.
>
> for instance, may a C++ class that would have functions like:
>
> #include csound.h
>
> int Csound::GetKsmps()
> {
>   return mCsound->csoundGetKsmps(mCsound);
> }
>
> and i guess a macro would be
>
> #define GetKsmps(x) x->csoundGetKsmps(x);
> ???
>
> -m
>
> On Wed, 19 Nov 2003, 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.
> >
> >
> > Original Message:
> > -----------------
> > From: stevenyi stevenyi@csounds.com
> > Date: Tue, 18 Nov 2003 21:11:06 -0800
> > To: csound-dev@eartha.mills.edu
> > Subject: [CSOUND-DEV:3397] Re: Csound API Split, design
> >
> >
> > > As for linking with libcsound.a at run time, that sort of thing is
> > standard
> > > on Linux and Unix, but on Windows, you can't link at run time without
> > either
> > > (a) coding with LoadLibrary and GetProcAddress, or (b) linking with a
> > static
> > > import library. The Csound scheme should work on all platforms and
> > therefore
> > > must be a lowest common denominator, which means exporting only
> functions
> > > and having the host push the function table into the plugin so that
> these
> > > issues need not arise.
> >
> > Yikes!  I didn't realize windows dll's were so nuts. I started reading
> > into static import libraries and DEF files and __declspec(dllexport) and
> > __declspec(dllimport) and it's quite a chore. I did find this though:
> >
> > http://cygwin.com/ml/cygwin/2000-06/msg00688.html
> >
> > and if I understand it correctly, we'd be able to get rid of the
> > function pointers in the GLOBAL struct and have all the symbols exported
> > and imported and linked correctly for windows.  Granted, for windows
> > opcode plugin developers they would have to add -DUSEDLL compiler flag,
> > but that's nothing compared to having to make the jump to using function
> > pointers.
> >
> > This seems like it would also be as future-proof as your function table
> > system, i.e. as long as none of the exported functions are removed,
> > you're fine.  It does have the advantage of not needing to rely on
> > maintaining the order of function pointers in the GLOBAL struct.
> >
> > I really hope this will work out as a possible solution.  I think the
> > study of building an Opcode Plugin, say, at a University electronic
> > music/programming course would be greatly eased if they didn't have to
> > deal with function pointers and the syntax that surrounds their use.
> > Also, I think this will be much easier to generate doxygen documentation
> > for as we could do it per-function as opposed to one large doc that
> > would have to explain every entry in the whole GLOBAL struct.
> >
> > Thanks,
> > steven
> >
> >
> > --------------------------------------------------------------------
> > mail2web - Check your email from the web at
> > http://mail2web.com/ .
> >
> >
>
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
>

>>>>> "Matt" == Matt J Ingalls  writes:

 Matt>                                       john's macros are fine except for
 Matt> hosts managing multiple instances [and multiple global structs]

Not so.  It pcglob is passed as an argument all over which was the
intent (and a better name) then it is equivalent -- that is the joy
of C macros.
==John

right.
but then you have to make sure you name the input argument 'pcglob' right?
[seems yucky to me]
i guess what i was thinking that it would be nicer to have the macros take
an input argument instead..??

-m

On Fri, 21 Nov 2003 jpff@cs.bath.ac.uk wrote:

> >>>>> "Matt" == Matt J Ingalls  writes:
>
>  Matt>                                       john's macros are fine except for
>  Matt> hosts managing multiple instances [and multiple global structs]
>
> Not so.  It pcglob is passed as an argument all over which was the
> intent (and a better name) then it is equivalent -- that is the joy
> of C macros.
> ==John
>
>

That is why I sais with a better name.

Thinking about it a bit more I thing that the simple route is to change 
the macros so pcglob is replaced by p->h->insdshead->csound (I think I get 
that right!) and then access to the structure of any opcode gives access 
to the current structure.  There would be a few loose ends to fix after 
that, but the multiple csounds would be allowed.
==John ff

good deal. but this then means it will only work for plugin-to-csound,
not csound-as-plugin, right?

-m


> That is why I sais with a better name.
>
> Thinking about it a bit more I thing that the simple route is to change
> the macros so pcglob is replaced by p->h->insdshead->csound (I think I get
> that right!) and then access to the structure of any opcode gives access
> to the current structure.  There would be a few loose ends to fix after
> that, but the multiple csounds would be allowed.
> ==John ff
>
>

cannot see why.  csound as plugin needs the csound parameter to be set, 
which can be done with the init call, which fills in the structure from 
internal function values, and defaults.  Setting sr, kr etc can be in the 
strcuture and then the basic engine needs similar changes.  This can all 
be done incrementally, which is my preferred development strategy.
==John ff