[Why did I get into this? oh well...]
[EMAIL PROTECTED] wrote:
> Wil Macaulay says -
>
> >But any text within double quotes that _does_ start with one
> >of those symbols can be safely used as an annotation, so IT IS NOW POSSIBLE
> >to write an abc file that can be safely played by abc2midi (or BarFly, or
> Muse) and
> >properly displayed by abc2ps (or BarFly or Muse).
>
> I seem to recall that during the debate on the sharps/flats version of the K:
> command you said -
>
> >if you write your abc/Noteworthy converter to use a version of abc
> >that is not in the 1.6 standard (I'm not even talking about 1.7 extensions
> here)
> >you will be creating tunes that are not readable by abc2win, which is the
> >most common abc platform for windows. Bad move.
>
> I quite agree. Have you changed that advice?
Not at all. If you are using abc as an output format, you are well advised
to use a lowest-common-denominator form. I have argued in the past for
a way of identifying abc versions - something like
%abc 1.6
as a header line, which would help when using it as a formal interchange
format. It would be impossible to enforce its use for people who write
the files directly.
>
>
> >Here's where I really believe that you just "don't get it" - software DOESN'T
> >produce abc, people do.
>
> And guns don't kill people or perhaps an analogy closer to home would be
> "Instruments don't make music, people do." But that doesn't absolve
> instrument makers from responsibility for the quality of their instruments.
> Musicians can make better music with better instruments.
>
And better instruments cost more. Should we stop the production of $50
guitars because they don't sound as good?
>
> >People will twist it to serve their own needs, if
> >they don't have a good way to do it in the standard, and if those needs
> >are seen as useful to multiple people they will get addressed, eventually.
>
> There is a maxim in the commercial computer world that says "Don't start the
> development until you've finished the design." Since this is almost never
> observed it is cynically twisted to "Don't finish the development before
> you've started the design." The latter seems to be policy in the abc
> community.
>
This is not commercial development. This is a bunch of people who saw something
useful _TO THEM_ that they picked up on, and then made it available to others
who might also find it useful. I ported abc2ps to the Mac because I was fed up
with having to do stuff at work. I could have kept it to myself, and I would never
have bothered if BarFly had been available. I wrote Skink because I wanted to
see how hard it would be to use java tools to write a recursive descent compiler
for abc (non-trivial, by the way, abc is just irregular enough to be frustrating).
I can honestly say that if I didn't see some programming issues that I don't
know how to solve right away, I wouldn't be doing this. I've been doing commercial
development for 20 years and if the problems were easily solved I'd
be bored by them. This stuff is _hard_ , folks. Layout for printing,
flowcontrol for playing, getting the staff elements to look right. I have
enormous respect and admiration for Chris and Phil and Laurie and Jim and
Michael and James and everyone else who has started this from scratch
or built on existing code.
So Bryan, here's some advice for you, whether or not you want it. Pick your
problem (in other words, your marketing requirements). In your case it
seems to be Noteworthy<->abc. Decide how much you want to bite
off (restrict your domain to get your functional requirements).
There is likely a subset of the functionality of
each that you need to support in order to translate the files you care about
today. You may find there are missing pieces of functionality in Noteworthy
(which I presume you can do little about) or abc (now you have the opportunity
to hack an existing package and try to put it in). Decide how you will
go about it (design stage) and go for it (implementation and test). Iterate
from the the "Decide how much you want to bite off" stage to get to the
next version. Have fun.
In all seriousness, if we tried to design a solution to all the problems at once, we
would never start. That may lead to some blind alleys. Such is life.
>
> Phil Taylor says -
>
> >The problem here lies not with the proposed mechanism, but with the fact
> >that the original (v1.5 abc) guitar chord format permitted abuse, and we
> >can't go back in time and change it retrospectively.
>
> I'm afraid he is right. Presumably guitar chords were originally seen as
> simple text.
The original player programs didn't play chords, and the original
layout programs didn't distinguish between chords and other annotations.
It wasn't until people started writing programs to do transposition (in other
words, increasing the functional requirements) or play chords (ditto)
that it was an issue.
> We are stuck with the results but can't we learn from the
> experience and try not to make the same sort of mistake again?
>
I think that's exactly what we are trying to do, but we are not starting from
scratch, but from an existing body of abc.
>
> It sounds as if I won't be able to use Phil's transcription of the Goldberg
> Variations. Can they really be said to be written in abc rather than in
> BarFly output code?
>
BarFly _INPUT_ code, please. ;-)
>
> Bryan
>
> 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
