Simon Wascher <[EMAIL PROTECTED]> writes:
> > The ABC representation of a
> > tune should give as much musical information as is reasonable but should
> > not specify how programs will make use of it.
>
> in certain cases it will have to allow exactly this in the future: For
> example by forcing display programs to display all copyright related
> information, usually the C: field and in case of traditional sources
> supported by an archive all informations the archive asks for to allow
> reproduction
I suppose that if I were to publish a 100-page volume of tunes from an
archive like that, it would suffice to give the full copyright
information once (e.g., at the beginning of the book), whereas if I
include just one tune from that archive in a 100-page book of tunes from
different sources giving the full copyright information with that tune
would be the proper thing to do (but then again maybe not directly below
the tune but in a cross-referenced appendix). Again this is a
presentation issue that is impossible to foresee in the ABC standard and
therefore should not be specified there, lest we have to change the ABC
notation for 100 pages' worth of tunes in order to get them ready to be
published. Also if I am reproducing tunes for my own personal use I am
not obliged (under German law) to display any copyright information at
all as long as I don't pass my reproductions along to other people. Why
should I then have to waste space on my paper? (Actually I do this a lot
-- an SCD arrangement of four tunes fits nicely on two A4 pages, but if
I had to put several lines' worth of copyright information and use
restrictions with every tune then this would no longer be the case.)
Crediting one's sources is a matter of courtesy even if it weren't
required by law. But since there is no way to `force' an ABC program to
do anything -- if an otherwise-nice ABC program insisted on putting
prominent copyright notices all over my private sheet music you can be
sure that the next thing I'd do is take the relevant code out or
(rather) make it conditional -- requiring in the ABC standard that
certain stuff MUST be displayed is a moot issue. If you don't trust
people to go along with your requests as to what they may do with your
ABC stuff then don't put ABC stuff on the Internet for everybody to
download (but you seem to have noticed that for yourself).
> So on an ad hoc basis :o) :
>
> Q:1/4=60 - Andante ma non troppo SEPARATOR whatever you want
Right. So we get `space' as the separator in the first part of the line
and SEPARATOR in the second part of the line. I can see how this is
very user-oriented and natural (see my reply to Laurie's message).
> > The idea is to keep musical stuff apart from presentation stuff.
> > Presentation details might go into a separate file, using syntax (like
> > CSS, if you will) that is more appropriate for the purpose than
> > bastardized ABC. In my opinion it is a very bad idea to mix musical and
> > typographic information like your `Q:1/4=60 -' proposal does -- even a
>
> I dont know if you got it: if a string of abc text should be readable
> for a display only program it must follow the same kind of syntax as if
> the abc program itself (whatever this is) should interprete this
> obligatory.
I don't know if *you* understood what *I'm* saying: The ABC-notated tune
could say something like `Q:1/4=60 display="Allegro"'. Then an ABC
display program could look at a `style file' to find, say,
metronome-speed { show=no }
(if the user wants no metronome speeds to appear at all), or
metronome-speed {
pos=after-textual-speed,
font=Times, size=10pt,
with-note=yes
}
for a detailed description of how the metronome speed should be typeset
(I'm just making this up as an example so don't hold me to this). This
makes for a clean separation of musical content and musical typesetting,
and incidentally would give the user of the display program much more
control about what would appear and how.
This type of specification is of course just as computer-readable as
the one where the (rudimentary) display control is intermixed with the
musical information on the `Q:' line, so I don't understand your
`syntax' comment above.
> > I keep going back to HTML but it really seems to me that we're about to
> > make all the mistakes over again that the HTML crowd made a few years
> > ago.
>
> in your statements, please keep in your mind that I do not understand a
> word about HTML, maybe other listmembers too.
I have explained this in more detail in my reply to Laurie. If there is
anything about this that you don't understand then feel free to ask,
either on the list or in private e-mail. In any case it is important for
us to learn from other people's mistakes in order to avoid repeating
them ourselves, so since the history of HTML is very relevant in this
context you should not dismiss it just because you don't understand it
right away.
Anselm
--
Anselm Lingnau .......................................... [EMAIL PROTECTED]
Experience is that marvelous thing that enables you to recognize a mistake when
you make it again. -- F. P. Jones
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
