<sigh>
You are absolutely right, XML is extensible, logical, and clean - to
parsers. There are even music-related DTDs. Maybe we should
write _all_music in XML - get rid of those funny dots, and stop
pretending that an open oval _really_ somehow has a time value
equal to four times a closed oval with a tail...
</sigh>
Lets have a little reality check here, and ask ourselves a couple of simple questions:
Why are there almost twenty thousand tunes freely available in abc format
on the internet, more than two orders of magnitude more than any other format?
Well, the answer is obvious - because people put them there, right? OK,
but who are these people, and what is it about these particular tunes that
makes people want to put them on the internet?
Well, most of these people are musicians, interested in traditional music,
by far the bulk in Irish and Scottish music.
The culture around this kind of music is a culture of tuneswapping, where
someone says "do you know 'The Maid Behind the Bar' ?" and the
tune gets played together. "Where did you get that tune" is answered usually
by naming a recording, another player, infrequently a book, and increasingly from the
Internet.
So what is it about these tunes?
- they are simple in structure so they can be entered quickly
- they are in the public domain so posting them is not a problem
- they are current in a culture of tuneswapping, so there is a real incentive to add
them
to the common repertoire.
The internet, and in particular the wwabc index has become the most convenient
place to locate the music for tunes in the Irish tradition, because of the work of
people like Henrik Norbeck, whose tunebooks were, IMHO, the critical mass for
abc repertoire. Most players could spend their whole lives just playing from them!
There are other reasons for using abc - it is much faster to touch-type than
most drag-n-drop music editors, it has the best multi-platform support, it
is small and easy to store, it is, above all, human-readable.
As we start extending abc, we should give preference to supporting features
that encourage the largest possible freely available repertoire:
- better support for other forms and cultures of traditional/public domain music
(Balkan modes, Klezmer ornaments...)
- other tuneswapping cultures ((this is where multivoice comes in), like
campfire songs, the sacred repertoire)
I would be the first to encourage an abc-XML translator, in fact I've toyed with
the idea myself. But I have a vested interest (as a musician, not a programmer)
in keeping the flood of tunes coming, so I want to keep abc as human-friendly
as possible, while adding features that encourage tuneswappers to keep entering
tunes in as many cultural traditions as possible. Let them think music, not XML.
wil
John Henckel wrote:
> At 10:14 PM 1/2/2001 +0000, John Chambers wrote:
> >Maybe we should just quietly do away with the "header" vs "music"
> >distinction. There are "header lines" and "music lines", which can be
> >in any order that makes sense. ......
>
> This is such a lively discussion that I felt I must really get my oar in
> the water as well.
>
> Do away with the "header" vs "music" distinction??! That a radical idea,
> but not radical enough.
>
> In case you guys haven't noticed, there is a revolution happening right now
> called the "Internet" and at the heart of it is a thing called XML. If you
> ever want ABC to have any kind of widespread acceptance you MUST be XML
> compatible. I used to scorn XML because I didn't understand it. XML is
> not HTML, it is far superior and far more useful than HTML. see
> http://www.w3.org/XML/
>
> Instead of
>
> V: soprano
>
> you've got to have
>
> <voice id=soprano>
> ..... contents of the voice .....
> </voice>
>
> I know that the syntax is a little revolting, but it has two HUGE advantages.
>
> #1 -- it is XML compatible, therefore ABC will be immediately compatible
> with thousands of parsers and browsers and tools.
>
> #2 -- it has a very clean, logical, and extensible syntax.
>
> I know that people are going to start whining "What about all my legacy
> code and legacy data?" No problem. Just write a little perl script to
> convert all your data. And the code? Just rewrite it. Well designed
> software should be easy to rewrite. If it isn't well designed, then throw
> it away and start over.
>
> John Henckel alt. mailto:[EMAIL PROTECTED]
> Zumbro Falls, Minnesota, USA (507) 753-2216
>
> http://geocities.com/jdhenckel/
>
> To subscribe/unsubscribe, point your browser to:
>http://www.tullochgorm.com/lists.html
--
Wil Macaulay email: [EMAIL PROTECTED]
voice: +1-(905)-886-7818 xt2253 FAX: +1-(905)-886-7824
Syndesis Ltd. 28 Fulton Way Richmond Hill, Ont Canada L4B 1J5
"... pay no attention to the man behind the curtain ..."
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
