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


----- Original Message ----- 
From: 
To: "Csound Developers Discussion List" 
Sent: Monday, October 20, 2003 9:29 AM
Subject: [CSOUND-DEV:3189] Re: --opcode-lib stuff, specdisp, update


In my opinion, plugins should access Csound only via the API. The
engineering reason for this is that shared library function binding works
differently on different platforms. On Windows, for example, shared library
functions are not accessible unless they are exported. The API is put into
a function table that is part of the Csound globals structure which is
available to every opcode. In other words, you can call API functions like
this: csound->csoundApiFunction(csound, arg1, arg2,...). The globals
structure and thus the API is passed from the host (Csound) to the client
(the plugin). This means that all plugin opcodes automatically have access
to all members of the globals structure, including all the functions in the
Csound API.

If the plugins call functions in cs.h, then on Windows they can't call them
unless they are exported. If they are exported, then we have two Csound
APIs, one defined in csound.h and one defined in cs.h.

Possibly the intention is to have two Csound APIs, one for "external" use
and one for "internal" use, but I think this distinction is artificial and
could prove confusing - as it already seems to be.

I would prefer that there be only one Csound API for both internal and
external use. I don't care where it is or what it's called, but it needs to
be able to support both CsoundVST and other csound-based applications, and
plugin opcodes.

Original Message:
-----------------
From: stevenyi stevenyi@csounds.com
Date: Sun, 19 Oct 2003 23:54:06 -0400
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3181] Re: --opcode-lib stuff, specdisp, update


Hi John,

Thanks for the reply!  I see now how you worked the other changes in
cs.h.  I've been a bit wary as I didn't want to add functions that
weren't "supposed" to be in there, as I thought all calls were to be
going through the API and cs.h is the public header for csound as a
library (at least, I thought it was).  Oh wait... I see where I'm
getting confused, and perhaps this is a point needing clarification for
myself.  Should opcode libs only #include csound.h and only use the
API?  If so, then perhaps the opcodes in the Opcodes dir should be
recoded to use API functions (and add API functions for cases where they
don't exist).

Anyways, I'll go ahead and move forward as you suggested and will be
committing changes as I make them.  I guess we can take functions back
out and add to the API later if need be (or recode opcodes to use
existing API functions where available).

Thanks,
steven


On Mon, 2003-10-20 at 02:25, John ffitch wrote:
> So the answer is to add ftfind to the list of function in teh internal
> interface; and then add the next one, and teh next one,... until it works.
> ==John
>
>


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

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

I do not think I agree with that.

john,

on this subject:

did you ever look at my stuff where i put all the needed defs inside
csound.h [leaving cs.h fairly sparse] and moved more sys-dep stuff inside
sysdep.h?

this is one of the reasons i havent jumped into the csound5 code, because
it is a somewhat substantial restructuring i felt like i was unqalified to
change the sources that much.

once that is implemented [or rejected] i would like to make some changes
to csound.c [with yalls approval of course]

thanks,
m



On Tue, 21 Oct 2003, John ffitch wrote:

> I do not think I agree with that.
>
>