I think my notion of modularity has been somewhat mis-represented.
Perhaps the idea as other folk have it is a good one, maybe better than mine.
I'll leave that decision to others [1], but as I think my original notion has
been misunderstood, I'll try and explain it a bit better than I did the first
time.
ABC has too many uses as it stands. It was designed to notate a single stream
of monotonic, diatonic melody. Now it is being used for everything and their
grandmother's kitchen sink. It's a testament to the developers and standards
people that it's been able to grow from these beginnings, but it's starting
to creak at the seams. Those who attempt typesetting with abcm2ps soon learn
to give up any notion of readability, likewise any hope that their efforts
will be of any use to any other piece of software, at least in terms of all
the meta-work that went into it. I'm sure other package users have similar
problems.
What I'd like to suggest (and it is only a suggestion; I certainly don't have
the skills to implement anything of the sort) is a completely open system,
where notation itself is just one element. The user would be able to specify
(I'm trying not to say 'scripting language' here) the behaviour of the
application, from parsing setup, playback instructions, through to being able
to deal with actually drawing in a custom manner.
What this means:
A scripting language. I've been thinking about this, and wondering if it
really is neccesary, and I think it is. What I envisage is a system where
everything is done in terms of this scripting language, running on top of an
application (ie postscript, MIDI, whatever). The entire default source for
this is available for the user to view, and the user can insert custom
modifications into his own files. What I imagine is a kind of tree
structure, analogous to the Javascript document model, where you might have:
source.draw.line.stave {
goto clef_start_point
draw_clefsymbol
loop_of_some_sort(5) {
goto point_to_draw_from
draw line
}
}
Now suppose our user wants to draw a drum stave, for notating percussion. He
just inserts in his file:
source.draw.line.stave {
goto clef_start_point
draw_custom_drummer_symbol //kinda wingin it here
goto point_to_draw_from
draw line
}
Obviously, there's a few holes needing filled in (!), but I hope you get the
idea.
All this is obviously a bit much to expect from users; this is where the
modularity comes in. Included with MagicalABC [2] are dozens of files of
custom code, which you can include in your own files, for all sorts of unique
and clever purposes. Users with specific individual needs, like pipers or
microtonalists, can just read the help file for their particular module, and
the majority need never worry about it. Those who suddenly decide they want
to do something new and exciting can go about hacking away without having to
try and figure out how the entire application works and recompile it, even
assuming that's an option for them.
The idea is that the standard scripts would implement what is currently done
inside applications, doing the pre-processing, parsing, and outputting some
sort of standardised stream to the actual application engine. The default
should be some widely recognised ABC standard, whether 1.6, 1.7.?, or Guido's
ABC 2.0. It also makes sense, BTW, for the scripts (and engine?) to be GPL
or some similar license (perhaps BSD would be more reassuring to developers
whose food depends on their work), so developers don't all have to go
implementing their own, and ending up with something like the STL was back
when I could program.
This whole approach means basically starting again, creating a scripting
engine, reimplimenting the applications in the scripts themselves, and
creating a surface layer to do what the thing is supposed to do (write
postscript, etc). [3]
OTOH, I think in the long run, it could be less work. If the output from the
scripting engine is well defined and documented, and free from user inserted
daftness or clumsiness, then that should be easier for developers to work
from. Yes/No/Maybe? Also, it means that output is simplified; just output a
plain text description of your format along with the neccesary script to deal
with it.
As I said before, I'm strictly an ideas rat. I have enough knowledge of
programming to talk about it, but not enough to do it. Maybe I should work
at the BBC...seriously, I think this approach has merit, or it will have once
some folk who know what they're doing have had their way with it. At the end
of the day, none of us can see all the uses ABC or its descendants might be
put to, and to try to cater for them all is courting disaster.
I'd be interested to hear what developers in particular think of this notion,
not so much in terms of their particular application, but the idea itself.
Cheers,
Calum
[1] - My argument against modularity is that it sounds like something that
developers won't implement; one can imagine developers creating an import
filter for the core spec, slapping a "Imports ABC!" label on the box, and
shipping it out. Users then get shafted when they discover that no-one is
actually likely to develop an extension for their particular special-purpose
module.
[2] - Apologies if this actually exists.
[3] - Not entirely sure what the output streams are; I imagine there would be
three: a playback stream, which might be convertible into MIDI or wav; a
drawing stream, which would contain instructions on how to draw the music;
and a "pure music" stream, which would describe the contents of the file as
fully as possible in a independent kind of way (not entirely sure what this
means myself, so don't worry about it). This last would probably be the
stream that input filters might use.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
