I think it best if plugins communicate with host through functions only.
Internally, however, Csound can and should use data members because that is
significantly faster. GLOBALS (perhaps to be renamed "Csound") is used by 3
parties in 3 ways:

Hosts of Csound, via function pointers
Plugins in Csound, via function pointers
Internal functions of Csound (taking Csound * for multiple instancing), via
data members

There must be only Csound or GLOBALS structure for all 3 parties; however
for the sake of clarity hosts can use 1 function pointer interface, and
plugins can use another function pointer interface. Something like this?

typedef struct HostInterface {
void (function1*)();
void (function2*)();
...
Csound_ *csound;
};
typedef struct PluginInterface {
void (function1*)();
void (function2*)();
...
Csound_ *csound;
};
typedef struct Csound_ {
HostInterface *hostInterface;
PluginInterface *pluginInterface;
int datamember1;
double datamember2;
...
};


Original Message:
-----------------
From: stevenyi stevenyi@csounds.com
Date: Tue, 25 Nov 2003 23:19:30 -0800
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3530] Re: Reset in Csound5


I thought that there was a move to change from functions accessing data
as:

cglob.dataMember

to:

(*cglob->dataAccessor)(cglob) 

(something like that)

so that dataMembers of GLOBAL were not to be accessed directly.  This
was in regards to Michael's email on the 19th:


> > I suggest it's better that all Csound state be in GLOBALs, but
hidden,
and
> > all Csound functions be in GLOBALs, but public.
> >
> > Perhaps we can do something like this:
> >
> > typedef struct CSOUND_INTERFACE {
> > int (Function1*)();
> > int (Function2*)();
> > } CSOUND_INTERFACE;
> >
> > typedef struct CSOUND_STATE {
> > CSOUND_INTERFACE csound;
> > void *userdata;
> > int kr;
> > int sr;
> > ...;
> > } CSOUND_STATE;
> >
> > This allows CSOUND_STATE to be safely type cast to CSOUND_INTERFACE.
Users
> > of the API only see CSOUND_INTERFACE, even though it carries a
hidden
> > CSOUND_STATE:
> >
> > CSOUND_INTERFACE  *csoundCreate(void *userdata)
> > {
> >     CSOUND_STATE *csoundState = (CSOUND_STATE *)
> > csoundAlloc(sizeof(CSOUND_STATE));
> >     csoundState->csound.Function1 = csoundFunction1;
> >     csoundState->csound.Function2 = csoundFunction2;
> >     ...
> >     csoundState->userdata = userdata;
> >     return (CSOUND_INTERFACE *)csoundState;
> > }


Sorry, just impatience on my part to suggest moving to this now; you
probably should continue with your change as I don't think the interface
is complete enough yet to have all of the accessor functions to fully
hide the data members anyways and of course you're correct in that the
functions held in GLOBAL struct don't yet take in the GLOBAL itself to
retrieve the data.  (or whatever GLOBAL is to be renamed to =) ).

steven


On Tue, 2003-11-25 at 22:47, John ffitch wrote:
> Sorry but I do not understand the suggestion.  I am aware that the 
> interface between the plugins anbd the engine is different from the API, 
> and it is the former that interests me.  I do not see how this is done 
> with a function without additional function calls for nothing.
> ==John ff
>   should I not continue this change on the train today?  Only minutes 
> before I leave.........
> 
> 


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

Hi Michael,

Thanks for explaining this again for me. =)  

One question I have with splitting the host and plugin interface, it
seems that you can add to either the HostInterface or PluginInterface
and you'd be future-proof.  Is this correct?  Or would you break plugins
if you add to the HostInterface?  

thanks,
steven



On Wed, 2003-11-26 at 07:23, gogins@pipeline.com wrote:
> I think it best if plugins communicate with host through functions only.
> Internally, however, Csound can and should use data members because that is
> significantly faster. GLOBALS (perhaps to be renamed "Csound") is used by 3
> parties in 3 ways:
> 
> Hosts of Csound, via function pointers
> Plugins in Csound, via function pointers
> Internal functions of Csound (taking Csound * for multiple instancing), via
> data members
> 
> There must be only Csound or GLOBALS structure for all 3 parties; however
> for the sake of clarity hosts can use 1 function pointer interface, and
> plugins can use another function pointer interface. Something like this?
> 
> typedef struct HostInterface {
> void (function1*)();
> void (function2*)();
> ...
> Csound_ *csound;
> };
> typedef struct PluginInterface {
> void (function1*)();
> void (function2*)();
> ...
> Csound_ *csound;
> };
> typedef struct Csound_ {
> HostInterface *hostInterface;
> PluginInterface *pluginInterface;
> int datamember1;
> double datamember2;
> ...
> };
> 

> plugins can use another function pointer interface. Something like this?
>
> typedef struct HostInterface {
> void (function1*)();
> void (function2*)();
> ...
> Csound_ *csound;
> };

except then you need the definition of Csound_ to compile a
host, and you are letting hosts see the Csound_ struct.  so can we have a
'private' and a 'public' definition for HostInterface, as mentioned
previously?

/*defined in cs.h or somewhere NOT in csound.h*/
typdef struct HostInterface {
void (function1*)();
void (function2*)();
...
Csound_ *csound;
};

/* defined in csound.h */
typdef struct CsoundLib { /*or someother name */
void (function1*)();
void (function2*)();
...
};

then implementation of api functions would look like:

CsoundLib *csoundCreate(void *hostData)
{
   Csound_ *cs = NewCsoundInstance() ; /* or however we do it */
   cs->hostdata = hostData;
   return (CsoundLib *)cs->hostInterface;
}

int csoundGetNchnls(CsoundLib *cs)
    {
        return ((HostInterface *)cs)->csound.nchnls;
    }



dont know if you need this for the plugin api too?  also i guess
'hostData' could be included in the function-pointer (what i called
CsoundLib) struct instead of the globals Csound_ struct..

-m