Re: The music notation market

Date: Sat, 10 May 2003 09:52:58 +0100
Newsgroups: comp.sys.mac.apps,rec.music.compose
Size: 5,432 bytes

In article <email-address-deleted>, Ioannis <email-address-deleted>
writes
>David Webber wrote:
>
>[snip]
>
>> .abc is an interesting simple ASCII text format, which is getting
>> higher up my to-do list. My *impression* is that it is rather
>> elegant for simple pieces but might not represent all the bells and
>> whistles of notation - I look forward to being corrected if I'm
>> wrong. :-)
>
>.abc is an interesting format, but can be no more than a toy to serious
>music programs and exchangers. My program has the capability to export
>as "multivoice" .abc, which is an abc extension implemented very nicely
>by Phil Taylor's BarFly.
>
>The essential limitations of abc come from its very definition, as an
>easy method to transfer and transcribe single-voice tunes of Irish folk
>music. I don't know how other programs handle abc, but BarFly does a
>terrific job with the multivoice format output.
The 2 big assets which abc has is
1. the sheer number of files available, which probably run into the tens
of thousands.
2. It is readable with practice by human beings.
While the base definition is for simple melodies it does have extensions
into chords and parts.
Music Publisher 5 is shortly going to include abc file import and export
due to pressure from users.
But, why "Irish" folk music only?
>
>I've had problems with Melody Assistant recognizing my multi-voice abc
>exports, but BarFly imports it with no problems.
>
>> NIFF (.nif) (which has been around since about 1995) and more
>> recently music XML have been designed for notation interchange. But
>> neither has taken off as much as they might. I have explored NIFF
>> and the problem with importing it (which MOZART 7 does) is that it
>> is just so flexible - one of its design desiderata. :-)
>
>The future of musical interchange is in Music XML. NIFF is a decent
>format, but it is mainly graphics oriented, as such it cannot retain
>many of the more elaborate bells and whistles which relate to
>performance.
It depends what you want notation software to do! If it's to produce
notation then performance is for the player: if it's to produce sound
then you could be right.
IMO the more graphics orientated a standard is the better it serves the
notation market. I would also add that the best interchange format is a
PDF/GIF/BMP format of the printout for the same reason. And with good
scanning input these days this becomes more realistic.
>
>I've made an effort to implement NIFF exports with Virtual Composer, but
>the lack of documentation, the obscure file format and the very complex
>internals of the specs made it almost impossible. I won't even bother
>with it any more.
>
>To give you an example: Lime for Mac, which I consider to be the best
>NIFF importer/exporter, crashes badly when trying to import a silly,
>simple, single staff programmatical example which no notes, and no
>signatures. And this example is on the NIFF development kitt.
>
>Music XML on the other hand is a pleasure to use. Although I use only a
>large subset when exporting from Virtual Composer, most programs I've
>tried, import the text without any problems whatsoever. Although all the
>examples in my download are of course Mac, I've had users who were able
>to import all the pieces to Finale for PC, using Michael Good's Dolet
>Music XML import module.
>
>BarFly also is able to import Music XML successfully.
>
>The only single drawback of Music XML is the huge size of the text
>files. However, (and this is its big plus), being a text only format, it
>can be compressed with zipit or stuffit to sizes with ratios of ~10/1.
>
IMO MXML is ridiculously verbose. The files are almost certainly about
3-4 times longer than they would have been with a shorter choice of
keywords. Consider
<note> <pitch> <step>E</step> <alter>-1</alter> <octave>5</octave> </pitch> <duration>12</duration> <tie type="start"/> <lyric> <syllabic>end</syllabic> <text>The</text> </lyric>
</note>
to represent a single Eb with a word underneath and a tie to the next
note
Even normal HTML has <B> and </B> for "bold" - surely basic concepts
such as step, octave, duration could optionally have been shortened to
one character?
It's also rather clumsy with <backup> and <forward> concepts when a part
divides into two - as most keyboard parts do every few notes which imo
shows the standard was not thought out by musicians but rather Midi-
based musicians.
I've not gone into the format a long way yet, but I haven't yet seen a
"horizontal position" feature for the notes. For musical reasons a
composer may want more space for a note than normal, maybe when using
"spacial" notation or other. If I'm wrong then I will be pleased to be
corrected, but the lack of graphics orientation is a severe loss if it's
not there.
>Compressing a 500K Music XML file exported from my program with stuffit,
>reduces the file loselessly to 8-10K.
I think the size issue is important. Yes, because of the repetition it
zips down to a tenth of the size - but most musicians have no idea what
zipping or stuffing a file even means and the music will remain in full
on web sites I am sure, all leading to the same bandwidth overload that
emails in HTML are contributing to.
Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland