Can I use one of these dummy API functions slots in CSOUND_

  struct CSOUND_ {
    /* Csound API function pointers (320 total) */
[...]
    MYFLT (*GetScoreTime)(CSOUND *);
    SUBR dummyfn_6;     /* unused slots */
    SUBR dummyfn_7;
    SUBR dummyfn_8;
    int (*IsScorePending)(CSOUND *);


to add the following API function:

void (*SetCscoreCallback)(CSOUND *, void (*cscoreCallback)(CSOUND *));

??

Or would it be preferable to put it at the end?  (near this:

    SUBR dummyfn_1;
    SUBR dummyfn_2[116];
)

Also, I did not see the Cscore functions from cscorfns.c in this list
anywhere.  Do they need to be added?  (I could do this if necessary).

I will also need to add a callback pointer to the data section of CSOUND_.
Should I add near the other callback pointers or should I append it to the
very end of the struct??

Thanks!

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> Can I use one of these dummy API functions slots in CSOUND_
> 
>   struct CSOUND_ {
>     /* Csound API function pointers (320 total) */
> [...]
>     MYFLT (*GetScoreTime)(CSOUND *);
>     SUBR dummyfn_6;     /* unused slots */
>     SUBR dummyfn_7;
>     SUBR dummyfn_8;
>     int (*IsScorePending)(CSOUND *);
> 
> 
> to add the following API function:
> 
> void (*SetCscoreCallback)(CSOUND *, void (*cscoreCallback)(CSOUND *));
> 
> ??
> 
> Or would it be preferable to put it at the end?  (near this:
> 
>     SUBR dummyfn_1;
>     SUBR dummyfn_2[116];
> )

I would recommend using slots from the big dummy array at the end,
and not the others scattered around because I already use those for
other functions, just did not commit the changes yet.

> Also, I did not see the Cscore functions from cscorfns.c in this list
> anywhere.  Do they need to be added?  (I could do this if necessary).

They are not there probably because so far no one was interested.
Note though that functions in CSOUND are meant to be used by plugin
libraries. A host is expected to link against libcsound and call
the functions directly; it cannot access anything in CSOUND because
the type is incomplete if you include csound.h and not csdl.h.
Are the new functions really intended to be used from plugins ?

> I will also need to add a callback pointer to the data section of CSOUND_.
> Should I add near the other callback pointers or should I append it to the
> very end of the struct??

It depends on whether you want to preserve the callback pointer on
calling csoundReset(). If you want the pointer to be persistent, add it
to the group of other callbacks between first_callback_ and last_callback_.
Otherwise, it can be added anywhere in the private section (or even the
public data if you do want to allow plugins to access the pointer directly;
in the case of public members, new stuff should always be added at the end
of that section).



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks, Istvan, for the very helpful advice.  I have a couple of other
questions, though, now.

Istvan Varga wrote on 9/30/05 4:12 PM:

> I would recommend using slots from the big dummy array at the end,
> and not the others scattered around because I already use those for
> other functions, just did not commit the changes yet.

OK.  Am I correct to assume that the purpose of the dummy slots is to avoid
changing the length of the function pointers in the struct?  So, if I add
some functions at this location, do I need to decrement the array size
accordingly?
 
>> Also, I did not see the Cscore functions from cscorfns.c in this list
>> anywhere.  Do they need to be added?  (I could do this if necessary).
> 
> They are not there probably because so far no one was interested.
> Note though that functions in CSOUND are meant to be used by plugin
> libraries.

I did not realize that that was their primary purpose.

> A host is expected to link against libcsound and call
> the functions directly; it cannot access anything in CSOUND because
> the type is incomplete if you include csound.h and not csdl.h.

Hmmm.  This brings up an interesting point that I have been thinking about.

I think that it would be very useful for a host to be able to dynamically
load different versions of the Csound library at the user's request.  This
of course would mean not linking directly to the library at build time.  I
thought that it would be possible then to load the csoundCreate symbol, call
it to get a Csound instance, and then use the function pointers to access
the host API.

There are two main reasons that I feel this would be useful.  First, users
will likely want to be able to switch between 32-bit and 64-bit versions of
the library for rendering "draft" versus "final" quality.  If a host is
linked directly to the library, then the user would have to use two
different versions of the host to acheive this.  It would definitely be a
plus if it could be possible to use one host binary with either library.

The second reason is for testing by developers.  In trying to track down
problems, I have found it very useful to be able to switch quickly between
versions of Csound.  The Cs4 front end on the Mac has this ability since the
front end and engine are separate.

Anyways, something to think about in case this functionality would require
any changes to the API.

> Are the new functions really intended to be used from plugins ?

I am not really sure at this point.  I had originally intended to add the
ability to load an external cscore() function from a plugin library.  In
this scenario, I guess the functions would have to be pointers in CSOUND_.
Is this correct?  That seems a little bit of a problem to me though, since
plugin cscore code would not be the same as host supplied code then.

I definitely want the capability now for the host to be able to call the
Cscore functions.  I guess the question is whether having Cscore plugins is
still necessary.  (My "development previews" of Cs4 for MacOS 9 include the
cscore plugin functionality).
 

>> I will also need to add a callback pointer to the data section of CSOUND_.
>> Should I add near the other callback pointers or should I append it to the
>> very end of the struct??
> 
> It depends on whether you want to preserve the callback pointer on
> calling csoundReset(). If you want the pointer to be persistent, add it
> to the group of other callbacks between first_callback_ and last_callback_.

Great!  I think that this will be the best route to go.  Thanks for the
info.

> Otherwise, it can be added anywhere in the private section (or even the
> public data if you do want to allow plugins to access the pointer directly;
> in the case of public members, new stuff should always be added at the end
> of that section).

This is good to know as well.

I would appreciate everyone's feedback on the above.  Thanks.

(I have host-supplied Cscore working right now here on my machine but have
not committed the code yet).

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> OK.  Am I correct to assume that the purpose of the dummy slots is to avoid
> changing the length of the function pointers in the struct?  So, if I add
> some functions at this location, do I need to decrement the array size
> accordingly?

Yes.

> Hmmm.  This brings up an interesting point that I have been thinking about.
> 
> I think that it would be very useful for a host to be able to dynamically
> load different versions of the Csound library at the user's request.  This
> of course would mean not linking directly to the library at build time.  I
> thought that it would be possible then to load the csoundCreate symbol, call
> it to get a Csound instance, and then use the function pointers to access
> the host API.

You can still do that if you include both csound.h and csdl.h (in this
order), or get the address of each API function to be used separately.
The reasons for not allowing hosts to access the contents of CSOUND
include problems with calling many of the function pointers that were
intended to be used from opcodes (for example dependencies on state
information like ids or pds, or calling longjmp), more dependencies on
additional headers, and more possible backward compatibility problems.
In general, the idea was to have as much encapsulation in the case of
the host API as possible, but it is possible that this approach may
need to be rethought.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> OK.  Am I correct to assume that the purpose of the dummy slots is to avoid
> changing the length of the function pointers in the struct?  So, if I add
> some functions at this location, do I need to decrement the array size
> accordingly?

Yes.

> Hmmm.  This brings up an interesting point that I have been thinking about.
> 
> I think that it would be very useful for a host to be able to dynamically
> load different versions of the Csound library at the user's request.  This
> of course would mean not linking directly to the library at build time.  I
> thought that it would be possible then to load the csoundCreate symbol, call
> it to get a Csound instance, and then use the function pointers to access
> the host API.

You can still do that if you include both csound.h and csdl.h (in this
order), or get the address of each API function to be used separately.
The reasons for not allowing hosts to access the contents of CSOUND
include problems with calling many of the function pointers that were
intended to be used from opcodes (for example dependencies on state
information like ids or pds, or calling longjmp), more dependencies on
additional headers, and more possible backward compatibility problems.
In general, the idea was to have as much encapsulation in the case of
the host API as possible, but it is possible that this approach may
need to be rethought.

Istvan Varga wrote:

> Anthony Kozar wrote:
> 
>> Hmmm.  This brings up an interesting point that I have been thinking about.
>>
>> I think that it would be very useful for a host to be able to dynamically
>> load different versions of the Csound library at the user's request.  
>> This of course would mean not linking directly to the library at build 
>> time.  I thought that it would be possible then to load the csoundCreate 
>> symbol, call it to get a Csound instance, and then use the function pointers
>> to access the host API.
> 
> You can still do that if you include both csound.h and csdl.h (in this
> order), or get the address of each API function to be used separately.

Well, actually if you do not link against libcsound, then it is enough
to include csdl.h, as the only additional feature of csound.h is the
function prototypes, and those are only useful if linking to the library
is done at build time.
However, if both the 32 and 64 bit versions of libcsound are to be used
by the same host, the declaration of struct CSOUND_ will not be correct for
one of the float types; this should be worked around somehow.

Thanks again for the help.

Istvan Varga wrote on 10/1/05 6:01 AM:

> You can still do that if you include both csound.h and csdl.h (in this
> order), or get the address of each API function to be used separately.

Ah!  I did not realize that this was still possible.  Good to know.
I think that it will be possible to decouple the host from the Csound
library using the information you've given me so that I can use multiple
libraries.

Thanks!

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote on 10/1/05 12:52 PM:

> Well, actually if you do not link against libcsound, then it is enough
> to include csdl.h, as the only additional feature of csound.h is the
> function prototypes, and those are only useful if linking to the library
> is done at build time.

Excellent!

> However, if both the 32 and 64 bit versions of libcsound are to be used
> by the same host, the declaration of struct CSOUND_ will not be correct for
> one of the float types; this should be worked around somehow.

OK.  I have not looked at the code here yet, but I assume that if I keep my
32-bit and 64-bit callbacks in separate files, that I can probably control
whether USE_DOUBLE is defined or not in each.

I was kind of concerned last week that the RTPlay callback signature had
changed to 

void (*)(struct CSOUND_ *, const MYFLT *, int)

The middle parameter used to be void* and I had code to deal with casting it
to either float or double as necessary.

But perhaps this will not be problem -- I can at least define two different
callbacks I suppose.  (Although ... will I have to have two separate pieces
of code for setting the callbacks as well??  Hmmm ...)

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net