We have discussed adding the CScore functions. I think this is a good idea. Please discuss your scheme for doing so with examples of how they might be used -- that would be extremely helpful.

Regards,
Mike

-----Original Message-----
From: Anthony Kozar 
Sent: Sep 30, 2005 2:50 PM
To: New Csound Developer list 
Subject: [Cs-dev] Questions about modifying CSOUND_

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
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
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

Michael Gogins wrote on 9/30/05 4:26 PM:

> We have discussed adding the CScore functions. I think this is a good idea.
> Please discuss your scheme for doing so with examples of how they might be
> used -- that would be extremely helpful.

I don't know what my "scheme" should be yet :)

Most of the Cscore functions had to be modified to take a CSOUND* argument
because they use a large number of statics to keep track of internal state.
So, backwards compatibility with old user cscore() code is already not
strictly possible.  (Although maybe a set of optional macros could be
defined to help this situation).

(BTW, does anyone know why lsort, lrel, lrelev, and lcount were not changed
to take a CSOUND* argument??)

So, I think the questions before us are whether the Cscore API should be
directly exported along with the rest of the API or should they just be
available as function pointers in CSOUND_, (or both);  whether their names
should be changed and how significantly; and whether we should continue to
provide a libcscore library with the distribution that contains only the
Cscore API and the cscore main() function of the past.

Regarding the names of the functions, many of them are very brief and
cryptic, and they currently lack any sort of prefix like "csound."  The
question I guess is should functions like createv and lcreat remain

EVENT  *createv(CSOUND *, int)
EVLIST *lcreat(CSOUND *, int)

or should they be changed to one of the following:

A  EVENT  *cscoreCreatEv(CSOUND *, int)
   EVLIST *cscoreLCreat(CSOUND *, int)

B  EVENT  *csoundCreatEv(CSOUND *, int)
   EVLIST *csoundLCreat(CSOUND *, int)

C  EVENT  *cscoreCreateEvent(CSOUND *, int)
   EVLIST *cscoreListCreate(CSOUND *, int)   (or cscoreCreateList)

D  EVENT  *csoundCreateEvent(CSOUND *, int)
   EVLIST *csoundListCreate(CSOUND *, int)

My preference would be option C.  (Although, again, macros to transform the
old names/syntax into the new format might not be a bad idea).


One of the exciting possibilities of having the functions in the API is that
host applications can set a Cscore callback and use the functions to
manipulate scores with its own internal mechanisms.  If a graphical
interface was constructed for some common operations, the host could create
a variety of Cscore processors without the user having to write any code.

Of course, bindings to other languages such as Python could benefit from the
availability of these functions.

Standalone Cscore programs would still be possible, but the cscormai.c code
would just become a client of the API like any other host.  However, to make
this possible, I think that the function cscorinit() will have to be added
to the API as well.

Hmmm ... Comments?  Other possibilities?

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:

> Most of the Cscore functions had to be modified to take a CSOUND* argument
> because they use a large number of statics to keep track of internal state.
> So, backwards compatibility with old user cscore() code is already not
> strictly possible.  (Although maybe a set of optional macros could be
> defined to help this situation).

I would rather not have "Csound4 compatibility macros" again; it was
more than enough work to remove all those that previously existed
(such as #define ksmps csound->ksmps and the like).
While macros may allow for easier porting of old code, they result in
confusion and problems later.

> (BTW, does anyone know why lsort, lrel, lrelev, and lcount were not changed
> to take a CSOUND* argument??)

Perhaps no one used those functions and the problem was not noticed.

> C  EVENT  *cscoreCreateEvent(CSOUND *, int)
>    EVLIST *cscoreListCreate(CSOUND *, int)   (or cscoreCreateList)
> 
> My preference would be option C.

These should be good, although if there are many types like EVENT
or EVLIST with simple names defined, it may be preferable to move
the Cscore interface to a separate header that is not #included by
csound.h, to reduce namespace pollution.


-------------------------------------------------------
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

I was working over the weekend, so I was unable to do any more with this
Cscore stuff.  Hopefully, I will get some code committed sometime this week.

Istvan Varga wrote on 10/3/05 5:28 AM:

> I would rather not have "Csound4 compatibility macros" again;

OK.  There are so few people using Cscore that I do not think backwards code
compatibility will really be much of an issue.  Once a new Cscore API is
available as part of the library though, I hope that usage of Cscore from
host apps and scripting languages will become more appealing.

>> (BTW, does anyone know why lsort, lrel, lrelev, and lcount were not changed
>> to take a CSOUND* argument??)
> 
> Perhaps no one used those functions and the problem was not noticed.

This may have been an oversight.  I will investigate and see if the
signatures need to be changed.  I think it would be better to be consistent
and have all Cscore functions take CSOUND* even if they do not use it unless
there is a reason that some cannot.

>> C  EVENT  *cscoreCreateEvent(CSOUND *, int)
>> EVLIST *cscoreListCreate(CSOUND *, int)   (or cscoreCreateList)
>> 
>> My preference would be option C.
> 
> These should be good, although if there are many types like EVENT
> or EVLIST with simple names defined, it may be preferable to move
> the Cscore interface to a separate header that is not #included by
> csound.h, to reduce namespace pollution.

I will go with these longer names then and not worry about the fact that
they are so different from the old names.

Regarding a separate header, this is already the current state of things
(everything is in cscore.h).  Given that the Cscore functions will be used
from a host, and might someday be used from plugins, as well as keeping
standalone Cscore programs as a possibility, perhaps keeping the Cscore API
and types in a separate header would be a good idea.

I will post more once I have things working.

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