Csound Csound-dev Csound-tekno Search About

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

Date2003-11-16 17:24
From"Michael Gogins"
Subject[CSOUND-DEV:3336] Re: Csound API Split, design
Matt's saying the same things here that I am in my earlier emails, except
for use of an ID as opposed to a pointer.

My experience as a programmer is that a pointer is easier to deal with, and
of course this is what we are currently doing, but that is a secondary
issue.

============================================
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: "Matt J. Ingalls" 
To: "Csound Developers Discussion List" 
Sent: Sunday, November 16, 2003 3:01 AM
Subject: [CSOUND-DEV:3328] Re: Csound API Split, design


>
> > 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.
>
> for me the main thing i want
> is the host to not have access to, or even know about the
> GLOBALS struct, which will allow a host to be compiled without all these
> csound header files.  the api header file should be the only thing needed.
> i believe it was decided on this list it was ok to change the api so that
> a unique ID is passed between csound and hosts in the api functions
> instead of a pointer to a GLOBALS struct like it is now.
>
> > 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) )
>
> if you are not exporting the symbols and want to call that function from
> an external host or plugin you need the pointer to the function to be able
> to call it!
>
> -m
>