|
> The macros depend on linking with a Csound library, do they not?
no. they are just a macro replacing the function pointer syntax.
>
> If so, they won't work across Csound versions where the structure layout
> changes.
i dont see how this could work in any case if the structure layout
changes, given the current design of the API?
-m
>
> Original Message:
> -----------------
> From: Matt J. Ingalls ingalls@mills.edu
> Date: Wed, 19 Nov 2003 13:42:18 -0800 (PST)
> To: csound-dev@eartha.mills.edu
> Subject: [CSOUND-DEV:3421] Re: Csound API Split, design
>
>
> > 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/ .
> >
> >
>
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
> |