The score manipulation functions you suggest already exist to some extent,
not in the Csound API, but in the CsoundVST API. CsoundVST inherits from
CppSound, which is a C++ wrapper on the Csound API, plus CsoundFile, which
is a container for Csound score and orchestra files with functions for
adding and getting score lines and instruments.

The parse/error report function is a great idea. I'm not sure how easy it
would be to implement in advance of the parser. In CsoundVST, you can see a
printout of the compilation process complete with error messages, but this
is not returned in an error callback or error buffer.

----- Original Message ----- 
From: "Anthony Kozar" 
To: "Csound Developers Discussion List" 
Sent: Thursday, June 24, 2004 10:25 PM
Subject: [CSOUND-DEV:4845] Score API, et al.


> After sending my summary of the changes in Csound 5 to the main list
today,
> I began thinking about what other changes might be wanted or needed.  Here
> are some ideas that have been brewing in my mind for awhile.
>
> On 6/24/04 12:32 PM, Anthony Kozar sent the
> following to the Csound mailing list address :
>
> > 4)  Completion of, and refinement of the Csound host API.  With this
change,
>
> It has been discussed here before, and I think there are some gaps in the
> API that should be filled, especially with respect to syntax checking and
a
> true API for allowing hosts to manipulate scores (and orchestras?) without
> having to implement their own parsers.
>
> First, I think there should be two calls in the API so that a host can ask
> Csound to check the syntax of a score or an orchestra, without performing
> any other processing.  The calls should be able to return information
about
> the nature of any errors and the (first) line(s) that caused the problem.
> This should be more flexible, I think, than simply returning an error
string
> (e.g. return a line number and an error code) so that the host can create
> its own error messages.  A standard list of error messages that correspond
> to the error codes would be useful however.
>
> The need for a Score API with calls that can parse a score and return it
in
> a malleable data structure as well as perform common changes seems
> imperative to me.  At one point, Michael suggested exposing the existing
> Cscore functions in the API.  This would be problematic since they have
> fallen greatly out of touch with the many changes in the score syntax in
> recent years.  However, I could see rewriting them, making them more
> flexible and robust -- able to handle scores with the newer event types,
> expressions, macros, etc.  I see no real need to maintain backwards
> compatibility here, but we could still call the result "Cscore."
>
> I would like to work out a more detailed proposal on these ideas if others
> agree that they are worthwhile.
>
> > 6)  Csound 5 will include a simple command-line host application so that
> > Csound appears to work as it always has.  A simple "cross-platform,"
graphical
> > host is being considered as well.
>
> There has been a lot of talk lately on the main list about having a
> graphical front-end that will run on "all platforms."  I think we know how
> much of a problem this could be to actually make it work.  John Ramsdell
has
> given us flCsound but it requires FLTK which is problematic for me.  His
> previous work though on wxCsound has interested me.  There is (or at least
> was) a port of wxWindows to MacOS 9 so it may be possible to make wxCsound
> run on at least OS 9, OS X, Windows, and Linux.
>
> What do all of you think?  What about Python and Tkinter as a possibility?
>
> > 8)  Replacement of the existing orchestra parser with a new more robust
parser
> > written with Bison/Lex.  It is hoped that this change will solve some
bugs and
> > make the code more maintainable and more easily extensible in the
future.
>
> I have been experiencing a lot of problems with score interpretation
> recently as well.  Does anyone think it would be beneficial to redesign
the
> score parser as well?
>
> This could complement the above work on revising Cscore.  I think it would
> be useful to be able to perform different phases of score interpretation
> separately as well.  For example, it would be nice to be able to stop
after
> only expanding macros, or to go as far as interpreting expressions,
carries,
> and ramps but not to perform the tempo warping.  (I am assuming that the
> output here would be a new score).  My understanding of the way that score
> interpretation is currently handled makes it sound as if it could be
> difficult to adapt the current parser to only perform select processing.
>
> As for bugs in the current parser, I have noticed a few.  If more than one
> t-statement is in a section, Csound prints a warning but interprets
> successive i-statements as having too many p-fields.  (Yes I know that
there
> should not be more than one t-statement per section, but it is still a bug
> :)
>
> I've noticed that an "i0" statement in a score can cause Csound to crash.
>
> And when the subject of repeat structures in scores came up a few weeks
ago,
> I was unable to figure out how to get the m- and n-statements to work -- 
the
> example in the manual would not work for me.  (I would like to make a
> proposal for a more flexible repeat syntax as well -- only being able to
> repeat entire sections serially is not satisfying everyone's needs).
>
> I've also noticed some bizarre things happening with Cscore being called
> from within Csound ...
>
> I'm interested to hear what your thoughts are on how we should address
these
> issues.
>
> Thanks.
>
> Anthony Kozar
> anthony.kozar@utoledo.edu
> http://akozar.spymac.net/
>
>