Great, I understand you better and I think we basically agree.
CSOUND_INTERFACE for the API, CSOUND_STATE for Csound's instance state, to
be reduced to a minimum over time.

============================================
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: "Richard Dobson" 
To: "Csound Developers Discussion List" 
Sent: Sunday, November 16, 2003 1:49 PM
Subject: [CSOUND-DEV:3339] Re: Road to Reentrancy


>   All I mean is that some of that data doesn't really represent state, but
is
> merely "private" and often transient data passed from one function to
another
> via a global variable. Variables that are used in only one or two files
are
> cases in point. For example, "nrecs", and "ngotos". Variables that were
> originally static to one file but subsequently moved to GLOBALS are also
cases
> in point. Some variables are in effect duplicates of data that is already
> available elsewhere. Anything that helps reduce the size of objects
potentially
> helps enhance performance.
>
> Many of these variables may not even need to survive at all when such
things as
> the new parser, use of soundfile libraries etc come online. Others are
surely
> read-only, and should be read through access functions only.
>
> I like your your suggestion for an CSOUND_INTERFACE, aranging thinsg this
way
> will also help clarify the restructuring process. I would then further
suggest
> that as part of the anyway necessary restructuring of the code, that a lot
of
> what is left can probably be removed through a process of voluntary
redundancy,
> so that in the end CSOUND_INTERFACE is all there is. In short, I don't
think the
> Csound state requires quite as much stuff as we currently have.
>
> A case in point is a variable such as "currevent", which is a pointer to
an
> EVTBLK (so we are stuck with the definition of that). Scanning through my
> version of Csound (4.23), the only elements of it that opcodes  are
interested
> in are "strarg", which is a string (may need to be Unicode one day), and
the
> list of pfields.  Arguably both are read-only. It is set in playevents()
and if
> it is passed to each opcode as an argument (which would be more
self-documenting
> if nothing else!), it is IMO very debatable whether it needs to be in
GLOBALS at
> all. So many programmers have complained about the obscureness and
> undocumentedness of the code, and this is just the sort of change that
will not
> only modularise the code more and economise on the size of GLOBALS, but
obviate
> those criticisms too.
>
>
>
>
> Richard Dobson
>
>
>
> Michael Gogins wrote:
>
> > I have mixed feelings about mini structures. I get your point about
extra
> > junk in there and not needing the whole set, yet my experience tells me
> > keeping it all in one struct will make Csound easier to program and
maintain
> > in future (oops, now this function needs member X added to its mini
struct,
> > and this other function needs member X also added to ITS mini struct).
> >
> > Could you please explain why you wish to distinguish between members of
> > GLOBALs and items private to Csound? How can Csound be a multiply
> > instantiable class if all required data is not referenceable through
> > GLOBALs?
> >
> > 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;
> > }
> >
>
>

I just found, by chance, another example of something that needs to be solved 
without automatically going into GLOBALS:

in my copy of butter.c, there is a static variable "pidsr" initialized to PI/esr 
by all the filter opcodes. This isn't a true constant as the posibility must 
exist of multiple Csound instances with different sample rates. But it would 
seem better to add this to the opcode struct BFIL unless such a value is 
actually required, er, globally. So there is a case for identifying data that 
really is global in some sense, as distinct from stuff that can be contained 
within opcodes. So what is regarded as Csound state and data may really be 
opcode state and data, which is different.

Richard Dobson