That's the idea, right.

The "contract" between Csound and its users, both host applications and
plugins, should be in one file, and it should be completely unambiguous and
completely self-contained.

Currently, csound.h does include cs.h, because some of the API calls
reference structures in cs.h.

Ideally, this would be changed; all the structures referenced by the API
would be defined in the API header, and cs.h would include THAT. 

I wouldn't have any problem moving the API into cs.h, either, if other
purely private things were moved OUT of cs.h. I just want the "contract" to
be clear to all concerned and to not contain confusing extraneous
information.

Original Message:
-----------------
From: stevenyi stevenyi@csounds.com
Date: Tue, 21 Oct 2003 09:31:41 -0400
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3194] csound.h, csdl.h (was Re: --opcode-lib stuff,
specdisp, update)


As I was the original confused person on this, I'd like to say that this
makes sense to me.  =)  csound.h, which is the interface for the API,
should be the only include a plugin or host system would need to
include, yes? 

Also, csdl.h seems to be something of glue code in itself; if we move to
using only API calls, this header would no longer be needed, yes?

Thanks,
steven

On Mon, 2003-10-20 at 20:23, Michael Gogins wrote:
> I just wanted to offer a little bit more clarification on what I wrote
> below. From my point of view, a plugin opcode is "external" to Csound. It
> doesn't need to know anything about how orchestras are parsed, or how
scores
> are warped. And it needs a standard, cast in stone interface that will not
> change so that it can run in various versions of Csound. This is why I
think
> distinguishing between an "internal" API and an "external" one is
> artificial. Also, in practice, plugins and host applications end up
calling
> many of the same functions (to get the sampling rate, to read a function
> table, etc.).
> 
> ============================================
> Michael Gogins
> gogins at pipeline period com
> Irreducible Productions
> Silence, a language for programming music and sound
> Available at http://sourceforge.net/projects/silencevst/
> ============================================
> 


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

as implied in my previous email, i am already doing this in mycode, with
everything inside of csound.h [it seemed less to move than putting
everything in cs.h]


-m





On Tue, 21 Oct 2003, gogins@pipeline.com wrote:

> That's the idea, right.
>
> The "contract" between Csound and its users, both host applications and
> plugins, should be in one file, and it should be completely unambiguous and
> completely self-contained.
>
> Currently, csound.h does include cs.h, because some of the API calls
> reference structures in cs.h.
>
> Ideally, this would be changed; all the structures referenced by the API
> would be defined in the API header, and cs.h would include THAT.
>
> I wouldn't have any problem moving the API into cs.h, either, if other
> purely private things were moved OUT of cs.h. I just want the "contract" to
> be clear to all concerned and to not contain confusing extraneous
> information.
>
> Original Message:
> -----------------
> From: stevenyi stevenyi@csounds.com
> Date: Tue, 21 Oct 2003 09:31:41 -0400
> To: csound-dev@eartha.mills.edu
> Subject: [CSOUND-DEV:3194] csound.h, csdl.h (was Re: --opcode-lib stuff,
> specdisp, update)
>
>
> As I was the original confused person on this, I'd like to say that this
> makes sense to me.  =)  csound.h, which is the interface for the API,
> should be the only include a plugin or host system would need to
> include, yes?
>
> Also, csdl.h seems to be something of glue code in itself; if we move to
> using only API calls, this header would no longer be needed, yes?
>
> Thanks,
> steven
>
> On Mon, 2003-10-20 at 20:23, Michael Gogins wrote:
> > I just wanted to offer a little bit more clarification on what I wrote
> > below. From my point of view, a plugin opcode is "external" to Csound. It
> > doesn't need to know anything about how orchestras are parsed, or how
> scores
> > are warped. And it needs a standard, cast in stone interface that will not
> > change so that it can run in various versions of Csound. This is why I
> think
> > distinguishing between an "internal" API and an "external" one is
> > artificial. Also, in practice, plugins and host applications end up
> calling
> > many of the same functions (to get the sampling rate, to read a function
> > table, etc.).
> >
> > ============================================
> > Michael Gogins
> > gogins at pipeline period com
> > Irreducible Productions
> > Silence, a language for programming music and sound
> > Available at http://sourceforge.net/projects/silencevst/
> > ============================================
> >
>
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
>