I am not currently using csound5. In the next week or so I will probably try
porting CsoundVST over to it. At that time, I will be making whatever
changes seem required to get things working again, and if I need to change
the reset functions as you suggest I will do that.

I presume when you mean "environment" you mean passing a pointer to the
GLOBALS struct to the reset functions.

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: 
To: "Csound Developers Discussion List" 
Sent: Tuesday, November 25, 2003 4:02 PM
Subject: [CSOUND-DEV:3509] Reset in Csound5


> I need RESET functions to have the environment structure as an
> argument.  Is that OK?  I have changed jpff_glue but someone may have
> to change the other API code.
>
> This is all to do with making the environment not global but instance
> related.  As I said earlier there are a number of issues, but they are
> all getting done; changes rather more extensive than I would have
> hoped, but I have two long(ish) train journeys tomorrow and so battery
> willing I should be nearly there by Thursday lunchtime.
>
> ==John ffitch
>

On Tue, 25 Nov 2003, Michael Gogins wrote:

> I presume when you mean "environment" you mean passing a pointer to the
> GLOBALS struct to the reset functions.
> 

Yes.  As I move to multiple instances the name GLOBALS seems less helpful 
-- it did start as exactly a structure of all globals but things are 
changing.  How about renaming this to ENV or CSOUND or some better name?  

Last night I got a little further with moving to a passed (pointer to) the 
GLOBAL structure in the plugins.  This is requiring changes in the base, 
and I want to do the same basic change to OOps, Engine etc as soon the 
Opcodes are done.

==John ff

Hi John,

There was discussion on this list about a week and a half ago to split
GLOBALS to CSOUND_INTERFACE for the function pointers and CSOUND_STATE
for the data members, with CSOUND_STATE's first member being an instance
of CSOUND_INTERFACE.  (I believe I have that correct).  Maybe it'd be a
good time to split the GLOBAL up and start changing code around to
access data via functions rather than directly access the data?  (I know
it's a larger step than renaming but I figure it might be worth
introducing this convention sooner rather than later, and it should be
able to be worked into the defines in cs.h/csdl.h).

steven


On Tue, 2003-11-25 at 21:47, John ffitch wrote:
> On Tue, 25 Nov 2003, Michael Gogins wrote:
> 
> > I presume when you mean "environment" you mean passing a pointer to the
> > GLOBALS struct to the reset functions.
> > 
> 
> Yes.  As I move to multiple instances the name GLOBALS seems less helpful 
> -- it did start as exactly a structure of all globals but things are 
> changing.  How about renaming this to ENV or CSOUND or some better name?  
> 
> Last night I got a little further with moving to a passed (pointer to) the 
> GLOBAL structure in the plugins.  This is requiring changes in the base, 
> and I want to do the same basic change to OOps, Engine etc as soon the 
> Opcodes are done.
> 
> ==John ff
> 
> 

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.........

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.........
> 
> 

That looks gratuitiusly expensive in C
==John ff