It is doable because the doapdr function keeps track of what is happening.
It cleans up on the first call, then does nothing on successive calls. This
is not so elegant but it is simple and it works fine.

============================================
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:24 AM
Subject: [CSOUND-DEV:3327] Re: csound.c issues, API request


> On Sat, 2003-11-15 at 22:09, Michael Gogins wrote:
> > playopen should be changed to take void* csound in Csound 5, and so
should
> > any other function that needs anything from Csound.
>
> So this will probably get addressed then when everything starts getting
> passed void *csound in and cglob is removed from global scope.  Cool, at
> least it's tagged with FIXME and will be addressed later then.
>
>
> > There is an opcode cleanup function (OENTRY.dopadr) that probably should
be
> > used in place of your suggestion to append a cleanup function. Csound
> > automatically calls this function pointer at the end of a run if it is
not
> > null.
>
> This is called after each opcode instance, but the way sfont.c and the
> family of opcodes that come from it are used, there's variables in the
> global scope that the opcode plugin would introduce that is currently
> being cleaned up by a function in csoundReset.  (sfload will load a
> soundFont and return an int which is an index into the list of loaded
> soundFonts, other opcodes take in the int to access the soundFont list
> and use them, at the end of the run csoundReset calls SfReset to clean
> up that list in the global space).  How could something like this
> architecture of opcodes be doable with OENTRY.doapdr?
>
> Thanks for any clarification on this,
> steven
>