|
Actually the latest round of V: discussion that I
remember reading contained an example which was acceptable to BarFly together
with a conjecture that Muse probably wouldn't like it, but in fact it was quite
acceptable to Muse. I believe that in fact there is a large common
subset. (In this case I think Muse is a bit more generous because Muse
digests the whole file and translates it into an internal format whereas BarFly
formats the bars on the fly as it were and so has what is sort of equivalent to
the usual sort of "one pass" syntax restrictions.
Laurie
----- Original Message -----
Sent: Monday, November 12, 2001 10:52
AM
Subject: Re: [abcusers] developing the
standard ......
Anselm Lingnau said -
>Nothing should go in the
>standard unless it has been
proved that it is actually implementable
>with reasonable effort. This
may mean that sooner or later one might hit
>a dead end with some
feature or other, but it will be much harder to get
>the standard fixed
if the feature in question is already part of it,
>than to get the
feature fixed *before* it goes into the standard. Of
>course if
implementors insist that once they have implemented something
>then it
must absolutely stay the way it is, then this approach doesn't
>work.
However I think there is merit in trying things on a strictly
>experimental basis without encouraging users to base their
multimegabyte
>ABC archives on those particular features that are being
tested.
There is no "sooner or later" or about it. This is what
is already happening. A notable example being the V: command.
There is a sort of Catch 22 which says "Well I have to try it out to see
if it works" followed by "I've put all that work into it and my users
like it so I'm not taking it out now."
I don't think we can stop
developers innovating but can we get them to at least keep everybody else
informed and modify what they are doing if there is a clash?
Phil
Taylor recently said -
>Before you start work, download BarFly,
MUSE, Melody Assistant
>and all the other programs which you don't
normally use. Read
>the documentation and use the programs until
you know what they
>are capable of.
The wrong way round
I feel. Surely it is the responsibility of developers to keep the rest
of the community informed of their innovations; not just just in their own
documentation but in some central easily accessible place.
Bryan Creer
|
