Exu Yangi wrote:
<Snip>
Ah, yes. What do we output? Once again, the number of output technologies available in common would seem to indicate either XML or INI format. They are text based, and portable assuming we ignore the wierd end-of-line marker problems on Macs.Maybe I'm stupid, but I don't understand this bit of the conversation. I would expect that a parser would not have ANY form of structured output for an entire tune, or an entire book of tunes. I don't understand why anyone would want to write a parser to parse a file and then spit out a new file (or buffer) of stuff that then itself has to be re parsed to be used???
I would vote for XML.
I envision the parser working something like this.
a. Program X is responsible for helping the user locate the file to be opened, whether url, or local, whatever.
b. if that file is to be buffered, then it is read in to a buffer. If the program wants to stay small on memory, the file identifier is kept.
c. a reference is created to the buffer... or, if using a file, a reference to the file and the file is locked.
d. invoke the parser using the reference to map the contents of the file.
e. the parser does a once over look at the file and determines the Start/Stop extents for each tune in the file... Automatically email headers, html, etc are made pretty much null and unreferenceable. From this action, number of tunes in the file can easily be determined.
f. the parser stores this information for further reference to be queried at need until the session with the parser is closed.
g. the program now knows how many tunes are in the file... It can now begin asking the parser to look at contents between each START/STOP extent to look at the individual tunes.
Step G would be where the useful API would come in... A useful command set of queries and manipulations that could then be run on one tune, or many tunes.
Program X would be responsible for writing out the buffer, or overwriting the file and unlocking the file on close.
Am I missing something? Why would there be an xml output or some such. What if that's not the format the programmer wants to use to organize and reference the data in the tune file?
(I hesitate to suggest it, as I rejected the idea of ASCII output, but MusicXML might be a useful format, at least as an option, as there is already an XML parser available)
The only problem with MusicXML is that is will not transcribe many types of music. Other than that, it works just fine ... <sigh/>
<Snip>
--
//Christian
Christian Marcus Cepel | And the wrens have returned & [EMAIL PROTECTED] icq:12384980 | are nesting; In the hollow of 371 Crown Point, Columbia, MO | that oak where his heart once 65203-2202 573.999.2370 | had been; And he lifts up his Computer Support Specialist, Sr. | arms in a blessing; For being University of Missouri - Columbia | born again. --Rich Mullins
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
