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
