Of course - opcode state belongs in the opcode struct, csound state belongs
in the GLOBALS (to be CSOUND_STATE) struct. But the Csound state must
include some parts of the opcode state that Csound tracks already per "i"
statement, right? Like the MIDI channel blocks, for instance, the
active/inactive lists, and so on.

============================================
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 8:49 PM
Subject: [CSOUND-DEV:3347] Re: Road to Reentrancy


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

Hi all,

It seems to me now that opcode plugins, since they won't be using the
API functions as defined in csound.h but rather should be accessing
through the GLOBAL *, then csound.h can be considered the host API and
cs.h in it's current form is something that would eventually become a
plugin API, yes?

steven

On Sun, 16 Nov 2003, stevenyi wrote:

> Hi all,
> 
> It seems to me now that opcode plugins, since they won't be using the
> API functions as defined in csound.h but rather should be accessing
> through the GLOBAL *, then csound.h can be considered the host API and
> cs.h in it's current form is something that would eventually become a
> plugin API, yes?
> 

When I suggested that the API for applications was a different object to 
the API for plugins I got attacked for such thinking.  Good to see that 
eventually you are coming round to what I was (a) doing and (b) saying

==John ff

> When I suggested that the API for applications was a different object to 
> the API for plugins I got attacked for such thinking.  Good to see that 
> eventually you are coming round to what I was (a) doing and (b) saying

Well, I think I missed any posts elucidating the current cs.h design as
it took me a while to realize that that was what you were doing.
Probably would have been over my head at the time anyways as it hasn't
been until this weekend that I've felt I've gotten intimate enough with
everyone's code and ideas, as well as the rest of the Csound engine and
codebase, to see what's going on.

So, now I'm thinking in terms of "host API functions" and "plugin API
functions".  There seems to be host API functions in the GLOBAL struct
that opcodes probably don't need and would be dangerous for opcodes to
call, for example:

  void *(*GetHostData)(void *csound);
  void (*SetHostData)(void *csound, void *hostData);
  int (*Perform)(void *csound, int argc, char **argv);
  int (*Compile)(void *csound, int argc, char **argv);
  void (*Cleanup)(void *csound);
  void (*Reset)(void *csound);
  void (*RewindScore)(void *csound);

and others.  Should these functions be removed, or is there something
else I'm missing?  

This would break the parity Michael was suggesting of every API function
in csound.h needing to have its mirror in the GLOBAL struct.  Other
things Michael was talking about like appending functions to GLOBAL (or
the proposed CSOUND_INTERFACE struct) would still hold. 

Thanks,
steven

csdl.h is the plugin format.

==John ffitch