> I'm in a software engineering course this semester, and we've decided we'd > like to go at adding another product to realm of available 'abc' tools. [...] > Right now, the idea is based mostly on writing new file format which will > implement the current standard of ABC. We want to write our program > to implement fully, and not expand at all on or deviate at all from the > specifications of the current standard. However, we wish to develop a > new file format which will contain standard abc notation _plus_ layout > information generated by our program. Speculatively, we would call it > something like abl (abc with layout), but we've not gone far as of yet > to discover what registered existing filetypes are out there.
Why do you need any new format? ABC already has comment lines, and some programs use special-purpose comment lines like BarFly's "%%Bfly" lines to encode application-specific data. So why not just put your extra stuff in "%%ABL" lines scattered through the source? - that way your files will just be standard ABC files and any ABC application will be able to use them. The effect of adopting a new format would be to limit the use of your software. To some extent this already happens: Muse uses a similar approach to the one you're suggesting, and nobody uses Muse files as an interchange medium - if the Muse-specific information had been done via comment lines, other ABC users would be able to use Muse files as is, and pehaps transmit them onwards to other Muse users. BarFly has a similar problem: certain information can be encoded in resource forks, but as that's totally Mac-specific, nobody ever uses it in a publicly available ABC file, and there is no easy way for it to be transmitted from one Mac user to another via a non-Mac system. (The only thing I ever do with it is drop my files onto the "Res Fork Killer" utility to get rid of it). > We anticipate using a base 16bit unicode file format Why? The only benefit I can see from that would be in extending ABC to cover non-ASCII character sets, which would be no bad thing but methinks would need to be done with a bit more consultation. (Also, it doesn't make a lot of sense to allow for Arabic or Devanagari script when ABC isn't yet capable of encoding Arabic or Indian music). A final point. One of the core advantages of ABC is concision. People who use ASCII-based file formats don't like bloat. If your software leads to people being emailed things as pointlessly humungous as Microsoft Word files or Outlook-generated HTML-tagged text when a few K of plaintext would do, you're not going to make any more friends than Microsoft have done. So you need to keep extra layout data to the bare minimum, and extract as much formatting information as possible from the ABC itself - e.g. instead of encoding stem direction for each note individually, use a heuristic to cover most cases with necessary exceptions marked locally. BarFly's stemming heuristic (which doesn't let you do anything about the exceptions :-( ) is correct about 95% of the time, so such a policy could cut the amount of stem-direction data you need to store by a factor of 20. =================== <http://www.purr.demon.co.uk/jack/> =================== To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
