Csound Csound-dev Csound-tekno Search About

[CSOUND-DEV:3325] Re: csound.c issues, API request

Date2003-11-16 06:09
From"Michael Gogins"
Subject[CSOUND-DEV:3325] Re: csound.c issues, API request
playopen should be changed to take void* csound in Csound 5, and so should
any other function that needs anything from Csound.

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.

============================================
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 12:44 AM
Subject: [CSOUND-DEV:3322] csound.c issues, API request


> Hi all,
>
> I'm currently working on editing csound.c to work with csound5 cvs.
> There are some issues I came across, mostly references to the global
> ksmps and things like that instead of grabbing them from the passed in
> void *csound.  However, there is one that is tricky: playopen_mi()
> references ksmps, but does not receive a void *csound in it's
> arguments.  For the time being I have it using csoundGetKsmps(&cglob),
> but that's a hack to get by for now. (I've added a FIXME note that
> should be easy to grep for).
>
> Here are some compiler errors that I received:
>
> Top/main.c:410: the use of `tmpnam' is dangerous, better use `mkstemp'
> csound.o(.text+0xb9): In function `csoundPerform':
> Top/csound.c:151: undefined reference to `runincomponents'
> csound.o(.text+0x125): In function `csoundCompile':
> Top/csound.c:166: undefined reference to `runincomponents'
> csound.o(.text+0x79d): In function `csoundReset':
> Top/csound.c:1000: undefined reference to `SfReset'
> csound.o(.text+0x8a5): In function `csoundGetInputBuffer':
> Top/csound.c:305: undefined reference to `inbuf'
> csound.o(.text+0x510): In function `csoundSetEnv':
> Top/csound.c:973: undefined reference to `warning'
>
> The issues that these bring up for me are:
>
> What is runincomponents?  In csound4 cvs it seems to be defined in
> musmon.c, and from looking at what changed between csound4 and csound5
> versions of it, was runincomponents changed to frsturnon? (if so, then
> I'll edit that in the csound.c file).
>
> The other big issues here is SfReset.  This is a cleanup function that
> is now moved out to an Opcode plugin (sfont.c).  Knowing the way sfont.c
> is implemented, it seems then that it might be worth adding to the
> csound API a method to appendCleanupFunction, so when csound goes to
> load the plugin, the plugin can then call the API function on the passed
> in void *csound to add any functions to run at the end of a csound run.
>
>
> I've committed csound.c, load_opcodes.c, and ccsound.c into csound5 cvs
> into the Top directory.  To use these, you'll need to edit the
> Makefile.in to remove references to jpff_glue.c and dl_opcodes.c and put
> in references to these files.  These files still need work and are not
> yet ready as drop-in replacements of jpff_glue.c and dl_opcodes.c.
>
> thanks!
> steven
>

Date2003-11-16 06:24
Fromstevenyi
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