> As always, comments are welcome. Actually more than welcome! If none is
> interested I'll refrain to keep posting about it. Just let me know.
I am very interested in the work you're doing. Unfortunately, I have very
little time these days! Once in a while, I'll have a week where I can spend
a little time each evening on this, but not very often. If I had time, I'd
plunge right in the middle of the work.
Your "things to do" list is right on. Solving those problems are the key to
whether this project succeeds or not.
I'd define success as one or both of the following:
1) Everyone who is supporting ABC programs likes it and switches to this
parser so that every program will interpret files the same, now and forever.
2) A simple to use tool is available that makes it easier to create a new
ABC application.
For the first item to happen, the following must be met:
1) The parser must be conveniently available to every language and platform
that is currently and likely to be used for an ABC application.
2) There must be a firm standard of what code is legal in ABC, and there
must be backwards compatibility with ABC files that already exist that are
not standard. This standard must be embraced by every developer.
3) The API and internal representation must be both simple to use and
complete.
-------
I can't comment one way or another on Lua, since I'm not familiar with it.
If it is easy to use, and can handle all the syntax of ABC, I don't have a
problem with it. It also needs to be available on PC, Mac, and Linux. Some
research should be done on other choices to see if there is something
better.
As far as the API and internal structure goes, I think we should see if we
can borrow some work from others. That was my interest in MusicXML. If
they've got a good API and a complete internal representation, then we save
some work and some potential missteps. Also, any program that supports that
API would support ABC by simply linking the parser in.
-------
We all need to agree on the ABC standard. We all need to agree on the API.
Only the ones actually coding need to agree on the scripting language and
the programming language.
I don't agree with your statement "To keep things simple I won't use C++
with all his many unnecessary complications." What complications are you
thinking about? The advantages of object oriented programming are so strong
it seems silly to arbitrarily limit the development team. Can you even get a
C compiler anymore that doesn't support C++? It is simple to avoid name
mangling and v-tables in the API, if that is what you are afraid of.
I'd be willing to help as much as my time allows.
Paul Rosen
--- Life is a musical, every once in a while
the plot stops and you start singing and dancing ---
http://home.earthlink.net/~catharsis.music/
http://home.earthlink.net/~theplums/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
