Re: [abcusers] something really simple
Anselm Lingnau wrote:
Laurie Griffiths [EMAIL PROTECTED] writes:
It's your turn to say what you find unacceptable in the proposal put forward
by me and Simon (the two were pretty much identical).
As far as I'm concerned, the main problem with these proposals is that
the syntax they define is pretty much particular to the `Q:' field. So
we get a `-' here and a mandatory space delimiter there, and in another
please try to stay at the formal side with your postings. You kow that
this is not a fair way to speak about the hard work other people do. Its
not just here and there like in silly idiots. Bring up formal
arguments and alternatives.
The problem is that the Q:field is playback active *and* display active.
It may contain a numeral definition for the programs player *and* text
string for the person who reads it (in that case it does not matter much
*where* the numeral definition is stored, in a definition field, or a
macro file or with the program or inside the actual Q:field).
The same case with the V:, K:, maybe M: .
ABC standard seems about to be extended in all sorts of directions we
should instead be aiming for a consistent style of syntax that allows us
to express these extensions.
Yes.
For example if we accept the `key=value'
style of options in fields such as `K:' or `V:' then we should define
extensions of the `Q:' or `L:' fields in a similar fashion, for
consistency, instead of giving these fields their own syntax because in
the short term that seems to be the easier choice and sufficient for
`everything that is needed'.
So , do we accept the style in which the K: and V: fields are extended,
so are all those draft and program related syntax proposals using the
same style of syntax ?
As far as I observed the K: and V: field discussions where halted
whitout a decision on the right syntax. but for me:
Q:3/8=69 display=allegro
Q:3/8=69 display=allegro
both displaying just: allegro
or something similar would be OK to *me* (as I said I do not care much
what SEPARATOR is choosen)
All the discussion just started since it was sugested (and later on
verified) that there would be more user orientated and natural ways to
indicate tempo specifications (which only have the disadvantage that it
needs to make use of a extended syntax in cases where a n/n=n *playback*
tempo definition is not being displayed).
(This is incidentally why I would prefer
something like `L:1/8 grace=1/32' to `L:1/8 {1/32}' as proposed in
Ewan Macpherson's message, even though it may be wordier in the short
term.) Chances are that it won't be.
This keyword:value syntax *is* wordier, on long an short term, since it
wont shrink by being used. And its neither more natural nor user
orientated. But I will not object if this is common sense.
I have also tried to illustrate how
this approach lets us easily introduce further extensions in the future
-- something that is difficult to do if more ad-hoc stuff is heaped upon
the layers of ad-hoc stuff introduced in earlier rounds of updates --
but that doesn't seem to have got through.
You do a lot of ad hoc stuff too, if you define ad hoc stuff as syntax
that is newly introduced into the draft (do not forget: draft is not
standard). the whole keywoard=value syntax is not generally approved,
and whithin that there is no general approval for the quotes as
delimiters.
The other issue is one that I have expounded upon several times already,
namely that the ABC standard should as far as possible stick to
expressing musical content, and leave presentation issues like what kind
of ancillary ABC information is and isn't printed where and in what
style to individual ABC-processing software, which is where it belongs
and how most of this material (such as titles, guitar chords and the
like) is already being treated.
As pointed out this your argument does not stop the need of a stringent
syntax for this, since it does not much make a difference which part of
a program has to recognize a string.
and if features are not implemented, it may also cause people to include
%%programspecific commands whithin files.
Simon Wascher - Vienna, Austria
http://members.chello.at/simon.wascher/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Ah. Good. Nicely put. I have a lot of sympathy with this.
(So you now all realise that I have a lot of sympathy with *both* sides).
The problem is that we want something that is completely compatible with
everything that has gone before and that can be enhanced into the future
with minimal new kludges. There is a tension between the two.
Regarding the describe meaning vs describe action debate, often it can
turn into just playing with words. This is a description of the tempo
which is designed to be meaningful to the musicians I expect to play it may
be a better description but Look, mate, just print this, OK? results in
the same action almost always. However - where there is a difference, I
agree with you that abc should describe meanings rather than actions.
I'll see if I can come up with a keyword=value scheme that overcomes my
objections to Anselms scheme (in another post, with luck).
Laurie
- Original Message -
From: Anselm Lingnau [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 13, 2001 11:47 PM
Subject: Re: [abcusers] something really simple
Laurie Griffiths [EMAIL PROTECTED] writes:
It's your turn to say what you find unacceptable in the proposal put
forward
by me and Simon (the two were pretty much identical).
As far as I'm concerned, the main problem with these proposals is that
the syntax they define is pretty much particular to the `Q:' field. So
we get a `-' here and a mandatory space delimiter there, and in another
field, once we get around to discussing it, maybe a magic squiggle here
and a couple of dots there if that looks nice and useful. Now that the
ABC standard seems about to be extended in all sorts of directions we
should instead be aiming for a consistent style of syntax that allows us
to express these extensions. For example if we accept the `key=value'
style of options in fields such as `K:' or `V:' then we should define
extensions of the `Q:' or `L:' fields in a similar fashion, for
consistency, instead of giving these fields their own syntax because in
the short term that seems to be the easier choice and sufficient for
`everything that is needed'. (This is incidentally why I would prefer
something like `L:1/8 grace=1/32' to `L:1/8 {1/32}' as proposed in
Ewan Macpherson's message, even though it may be wordier in the short
term.) Chances are that it won't be. I have also tried to illustrate how
this approach lets us easily introduce further extensions in the future
-- something that is difficult to do if more ad-hoc stuff is heaped upon
the layers of ad-hoc stuff introduced in earlier rounds of updates --
but that doesn't seem to have got through.
The other issue is one that I have expounded upon several times already,
namely that the ABC standard should as far as possible stick to
expressing musical content, and leave presentation issues like what kind
of ancillary ABC information is and isn't printed where and in what
style to individual ABC-processing software, which is where it belongs
and how most of this material (such as titles, guitar chords and the
like) is already being treated. This is a very important distinction,
and for a famous and spectacular example of getting this wrong look at
HTML after Netscape and Microsoft were through with it. I would hate to
see the same thing happen to ABC.
Anselm
--
Anselm Lingnau ..
[EMAIL PROTECTED]
I think there is a world market for about five computers.
-- Thomas J. Watson, CEO, IBM Corporation,
1947
To subscribe/unsubscribe, point your browser to:
http://www.tullochgorm.com/lists.html
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something fairly complicated (Q: field)
Having watched this debate for a while, I feel obliged to make a comment. I think what is actually wanted is the ability to write Q:allegro because the word allegro was the tempo indicator in the original score. If a player program recognizes this and picks an appropriate tempo, then all is well. I believe that there are only a finite number of italian words used to indicate musical tempo, so this approach should actually be possible. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Hello, Anselm Lingnau wrote: I define `ad-hoc stuff' to be syntax that is used in one particular header field, such as `if there is a `-' after the metronome speed in a `Q:' field that means that the metronome speed is not supposed to be printed'. Why don't we allow a `-' after a composer name in the `C:' field so the composer name will not be printed? There are plenty of cases where one would want to have this facility -- for example, if you typeset Bach's Well-Tempered Piano you don't need to put `Johann Sebastian Bach' across the top of every prelude and fugue since the information is already on the title page of the book. Allowing such things in one place but not in another is one aspect of what I call `ad-hoc' syntax. Why not. I know you are convinced that it is important that abc does *not* allow this to be decided by the transcriber. But for me: why not. Again: My point is that the ABC representation of a tune should not say what must be printed and what mustn't, since it is impossible to foresee in what context the ABC is going to be used. 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 (that acctual programs do not do so is a big problem in the moment for me and a reason not to add any more tunes on internet). It should not be necessary to change the ABC representation of a tune just because it is supposed to be played back at a different speed this afternoon again, no sarcasm please, You know that the above was not part of any of my examples. The idea was to allow the transcriber to add a program readable speed besides a composer chosen textual tempo indicator, to make sure the playback does not fall to an incorrect default. Finally, let's for the moment stipulate that your proposal goes through and that we will be able to write Q:1/4=60 - Andante ma non troppo If you define that everything from `Andante' to the end of the line -- excepting a `%' comment, of course -- is a textual tempo specification then how are you ever going to put in another data field if that should become useful at some point in the future? So on an ad hoc basis :o) : Q:1/4=60 - Andante ma non troppo SEPARATOR whatever you want since the separator got out of use with the introduction of the minus but better ask those who opposed to the SEPARATOR idea about their oppinion abot the keyword=value proposal (as the keyword is in a way a kind of separator). [Musical content vs. presentation issues] As pointed out this your argument does not stop the need of a stringent syntax for this, since it does not much make a difference which part of a program has to recognize a string. 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. %%abctypesetter dont-display-metronome-speeds abctypesetter will fail if the abc syntax is not computerreadable. So If the Q:syntax says we wont care about display as a priciple, the %%abctypesetter commands may fail. and if features are not implemented, it may also cause people to include %%programspecific commands whithin files. Does that mean we need to put everything that could possibly occur somewhere in some kind of musical notation into ABC, just so people don't feel tempted to use `%%something'? In a way yes, not about everything that could possibly occur but everything thats possible . This would help to persist file exchangability. support or not. (And if you are in the business of sharing musical *presentation* -- like near-facsimiles of old musical scores: If ABC works for you in this context then more power to you, but people will like you better if you put up your formatted score as a PDF file alongside a very I *know* whats my business. My problem is that I would like to use abc formating for distributing music (filesize, exchangeability, playability displayability, its freeware) but in this case there are some things that tangent the display. 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
Re: [abcusers] Looking for ABC transcriber.
Buddha Buck wrote: I have a file called playford.abc, which I got from http://www.contrib.andrew.cmu.edu/~flip/contrib/dance/playford.abc. Unfortunately, it doesn't have any information on who transcribed it, or who owns the copyright, etc. Does anyone have any idea who wrote it? As far a I know, that would be Michael Robinson. A link to his site: http://www.sls.hawaii.edu/bley-vroman/contra/dances/playford.html -- bert van vreckem If Bill Gates had a nickel for every time Windows crashed... Oh wait! He does! To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
On Tue, 13 Nov 2001, Laurie Griffiths wrote: I'm not 100% sure what the right default is in the absence of a beat=. Is it the L value (explicit or implied)? I'd rather stay away from L:. A quick look through some of my collection shows that it would give the wrong beat more often than not. It could be treated as an error, but I would rather take a reasonable guess and give a clear warning instead. Perhaps this should be left up to the software, though. In any case, here's a fairly simple rule that would be right most of the time. Given a meter of Y/Z: 1. If Z is less than or equal to 4, beat=1/Z 2. If Z is greater than or equal to 8: a. If Y is evenly divisible by 3, beat=3/Z. b. Otherwise, if Y is odd, beat=2/Z (or 1/(Z/2)). c. Otherwise, beat=1/Z. Examples: 2/2 time, beat=1/2 (rule 1) 3/2 time, beat=1/2 (rule 1) 2/4 time, beat=1/4 (rule 1) 3/4 time, beat=1/4 (rule 1) 4/4 time, beat=1/4 (rule 1) 4/8 time, beat=1/8 (rule 2c) 5/8 time, beat=1/4 (rule 2b) 6/8 time, beat=3/8 (rule 2a) 7/8 time, beat=1/4 (rule 2b) 9/8 time, beat=3/8 (rule 2a) 12/8 time, beat=3/8 (rule 2a) etc. For M:none, assume beat=1/4. I would also suggest that once established, the beat should NOT change, even if the meter changes, unless accompanied by an explicit beat= or another Q: field. John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] possible abctab2ps extensions
I defintely don't want to have to write a Highland
pipe jig (typical grace = 1/32) like:
L:1/8
K:HP
{g//}A{d//}A{e//}A {g//e//f//}e2 f | {g//}ec{G//}c {g//e//f//}e2
How about
L:1/8 grace=1/32
K:HP
{g}A{d}A{e}A {gef}e2 f | {g}ec{G}c {gef}e2
Why the quotes?
I'd prefer
L:1/8 {1/32}
and for the functionality Ewan wants, setting this once and for all for
a bunch of tunes, have a line near the start of the file just saying
L:{1/32}
with the default length for melody notes unspecified and maybe varying
throughout the file.
: The format param=value is preferable because it is more flexible
: and allows future extensions.
In this case there aren't likely to be any future extensions, so
readability becomes a more important consideration. Even when there
are likely to be extensions, this syntax can be too ugly to consider;
e.g. for non-Western key signatures, would you really rather have
K:D Major second=_E sixth=_B than K:D Major _E _B ?
I think of the header fields in ABC as being typed, and *not* all of
type string. For such information alternative lexical syntaxes
are usually appropriate. The type of this field is presently that
of rational fractions and the proposal makes it a variant, rational
fraction or pair of rational fractions (or perhaps ordered pair of
[rational|NULL]). I can think of only one piece in all music where
you'd want anything different, Nancarrow's player piano piece where
the basic note lengths of the two parts are in the ratio 1:sqrt(2).
: And most important, it solves most compatibility problems: programs
: only interpret the param clauses which they know and ignore the other.
It's no harder for a program to ignore {1/32} than grace=1/32, is
it?
BTW, there is a seriously hairy problem with the semantics of variable-
length gracenotes in Highland pipe music. There are bunch of pibroch
transcriptions on the web which encode them in full gory detail using
the Piob Mhor notation; I don't have a machine which can process that,
but I think the effect is that it plays right while also generating the
usual sort of score, which has the timing oversimplified. I don't think
it's reasonable to ask the implementors of player programs to understand
details of interpretation that are normally passed on by oral tradition,
but if their software can accept gracenote groups like {ge4d} without
gagging and maybe play them as {ged} that'll do for a start.
But let's get tempo fixed first.
=== http://www.purr.demon.co.uk/jack/ ===
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Hello Anselm, Now we surely brought it to the point what divides us deeply. For reasons of scientific quality I need to include as much as possible information of the original source within the file, as near to the original as possible. So the file should be a representation of the playback *and* the the display. Do not say this is *not* the target of abc, there is no such thing as a restriction against display matters anywhere in the standard. Its *your* ideology about abc. For me abc is a way to create compressed, easily exchangeable, freeware, playback active representations of a musical source. Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Looking for ABC transcriber.
James Allwright [EMAIL PROTECTED] writes: Since Playford published his collections of music several centuries ago, you are pretty safe in assuming the copyright has expired. Yes, but it might be construed that there is copyright on editorial changes within the transcription, which may be more or less obvious. A lot of Playford stuff is available from the US Library of Congress (they have a special page on the history of dancing, the URL of which escapes me right now), so one could go back right to the original sources to make sure that the ABCs in question are `uncontaminated'. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] From a limp beginning, the erotic information processing market has been rising in recent years and is now quite firm, although the recession has created some soft spots. -- Tom Betz, in rec.humor.funny (1989) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Looking for ABC transcriber.
At 05:11 PM 11-14-2001 +0100, Bert Van Vreckem wrote: I found a site of a Michael Robinson that's into traditional music, but the Playford transcription isn't mentioned: http://www.sirius.com/~ststones/. There's other abc stuff there, though. Actually, he has, buried in his Standing Stones site, a page devoted to Playford (http://www.sirius.com/~ststones/playford.html. However, that site does not seem to claim authorship of the playford.abc file, instead, it provides two links -- one to a defunct site at Stanford University, and one to the ceolas.org archive. Ceolas.org, on the otherhand, claims that their Playford collection is courtesy Michael Robinson, and has an introduction file linked that contains the same text as on the Standing Stones' site. I will try to contact Michael Robinson and see what information I can get from him. Thanks all. -- bert van vreckem If Bill Gates had a nickel for every time Windows crashed... Oh wait! He does! To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something fairly complicated (Q: field)
I sense that we are all beginning to understand the virtues and weakneses of each proposal. I sense that any residual NIH is weakening. Good. I'm going to lurk and think for a bit! L. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something fairly complicated (Q: field)
Is there any mileage in something like Q:Allegro=120 % definition ... Q:3/8=Allegro % use, meaning that the beat is 3/8 in this case ? Laurie To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Simon Wascher [EMAIL PROTECTED] writes: For reasons of scientific quality I need to include as much as possible information of the original source within the file, as near to the original as possible. So the file should be a representation of the playback *and* the the display. The ABC file should be an approximate representation of the *musical content* of a piece. Anything else is likely hoping for too much -- as far as playback is concerned, an ABC file of Bach's Goldberg Variations would probably be closer to the sort of modern edition of the work that you can buy in a music shop than to either Bach's original manuscript (on the `display' side) or Glenn Gould's recorded interpretation of the piece (on the `playback' side). Both exploit dimensions of `presentation' that are simply not available in ABC notation, nor likely to be, and while the ABC edition of the piece would be nice to have around the house and let us have all kinds of fun with it, it would most probably never be the one or the other. As I said earlier on, if you want a near-facsimile replica of an original source, ABC is probably not the right vehicle for your work -- at least not without major tweaking of the standard and without restricting yourself to a particular output program (since the standard, fortunately, doesn't prescribe printed ABC output in enough detail for the various notation programs not to differ greatly from one another in just how they display things). Note that ABC in its current form doesn't even let you specify whether the stems of notes go up or down in a sequence like `ABc', so if you want to imitate a given score as closely as possible (we're talking `science', after all) using ABC, you have still quite a way to go before you're done. I don't know a lot about Lilypond but it might be worth checking out for your purposes. In any case if you're after a specific look to your sheet music you would do well to publish PDF as well as ABC, since even if you stick all your little presentation things into the ABC standard others will not be able to reproduce your output with anything approaching `scientific' precision unless they run exactly the same software that you do. Similarly, if you want to capture or express all the details of the performance of a piece of music then something like a MIDI file may really be the way to go, rather than ABC. All three formats -- ABC, PDF, MIDI -- fill different `ecological niches' that do overlap to some extent, but any one of the three could never fully replace either of the others. I'm not saying that you shouldn't try to make ABC do everything that you want. I'm just trying to caution you not to expect too much from ABC as it is, or ABC as it can be while still resembling what ABC is today enough to be recognizable. If music notation schemes were vehicles, then ABC originally started out as something like a bicycle -- very cheap and easy to use but still able to get us to all sorts of interesting places as long as they are not too far away from home. Now since its original invention the ABC bike seems to have acquired all sorts of useful accessories (like a lamp, 21 gears, panniers, and a radio), but that doesn't mean that we will ever be able to use it to pull a 25-ton trailer -- not without losing the ability of carrying it down the basement stair for the night, anyway, and that may be something that many of its users aren't ready to give up. Do not say this is *not* the target of abc, there is no such thing as a restriction against display matters anywhere in the standard. Its *your* ideology about abc. For me abc is a way to create compressed, easily exchangeable, freeware, playback active representations of a musical source. Guess what -- with me it's just the same. However I've been around the block often enough to have found out that it is a good idea to keep the actual information and the details of its presentation quite separate. It is not as if this was just some stupid `ideology' -- it is sound engineering practice, founded on a large body of experience in designing similar systems, which is available to anyone who deigns to enter a good computer science research library. (In fact, an hour or two on the Web reading up on the philosophy behind XML should give one a reasonably good idea of what the data/presentation dichotomy is all about, without one actually having to bother moving one's lazy self away from the computer.) You appear to have this learning experience still ahead of you. I wish you well; may your epiphany not be too painful when it comes. As it will, eventually. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] What we call 'Progress' is the exchange of one nuisance for another nuisance. -- Henry Havelock Ellis To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
