Csound Csound-dev Csound-tekno Search About

[CSOUND-DEV:3334] Re: Csound API Split, design

Date2003-11-16 17:21
From"Michael Gogins"
Subject[CSOUND-DEV:3334] Re: Csound API Split, design
both csoundUnquote and globals->Unquote -- see earlier email.

We can't have a multiply instantiable Csound unless all Csound functions are
function pointer members of a single GLOBALS structure - in other words,
unless Csound is a single C class.

In other words, although it would POSSIBLE to declare some of these
functions in one header for hosts, and other functions in another header for
plugins, I think it will be much less confusing if they are all declared in
one header because, after all, it is really one class. We just need to
document the header clearly.

============================================
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: "stevenyi" 
To: "Csound Developers Discussion List" 
Sent: Sunday, November 16, 2003 1:14 AM
Subject: [CSOUND-DEV:3326] Csound API Split, design


> Hi all,
>
> >From another conversation with Matt and others, what's the concensus on
> splitting the CsoundAPI into two parts, one for host functions and one
> for plugins?
>
> The rationale: plugins don't need access to many of the functions of the
> current CsoundAPI (i.e. running csound or calling reset).  Hosts
> probably don't need access to functions plugins would need (unquote,
> function table access, etc.).  There are also functions both would need
> (getKsmps, getNchnls, etc.).  Perhaps now would be a good time for all
> of us to review the API to get these things nailed down.  I'm sure as we
> work through reentrancy and other things, more functions and issues may
> come up.
>
> Also, in general for design, should functions that are currently being
> stored in the GLOBAL struct be there, or should those functions be
> redesigned to take in the GLOBAL struct if they need data from it and
> then exposed through the API?  (i.e. instead of cglob->unquote we get
> csoundUnquote(void *csound) )
>
> Thanks all,
> steven
>