Hi all,

>From another conversation with Matt and others, what's the concensus on
splitting the CsoundAPI into two parts, one for host functions and one
for plugins?  

The rationale: plugins don't need access to many of the functions of the
current CsoundAPI (i.e. running csound or calling reset).  Hosts
probably don't need access to functions plugins would need (unquote,
function table access, etc.).  There are also functions both would need
(getKsmps, getNchnls, etc.).  Perhaps now would be a good time for all
of us to review the API to get these things nailed down.  I'm sure as we
work through reentrancy and other things, more functions and issues may
come up.  

Also, in general for design, should functions that are currently being
stored in the GLOBAL struct be there, or should those functions be
redesigned to take in the GLOBAL struct if they need data from it and
then exposed through the API?  (i.e. instead of cglob->unquote we get
csoundUnquote(void *csound) )

Thanks all,
steven

> The rationale: plugins don't need access to many of the functions of the
> current CsoundAPI (i.e. running csound or calling reset).  Hosts
> probably don't need access to functions plugins would need (unquote,
> function table access, etc.).  There are also functions both would need
> (getKsmps, getNchnls, etc.).  Perhaps now would be a good time for all
> of us to review the API to get these things nailed down.  I'm sure as we
> work through reentrancy and other things, more functions and issues may
> come up.

for me the main thing i want
is the host to not have access to, or even know about the
GLOBALS struct, which will allow a host to be compiled without all these
csound header files.  the api header file should be the only thing needed.
i believe it was decided on this list it was ok to change the api so that
a unique ID is passed between csound and hosts in the api functions
instead of a pointer to a GLOBALS struct like it is now.

> Also, in general for design, should functions that are currently being
> stored in the GLOBAL struct be there, or should those functions be
> redesigned to take in the GLOBAL struct if they need data from it and
> then exposed through the API?  (i.e. instead of cglob->unquote we get
> csoundUnquote(void *csound) )

if you are not exporting the symbols and want to call that function from
an external host or plugin you need the pointer to the function to be able
to call it!

-m

> > Also, in general for design, should functions that are currently being
> > stored in the GLOBAL struct be there, or should those functions be
> > redesigned to take in the GLOBAL struct if they need data from it and
> > then exposed through the API?  (i.e. instead of cglob->unquote we get
> > csoundUnquote(void *csound) )
> 
> if you are not exporting the symbols and want to call that function from
> an external host or plugin you need the pointer to the function to be able
> to call it!

Okay, I'm a bit confused here, since most of the functions are available
via the API header.  If we're exposing the csound API functions with
csound.h, why are the function pointers currently in the GLOBALS struct
there (especially if you want the GLOBAL struct to be hidden from client
applications)?  If you're passed in the GLOBAL as a void *, and you're
#including the csound.h header, can't you write your code to call the
csound API functions on the void *?  Or in other words, why is currently
possible to write:

(*cglob->Cleanup)(&cglob)

as well as:

csoundCleanup(&cglob)

Right now, most of the function pointers in GLOBALS are copies of csound
API functions.  The later additions:

  void (*auxalloc)(long nbytes, AUXCH *auxchp);
  char *(*getstring)(int, char*);
  void (*die)(char *);
  FUNC *(*ftfind)(MYFLT *);
  int (*initerror)(char *);
  int (*perferror)(char *);
  void *(*mmalloc)(long);
  void (*mfree)(void *);
  void (*dispset)(WINDAT *, MYFLT *, long, char *, int, char *);
  void (*display)(WINDAT *);
  MYFLT (*intpow)(MYFLT, long);
  FUNC *(*ftfindp)(MYFLT *argp);
  FUNC *(*ftnp2find)(MYFLT *);
  char *(*unquote)(char *);
  MEMFIL *(*ldmemfile)(char *);

are all functions that should either be added to the CsoundAPI as they
are function that should be exposed to client applications and plugins,
or should be hidden and opcodes that use these functions should be
rewritten. 

Am I misunderstanding your side and the code as well?

Thanks,
steven