Re: [abcusers] something really simple

[Jack Campin]

>: Most of
>: the information fields are for use within a tune  header  but  in
>: addition  some  may be used in the tune body, or elsewhere in the
>: tune file.
> This is not a widely implemented feature of the abc standard and I
> would personally like it to become deprecated. My reasoning is that
> if you have global fields, you can't treat a single abc tune as
> something that can be edited out of its source file (which you might
> do if you wanted to print off just one tune from a collection).

You can't do a lot with a C function like

   void thing()
   {
 x++;
   }

unless you have a declaration for x in the environment, either.

You want to rewrite yaps in a language that uses those constraints?
(Only assembler does, as far as I know).

The point is that the non-local definability is USEFUL.  Trivial tweaks
that only affect the typeface header fields are displayed in is an utter
waste of time.  No ABC program is ever going to compete with a special-
purpose music typesetting engine and it's pointless trying.  But ABC
*already* has richer semantics in some directions than they do, and much
greater flexibility of application.  Those are directions in which further
extension will give it unique advantages among all other forms of musical
representation.

These non-local features are not exactly cutting-edge stuff to implement,
given that programming languages have had declarations since 1956 or
thereabouts and block scoping since 1960.  And it was in the very first
computer implementation of ABC.

I don't *want* my tunes edited out of the context I presented them in.
Ever.  Any proposal that helps prevent it is an advantage in my book.

Conversely, anyone who *does* want their tunes edited out of their
original file context can just avoid using non-local constructs.  You
couldn't very well use them accidentally.

So the only people being hampered by this are people who want to use
music in a way that the original transcriber didn't want them to.  Is
that a category of people we want to cripple the notation for?


] I'm on a number of mailing lists that use abc a lot, and I have some
] little programs to extract tunes from email messages and do something
] with them.  The problem is that messages often have a bit of discussion
] of the tunes, including history and variants and other similar tunes.
] It isn't at all unusual for the text before the tunes to have fragments
] of abc, sometimes just a few header lines, and these fragments often
] have little or nothing to do with the later tunes in the message.  So
] if the fragments are added into later tunes, the result is often not
] at all what was intended.

Perhaps having their messages automatically harvested by bots might not
have been what the authors intended either.  You can't assume it unless
that was stated up-front as the policy of the list when they joined.

What was the problem with contacting the transcriber and asking them?
Maybe they might have wanted that history included (e.g. as comment
lines or embedded in H: fields).  It's not like we're short of ways to
quote stuff.  If somebody puts an ABC tune in an email message, a simple
default is just to put % signs at the start if every line that isn't the
tune.


===  ===


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[John Chambers]

James Allwright writes:
| > They're in the 1.6 standard for other header fields:
| >
| > : Most of
| > : the information fields are for use within a tune  header  but  in
| > : addition  some  may be used in the tune body, or elsewhere in the
| > : tune file. Those which are allowed elsewhere can be used  to  set
| > : up  a  default  for  the whole or part of a file. ...
|
| This is not a widely implemented feature of the abc standard and I
| would personally like it to become deprecated. My reasoning is that
| if you have global fields, you can't treat a single abc tune as
| something that can be edited out of its source file (which you might
| do if you wanted to print off just one tune from a collection).

Some time back,  I  ran  across  a  nasty  "gotcha"  with  this  that
encouraged me to "deimplement" such per-file header info for a number
of my own programs.  I'm on a number of mailing lists that use abc  a
lot,  and  I  have  some  little programs to extract tunes from email
messages and do something with them.  The problem  is  that  messages
often  have  a  bit of discussion of the tunes, including history and
variants and other similar tunes.  It isn't at all  unusual  for  the
text  before the tunes to have fragments of abc, sometimes just a few
header lines, and these fragments often have little or nothing to  do
with  the  later tunes in the message.  So if the fragments are added
into later tunes, the result is often not at all what was intended.

Writing software to understand English and do the right thing in such
cases is utterly hopeless.  I don't think I've ever seen a case where
abc header fragments in a message were a useful addition to later abc
tune(s), so I've just made my programs ignore such fragments.

If I ever have occasion to use these programs on actual abc files,  I
may  re-enable  processing  of  "global header lines".  But so far, I
haven't seen a need for this.

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laura Conrad]

> "James" == James Allwright <[EMAIL PROTECTED]> writes:

[about global header fields]

James> This is not a widely implemented feature of the abc standard and I
James> would personally like it to become deprecated. My reasoning is that
James> if you have global fields, you can't treat a single abc tune as
James> something that can be edited out of its source file (which you might
James> do if you wanted to print off just one tune from a collection).

Unless you use a utility to edit the file.  abcselect seems to
preserve global headers when you select a tune.

-- 
Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ )
(617) 661-8097  fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139
(If I haven't invited you to my party on December 16, I'm sure it's an oversight.)
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[James Allwright]

On Fri 23 Nov 2001 at 11:24PM +, Jack Campin wrote:
> 
> > The extra 'per file definition fields' seems like quite a major
> > extension to ABC to me, I don't think we have anything quite like
> > that at the moment, and I'm not convinced about the need to add it
> > for this.
> 
> They're in the 1.6 standard for other header fields:
> 
> : Most of
> : the information fields are for use within a tune  header  but  in
> : addition  some  may be used in the tune body, or elsewhere in the
> : tune file. Those which are allowed elsewhere can be used  to  set
> : up  a  default  for  the whole or part of a file. For example, in
> : exactly the same way that tunebooks are organised, a  file  might
> : start  with  M:6/8 and R:Jigs, followed by some jigs, followed by
> : M:4/4 and R:Reels, followed by  some  reels.  Tunes  within  each
> : section then inherit the M: and R: fields automatically, although
> : they can be overridden inside a tune header.
> 
> My proposal was modelled on that.

This is not a widely implemented feature of the abc standard and I
would personally like it to become deprecated. My reasoning is that
if you have global fields, you can't treat a single abc tune as
something that can be edited out of its source file (which you might
do if you wanted to print off just one tune from a collection).

James Allwright
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laurie Griffiths]

I have a metronome and it has no Italian words on it at all.
It is a traditional "upside-down pendulum" job in a nice triangular wooden
box.  I think the Italian words are just for the classical music sub-genre.
They're fine but they're just one way to do it.  I'm sure Russian words
would work just as well  (medleno etc - excuse the wrong font!).
Laurie

- Original Message -
From: James Allwright <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 23, 2001 10:14 AM
Subject: Re: [abcusers] something really simple


> On Thu 22 Nov 2001 at 04:52PM +, Jack Campin wrote:
> >
> > No it isn't.  A typical dance tune book will use "reel time" or "waltz
> > tempo" the same way all through.  In the Kurdish song book I quoted,
> > the same Italian tempo terms are used over and over again and are NEVER
> > defined at the beginning of a tune.  There wouldn't be any point in
> > tempo terms unless they had an understood meaning in a context wider
> > than an individual tune.  Today, everybody who has a metronome uses the
> > commonest 8 or so Italian terms in the same way to about 1% precision
> > because they're engraved on the scale, and I would guess the world
> > contains a few million more metronome users than ABC users.
>
> As someone who doesn't own a metronome, this is new information to me.
> If everyone who has a metronome posts these numbers, then maybe we
> will find that they all agree and we will have the basis for a useful
> standard. Likewise, perhaps you could post a list of military march
> tempos. Where pre-existing standards exist, then providing support
> for them in abc does seem like a good idea.
>
> James Allwright
> 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 really simple (is: playback of textual tempo indicators)

[Simon Wascher]

Hello,

James Allwright wrote:
> Conflicting  standards are an unfortunate thing, but I don't think they
> condemn us to forever fudging the issue and not adopting some standard.
> We already have abitrary default tempos fixed into all playback programs,
> so a new set of imperfect tempo settings doesn't really seem such a bad
> thing.

depends. If it is fixed part of a playback program it is a bad thing (as
I read is what happens in one program with the R:fields playback
information). If it is some default that can be changed by the user
within the playback program it is not. And definitely it should *not* be
part of the abc format standard, since for some musicans using textual
tempo indicators is to *avoid* metronome numbers to sugest that it
depends on the circumstances of a performance which tempo is the right
one.

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

[Simon Wascher]

Hello,

Bob Archer wrote:
(...)
> It's not uninterpreted text, it's text with a meaning. We already have
> the Q field which provides a computer readable indication of the
> speed usable by player programs. We now have this field to provide
> a textual description for display programs.
(...)
> A player program might default to looking at the Q field to get its
> tempo, or it could have the tempo specified on the command line,
> or it could have a separate "tempo definitions" file (similar to a
> stress file) and attempt to interpret the text in the q field (thus
> allowing for tempo descriptions such as "A little too fast")
> 
> A display program can choose to display the Q field, the q field,
> both or neither depending on what program specific options are set.
(...)

Just to say, yes I like this. I try to repat it in my own words to see
if I got it right:

The 
Q:field defines the playback tempo in ways of numeral definition,
unchanged.

a new 
q:field can be used to support `a textual description of the speed of
the tune'

both fields can be used in the header and the body of a tune. Which of
them is displayed and/or used for playback is decided depending on what
program specific options are set by the user. 

the `textual description of the speed of the tune' supported in the
q:field can be used 
by program specific options (whether they are predefined :-( or
definable :-) )  
or  together with a  `"tempo definitions" file (similar to a stress
file)'.  

*or* by other mechanisms of tempo definitions, in file headers or tune
headers which have not been agreed on so far.


Advantages of this proposal if I got it right, are:

* 100% backwards compatability in tune files,
* textual tempo indicators are allowed without the need to agree on if
and how they are interpreted by player programs, which I do belive is a
separate topic.


Simon

-- 
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

[Simon Wascher]

James Allwright wrote:
> On Thu 22 Nov 2001 at 04:52PM +, Jack Campin wrote:
> > No it isn't.  A typical dance tune book will use "reel time" or "waltz
> > tempo" the same way all through.  In the Kurdish song book I quoted,
> > the same Italian tempo terms are used over and over again and are NEVER
> > defined at the beginning of a tune.  There wouldn't be any point in
> > tempo terms unless they had an understood meaning in a context wider
> > than an individual tune.  Today, everybody who has a metronome uses the
> > commonest 8 or so Italian terms in the same way to about 1% precision
> > because they're engraved on the scale, and I would guess the world
> > contains a few million more metronome users than ABC users.
> 
> As someone who doesn't own a metronome, this is new information to me.
> If everyone who has a metronome posts these numbers, then maybe we
> will find that they all agree and we will have the basis for a useful
> standard. Likewise, perhaps you could post a list of military march
> tempos. Where pre-existing standards exist, then providing support
> for them in abc does seem like a good idea.

The problem is, that some classical musicans belive that these italian
tempo definitions are clear und unique. 
Practically there are a few more musicans than metronome users and even
within the core of classical music - Mozart, Haydn, Beethoven - there is
clear evidence that it is not at all clear what tempo (in absolute
metronome numbers - the only thing a computer playback program can make
use of) is really meant with those classical italian tempo indicators
(just listen to your classical music recordings!).
So, there is more than one pre-existing standard for each textual tempo
indicator, and therefore it would be counterproductive to fix them
unchangeable within a program and even worse to disastrous to fix them
within the standard.

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

[James Allwright]

On Thu 22 Nov 2001 at 04:52PM +, Jack Campin wrote:
> 
> No it isn't.  A typical dance tune book will use "reel time" or "waltz
> tempo" the same way all through.  In the Kurdish song book I quoted,
> the same Italian tempo terms are used over and over again and are NEVER
> defined at the beginning of a tune.  There wouldn't be any point in
> tempo terms unless they had an understood meaning in a context wider
> than an individual tune.  Today, everybody who has a metronome uses the
> commonest 8 or so Italian terms in the same way to about 1% precision
> because they're engraved on the scale, and I would guess the world
> contains a few million more metronome users than ABC users.

As someone who doesn't own a metronome, this is new information to me.
If everyone who has a metronome posts these numbers, then maybe we
will find that they all agree and we will have the basis for a useful
standard. Likewise, perhaps you could post a list of military march
tempos. Where pre-existing standards exist, then providing support
for them in abc does seem like a good idea.

James Allwright
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Simon Wascher]

Jack Campin wrote:
> The problem is how to use textual descriptions of numerical playback
> speeds in ABC.

So as I said it:
there are two parts in this proposal: 

1)displaying textual tempo definitions (the first five lines of Jacks
proposal)

I think its obvious that everybody finds this a good idea.

2)making these textual tempo definitions executeable for playback

as we have seen again and again there is no agreement at all on this
part of Jacks proposal (the rest of it).

So could we consider to spilt these two things appart and work out how
1) can become an acceptable common agreement (forewards and backwards
copatability in tunes and at least partly in programs ? )


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

[Bob Archer]

Jack Campin <[EMAIL PROTECTED]> wrote:

> >In an attempt to wrap up this thread, would the following proposal
> >for a new field meet everyone's requirements ?
> >
> >Field Name: q:playing style
> >Header: Yes
> >Tune Body: No
> >Description: Contains a written non-numerical description of the
> >  tune's tempo or "mood".
> >
> >Examples: 
> >
> >q:Allegro
> >q:Lento
> 
> That says exactly nothing about the semantics.

I think it does say something about the semantics. The text is part 
of the 'q' field which gives it the semantics 'a textual description of 
the speed of the tune'.

> Unless your "q:" field provides me with a way of DEFINING those
> strings in a musically intuitive way so that a numerical playback
> speed can be statically deduced from the musical text (e.g. by a
> playback program), there is no point in what you're suggesting.  There
> are already about 10 different ways to put uninterpreted text into a
> tune header, we *do not* need another one.

It's not uninterpreted text, it's text with a meaning. We already have 
the Q field which provides a computer readable indication of the 
speed usable by player programs. We now have this field to provide 
a textual description for display programs.

> And these *have* to go in tune bodies.  It is quite routine for tempo
> to change in the middle of a piece.

Agreed. I'd suggest that Q and q fields be allowed in the body of a 
tune.

> That suggestion ignores 95% of the issues we've discussed in this
> thread so it's nowhere near "wrapping it up".  The central problem is
> how to specify the required definition mechanism.

Actually, I think the advantage of the suggestion is that it ignores 
95% of the issues discussed. I think it cuts to the chase.

A player program might default to looking at the Q field to get its 
tempo, or it could have the tempo specified on the command line, 
or it could have a separate "tempo definitions" file (similar to a 
stress file) and attempt to interpret the text in the q field (thus 
allowing for tempo descriptions such as "A little too fast")

A display program can choose to display the Q field, the q field, 
both or neither depending on what program specific options are set.

With the caveat that q should be allowed in the tune body I like the 
suggestion. I think it hits the sweet spot between power and 
simplicity, and it avoids adding fields which should be placed 
before the beginning of the first tune in a file. The extra 'per file 
definition fields' seems like quite a major extension to ABC to me, I 
don't think we have anything quite like that at the moment, and I'm 
not convinced about the need to add it for this.

> In the case of pipe band marches, each band today has its own set of
> tempi.  There are ABC files out there with hundreds of marches.  It's
> up to the pipe-major to decide the speed, NOT the tune transcriber,
> and it's a waste of the P-M's time if they have to go through the
> whole file and treat every tune as a special case.

I would suspect that the P-M would have a tempo definition file on 
their computer containing their preferred definitions and would have 
set the playback program to use the q field rather than the Q field. 

Bob


--
-- Bob Archer  [EMAIL PROTECTED]
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Jack Campin]

>> Unless your "q:" field provides me with a way of DEFINING those strings
>> in a musically intuitive way so that a numerical playback speed can be
>> statically deduced from the musical text (e.g. by a playback program),
>> there is no point in what you're suggesting.  There are already about
>> 10 different ways to put uninterpreted text into a tune header, we *do
>> not* need another one.
> The problem I have with the "definition" idea is that definitions are
> only useful if you re-use the definition. If a term is defined at the
> beginning of a tune, used once and then lost there is no point in
> having it. This seems to be how written tempos are normally used.

No it isn't.  A typical dance tune book will use "reel time" or "waltz
tempo" the same way all through.  In the Kurdish song book I quoted,
the same Italian tempo terms are used over and over again and are NEVER
defined at the beginning of a tune.  There wouldn't be any point in
tempo terms unless they had an understood meaning in a context wider
than an individual tune.  Today, everybody who has a metronome uses the
commonest 8 or so Italian terms in the same way to about 1% precision
because they're engraved on the scale, and I would guess the world
contains a few million more metronome users than ABC users.

A typical case where definitions need both to be shared among multiple
tunes and also need to be easily redefinable: military marches.  In some
cases, British regiments have been using the same tunes to march to for
300 years.  And they have usually had their tempi labelled the same way
all that time: slow march, quickstep, retreat.  But the numerical values
of those tempi have risen steadily over the years, as soldiers have had
better roads to march on and needed to carry less of their own equipment
(the exact numbers are in period military manuals, and were insisted
on; disagree with the RSM about the speed of a march and you could look
forward to cleaning the parade ground with a toothbrush).  And these
terms have still faster definitions when the same tunes are used for
country dances.  So, if you've got a file of marches, and want to hear
them as they might have been played in the American War of Independence
or the Crimean War, it makes sense to just change the tempo definitions
*once* at the start of the file and have *all* the tunes interpreted
consistently.

In the case of pipe band marches, each band today has its own set of
tempi.  There are ABC files out there with hundreds of marches.  It's
up to the pipe-major to decide the speed, NOT the tune transcriber,
and it's a waste of the P-M's time if they have to go through the
whole file and treat every tune as a special case.


> It seems we haven't even agreed what the problem is.

The problem is how to use textual descriptions of numerical playback
speeds in ABC.


> I think it will be difficult to agree on a solution.

We've had quite a few variant proposals but they're mostly in the same
ballpark regarding what they can express, most of the differences are
merely syntactic.  So I don't think this is going to be all that hard.

===  ===


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[James Allwright]

On Thu 22 Nov 2001 at 12:22AM +, Jack Campin wrote:
> 
> That says exactly nothing about the semantics.
> 
> Unless your "q:" field provides me with a way of DEFINING those strings
> in a musically intuitive way so that a numerical playback speed can be
> statically deduced from the musical text (e.g. by a playback program),
> there is no point in what you're suggesting.  There are already about
> 10 different ways to put uninterpreted text into a tune header, we *do
> not* need another one.
> 

The problem I have with the "definition" idea is that definitions are
only useful if you re-use the definition. If a term is defined at the
beginning of a tune, used once and then lost there is no point in
having it. This seems to be how written tempos are normally used.

It seems we haven't even agreed what the problem is. I think it will
be difficult to agree on a solution.

James Allwright

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[James Allwright]

On Wed 21 Nov 2001 at 01:41PM -0500, Buddha Buck wrote:
> At 03:40 PM 11-21-2001 +, James Allwright you wrote:
> 
> >In an attempt to wrap up this thread, would the following proposal
> >for a new field meet everyone's requirements ?
> >
> >Field Name: q:playing style
> >Header: Yes
> >Tune Body: No
> 
> Would this make it impossible to transcribe music which is supposed to be 
> played "Placidly" in the main, except for a passage which is supposed to be 
> played "Excitedly"?

Use "_Excitedly" in the middle of the tune and then go back with
"_Placidly".

> 
> >Description: Contains a written non-numerical description of the
> >   tune's tempo or "mood".
> >
> >Examples:
> >
> >q:Allegro
> >q:Lento
> 
> Could the proposal be fleshed out more?  How does the new q: field interact 
> with the Q: field? 

It doesn't really, except that in the absence of a Q: field, a player
program might try to interpret the q: field to choose the tempo to
use.


> Any recommendations as to how playback or printout 
> programs should treat q: and Q: fields?
> 

A  playback program looks for a Q: field and ignores the q: field
most of the time (unless it is a top-of-the-range abc program
which knows how to how to read Italian).

A printout program would probably print whichever field
is present and both if you have both unless you have some 
special option to suppress one or the other.

James Allwright
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Jack Campin]

>In an attempt to wrap up this thread, would the following proposal
>for a new field meet everyone's requirements ?
>
>Field Name: q:playing style
>Header: Yes
>Tune Body: No
>Description: Contains a written non-numerical description of the
>  tune's tempo or "mood".
>
>Examples: 
>
>q:Allegro
>q:Lento

That says exactly nothing about the semantics.

Unless your "q:" field provides me with a way of DEFINING those strings
in a musically intuitive way so that a numerical playback speed can be
statically deduced from the musical text (e.g. by a playback program),
there is no point in what you're suggesting.  There are already about
10 different ways to put uninterpreted text into a tune header, we *do
not* need another one.

And these *have* to go in tune bodies.  It is quite routine for tempo
to change in the middle of a piece.

That suggestion ignores 95% of the issues we've discussed in this thread
so it's nowhere near "wrapping it up".  The central problem is how to
specify the required definition mechanism.

If nobody else jumps in first, I'll try to do a revised formulation of
my proposal (in the light of the subtleties I hadn't thought of) in a
week or two (too busy to launch into it immediately).

===  ===


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Buddha Buck]

At 03:40 PM 11-21-2001 +, James Allwright you wrote:

>In an attempt to wrap up this thread, would the following proposal
>for a new field meet everyone's requirements ?
>
>Field Name: q:playing style
>Header: Yes
>Tune Body: No

Would this make it impossible to transcribe music which is supposed to be 
played "Placidly" in the main, except for a passage which is supposed to be 
played "Excitedly"?

>Description: Contains a written non-numerical description of the
>   tune's tempo or "mood".
>
>Examples:
>
>q:Allegro
>q:Lento

Could the proposal be fleshed out more?  How does the new q: field interact 
with the Q: field?  Any recommendations as to how playback or printout 
programs should treat q: and Q: fields?

>James Allwright
>
>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 really simple

[James Allwright]

In an attempt to wrap up this thread, would the following proposal
for a new field meet everyone's requirements ?

Field Name: q:playing style
Header: Yes
Tune Body: No
Description: Contains a written non-numerical description of the
  tune's tempo or "mood".

Examples: 

q:Allegro
q:Lento

James Allwright

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Anselm Lingnau]

John Walsh <[EMAIL PROTECTED]> writes:

>   Some programs (abcmus for sure, and judging by other comments in
> this thread, Barfly, probably others too) use the R: and M: fields to
> determine the tempo (and, more, a stress program) which can be modified by
> the user as desired. It's a great feature. I think of the translation of
> "allegro" into beats per minute as an extension of this.

I must say I quite like the idea of `stress programs' as exemplified by
BarFly. They are a nice illustration of my claim that ABC notation and
presentation details are best kept separate.

Anselm
-- 
Anselm Lingnau .. [EMAIL PROTECTED]
Convictions are more dangerous enemies of truth than lies.
 -- Friedrich Wilhelm Nietzsche


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[John Walsh]

Anselm Lignau writes:

>Yes, but the whole point of Jack's original proposal was for people to
>be able to define the meanings of these terms themselves, in a manner
>appropriate to the music they were working with. The suggestion to
>hard-code a selection of `tempo terms' (a bad one, IMHO) came from
>elsewhere, quite a bit later.
>

I interpreted those as suggestions for possible default values which
could be easily overridden by the user.

Some programs (abcmus for sure, and judging by other comments in
this thread, Barfly, probably others too) use the R: and M: fields to
determine the tempo (and, more, a stress program) which can be modified by
the user as desired. It's a great feature. I think of the translation of
"allegro" into beats per minute as an extension of this.

Cheers,
John Walsh


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Ewan A. Macpherson]

Frank Nordberg wrote:

> My favorite tempo indication is "A little too fast" ;-)

Which beats mine, which is: "So rasch wie möglich"
 
e.
--
Ewan Macpherson <[EMAIL PROTECTED]>
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Frank Nordberg]

Buddha Buck wrote:
> 
> I have a songbook at home in which the composer chose a different English
> tempo description for every song -- about 60 all told.

My favorite tempo indication is "A little too fast" ;-)

Frank Nordberg
http://www.musicaviva.com
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Anselm Lingnau]

Simon Wascher <[EMAIL PROTECTED]> writes:

> there are french baroque tempo definitions, german expressionist tempo
> definitions , tempo definitions in all languages of the world which *do*
> have their regional value. 
> It would really be extremly rigid to stuck with those oldfashioned
> classical music's set of italian  tempo descriptors which have in no way
> a consistent well defined generally accepted meaning as every
> musicologist can demonstrate.

Yes, but the whole point of Jack's original proposal was for people to
be able to define the meanings of these terms themselves, in a manner
appropriate to the music they were working with. The suggestion to
hard-code a selection of `tempo terms' (a bad one, IMHO) came from
elsewhere, quite a bit later.

Anselm
-- 
Anselm Lingnau .. [EMAIL PROTECTED]
Bicycles have their proper place, and that place is under small boys delivering
evening papers.
 -- P. J. O'Rourke, *A Cool and Logical Analysis of the Bicycle Menace*

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laurie Griffiths]

> ...(at what speed is "Ecumenically"?  or
> "Elementally"). ...

Ecumenically would have to be a speed that made everyone happy or at least
that no schism of the church objected to greatly.:-)

Not sure about the other one.

Laurie



To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Buddha Buck]

At 02:43 PM 11-19-2001 +, James Allwright you wrote:
>On Mon 19 Nov 2001 at 01:34PM -, Laurie Griffiths wrote:
> >
> > Some people (I think it was Frank that started it) say (and I'm putting
> > words into their mouths) "Look, the Q: syntax is all very well for
> > controlling the speed of a player program, but what I want to be able to do
> > is to say 'play this at an Allegro speed' (or 'Lento' or some other word
> > whose meaning I know.  And what 'Allegro' means is about 120 per minute.  I
> > don't mind writing down what Allegro means once, but I shouldn't have to
> > write it every time.  I mean Allegro is Allegro".
> >
>
>I think we need to know whether "Allegro" is one of a small set of
>well-defined tempo descriptors (in which case it would be really nice
>to have the complete set together with their definitions) or one
>tempo definition in a large and vague set that spans the complete
>Italian language and is interpreted at the performer's discretion.

The latter, and then some.

I have a songbook at home in which the composer chose a different English 
tempo description for every song -- about 60 all told.  The composer is a 
humorist, and the tempo markings relate more to the subject matter of the 
song than the speed to be played (at what speed is "Ecumenically"?  or 
"Elementally").  However, if I were to transcribe his work into ABC, I 
would wish to preserve his tempo markings, even if I did have to indicate 
what speed "Painfully" was in terms of beats per minute.

Also, when transcribing Arbeau's dances, I'd prefer to keep his tempo 
indications (roughly, slow, medium, and fast, but written in 16th century 
French, and not always mentioned directly), which would not be Italian terms.

It may be reasonable to have a set of pre-defined Italian tempo terms 
available, but the user may have need for more, especially if working with 
modern, non-western, or pre-classical music.

>James Allwright
>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 really simple

[Frank Nordberg]

James Allwright wrote:
> 
> I'm willing to bow to Frank's superior knowledge here.

Thanks :-)

>
> The conclusion is
> that tempo indicators are essentially random text and it is not worth
> our while attempting to codify them so they can be translated into
> numerical meanings.

In other words - we should get rid of the Q: field altogether ;-)

But seriously:
The reason why there are no easily definable always-correct tempo
indications in music, is that it's impossible to create such a thing.
The tempo of a performance depends on so many different factors that
simply can't be quantified. So what composers throughout the centuries
have done, is to add a short description of the "feeling" of the piece,
hoping that the musicians are intelligent enough to interpret it in a
sensible way.

Laurie Griffiths wrote:
> 
> I personally imagined that we could have whatever terms the author thought
> good.

I agree.

In a way the present definition of the Q: field represents a perversion
of everything music is about. Notated music (standard notation or abc or
whatever) exists mainly to aid the performing musician, but the Q: field
as it is today seems to assume that the music is to be played by a computer.

My idea is to have ABC present the tempo in a way that is as useful as
possible to the live musician, and *then* add some kind of mechanisms
for helping the computer interpret it as well as it can.

Frank Nordberg
http://www.musicaviva.com



To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[James Allwright]

On Mon 19 Nov 2001 at 04:26PM +0100, Frank Nordberg wrote:
> 
> 
> James Allwright wrote:
> > 
> > I think we need to know whether "Allegro" is one of a small set of
> > well-defined tempo descriptors (in which case it would be really nice
> > to have the complete set together with their definitions) or one
> > tempo definition in a large and vague set that spans the complete
> > Italian language and is interpreted at the performer's discretion.
> 
> There is no small set of well-defined tempo descriptors. Nor are the
> tempo indicators necessarily in Italian. Basically, the composer can use
> any words in any language he wants.
> 

I'm willing to bow to Frank's superior knowledge here. The conclusion is
that tempo indicators are essentially random text and it is not worth
our while attempting to codify them so they can be translated into
numerical meanings.

James Allwright
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laurie Griffiths]

I personally imagined that we could have whatever terms the author thought
good.  For myself I play a lot of dance music and "waltz", "step-hop",
"skipping", "rant", "walking" and "running" covers most of it.  I would
never dream of putting "Allegretto" on a sheet of the stuff I play but I
have often been frustrated in encountering a new piece of written music by
the complete absence of any tempo indication.  So just because non scrivo
mai in italiano (*) it doesn't mean I don't want to write a tempo.

Laurie
(*) I never write in Italian.
- Original Message -
From: James Allwright <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 19, 2001 2:43 PM
Subject: Re: [abcusers] something really simple


> On Mon 19 Nov 2001 at 01:34PM -, Laurie Griffiths wrote:
> >
> > Some people (I think it was Frank that started it) say (and I'm putting
> > words into their mouths) "Look, the Q: syntax is all very well for
> > controlling the speed of a player program, but what I want to be able to
do
> > is to say 'play this at an Allegro speed' (or 'Lento' or some other word
> > whose meaning I know.  And what 'Allegro' means is about 120 per minute.
I
> > don't mind writing down what Allegro means once, but I shouldn't have to
> > write it every time.  I mean Allegro is Allegro".
> >
>
> I think we need to know whether "Allegro" is one of a small set of
> well-defined tempo descriptors (in which case it would be really nice
> to have the complete set together with their definitions) or one
> tempo definition in a large and vague set that spans the complete
> Italian language and is interpreted at the performer's discretion.
>
> James Allwright
> 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 really simple

[Frank Nordberg]

Laurie Griffiths wrote:
> 
> James, we're at cross purposes here.  In fact I think you are at
> cross-purposes with everyone else.
> 
> We know that the existing Q: field works and it's well defined BUT
> Some people (I think it was Frank that started it)

It was Jack, actually.


James Allwright wrote:
> 
> I think we need to know whether "Allegro" is one of a small set of
> well-defined tempo descriptors (in which case it would be really nice
> to have the complete set together with their definitions) or one
> tempo definition in a large and vague set that spans the complete
> Italian language and is interpreted at the performer's discretion.

There is no small set of well-defined tempo descriptors. Nor are the
tempo indicators necessarily in Italian. Basically, the composer can use
any words in any language he wants.


Frank Nordberg
http://www.musicaviva.com

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Jack Campin]

> I belive it is not really neccessary to define the beat of allegro in
> Balkan music (like 3+3+2), I've never heard of such a definition in any
> other music notation context. And for sure it would be an abuse of the
> classical music's tempo word "Allegro".

I just fished out my copy of Maud Karpeles' "Folk Songs of Europe" (1956).
She has:

- a Latvian song in 3/4:4/4, Moderato patetico
- a Czech song in 2/4:3/4, Andante
- a Hungarian song with no time signature, Parlando
- a Romanian song, ditto, Vivo
- a Macedonian song in 7/16, Allegro giocoso
- a Dutch song mixing 9/8, 6/8 and 3/8, Allegro
- an English song in 5/4, Allegretto e semplice

etc.

Italian tempo names are used all the time by ethnomusicologists.

Or if you want one from an entirely non-Western context, here's one
from a collection of Kurdish folk songs.  The songs are given in the
original Kurdish, the commentary is in Turkish, and the tempo markings
are entirely in Italian.  No metronome marks at all and no explanation
of the markings; the reader is expected to know, and if they'd gone
through the standard Turkish high school music syllabus, they would.

X:1
T:Hey lo, Seni
B:Mehmet Bayrak: Kurt Halk Turkuleri, Ozge Yayinlari, 1991
Z:Jack Campin 2001
M:8/8
L:1/8
Q:Moderato
N:Bar 6 is (3B,/F/E/- E E/ D D< C- C (3D/(D/C/)| in the
N:book, which doesn't add up so I'm assuming it's a typo
K:B Minor
  AF2  A/F/ A  F2A/F/  |
  AF2  A/F/ F  E> (D E/)F/ |
  FE2  E/D/ D  C2D/E/  |
  F<   DD< CC< B,- B,  (3C/(D/C/)  |
  E/D/ D/C/ C< B,-  B, B,  B,2 |
(3B,/F/E/- EE< DD< C-  C   (3D/(D/C/)  |
  F<   DD< CC< B,- B,  (3C/(D/C/)  |
  E<   DD< CC< B,- B,- (3B,/B,/B,/|]




> And if ever it will be possible to use 3+3+2/8 in an abc M: field,
> we can find a way to define allegro under such a M: field.

I don't understand this at all.  Why would you want to roll tempo
definitions into a field already designed for something entirely
different?  Are you suggesting this would make it *easier*?  How?

===  ===


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Simon Wascher]

Hello,

[EMAIL PROTECTED] wrote:
> On Mon, 19 Nov 2001, Simon Wascher wrote:
> 
> > why if the beat changes with the meter, the meter (M:)  isnt the field
> > which defines by its content (I do *not* mean to add an extention to
> > it) what Allegro (~120 beats per minute) means.
> 
> However, if the note value of the beat is compound (dotted), there is no
> whole number that can represent it accurately, so a smaller note value has
> to be used.  For instance, if the composer intended two beats per measure,
> with a dotted-quarter beat, the only accurate way to write it would be
> something like 2/2.666...  For obvious reasons, we write 6/8 instead.
> 
> The problem is that by doing this, traditional notation breaks its own
> rules.  6/8 time seems to imply that there are actually six beats per
> measure, and that the eighth note defines the beat. 

to me as an traditional musican, this is not a broken rule its simply an
special rule to dotted rhythms:
3/8 equals one beat. so if I want to write three beats in dotted rhythms
I use 6/4 time. One problem is with 5/8 which has two beats (3+2 or 2+3
; I do not know how to fit this into a classical "allegro" recipe)
wheras 5/4 has five beats :-) .


 And to complicate the
> matter further, sometimes this *is* what the composer intended.

composers ask for everything and the opposite, composing is mainly a
game about establishing rules to break them.

 
> The question at this point seems to be whether we want the standard to get
> it right all of the time (define Allegro as 120, define the beat for each
> piece); get it wrong only sometimes (define Allegro as 120, guess at the
> beat); or get it wrong a great deal of the time (define Allegro as
> 1/4=120, even in 6/8, damn the beat).

I think in most cases defing allegro to the beat given in the M: field
under the presumtion that 3/8 = one beat will be sufficient in 95% of
all cases. In other cases the transcriber has to redefine the beat.


> > I belive it is not really neccessary to define the beat of allegro in
> > Balkan music (like 3+3+2), I've never heard of such a definition in
> > any other music notation context.
> 
> This kind of thing happens quite often in newer compositions, usually
> implied by the note beaming, but sometimes written out explicitly in the
> meter (e.g., 3+2 over 8 instead of 5 over 8).  Some notation software
> allows this... I believe Finale is one of them.

Yes, yes of course, I use this stuff too. What I wanted to say is "I've
never heard of a definition for *"allegro"* in 3+3+2 rhytms in any other
music notation context (a definition for a correct tempo for *allegro*
in 3+3+2 time ). No question compound rhythms  *do* exist (and Finale
supports them). It seems I did not write too clear.

Simon

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

[jhoerr]

On Mon, 19 Nov 2001, Simon Wascher wrote:

> why if the beat changes with the meter, the meter (M:)  isnt the field
> which defines by its content (I do *not* mean to add an extention to
> it) what Allegro (~120 beats per minute) means.

This has already been discussed.  It is possible to take a reasonable
guess as to what beat is intended for a given meter.  However, due to a
shortcoming in traditional notation, that guess will not always be
correct.  Whether or not it's correct "often enough" is still something
that might be worth discussing.

In the traditional way of notating meter, the top number defines the
number of beats in the measure, and the bottom number gives the value of
the note that defines the beat (e.g., 4/4 means four beats per measure,
and the quarter note defines the beat; 3/2 means three beats per measure,
with half-note beats).

However, if the note value of the beat is compound (dotted), there is no
whole number that can represent it accurately, so a smaller note value has
to be used.  For instance, if the composer intended two beats per measure,
with a dotted-quarter beat, the only accurate way to write it would be
something like 2/2.666...  For obvious reasons, we write 6/8 instead.

The problem is that by doing this, traditional notation breaks its own
rules.  6/8 time seems to imply that there are actually six beats per
measure, and that the eighth note defines the beat.  And to complicate the
matter further, sometimes this *is* what the composer intended.

Metronome markings are one way to resolve this ambiguity in traditional
notation -- the very fact that they are written as {note value}={beats per
minute} instead of just {beats per minute} illustrates this.  In the
absence of a metronome marking, though, we sometimes have to guess at the
beat.  It's not usually too hard for a human to do this, but it's quite
another thing to systematize it.  So, as far as abc is concerned, either
we allow human transcribers to use their own natural intelligence to
define the beat, or we accept that whatever artificial intelligence the
standard provides (if any) for determining the beat will be wrong
sometimes.

The question at this point seems to be whether we want the standard to get
it right all of the time (define Allegro as 120, define the beat for each
piece); get it wrong only sometimes (define Allegro as 120, guess at the
beat); or get it wrong a great deal of the time (define Allegro as
1/4=120, even in 6/8, damn the beat).

And of course, there is still the option of not allowing Allegro to be
defined in abc as anything at all, leaving it to the developers to make
sense of Q:Allegro for playback.

> I belive it is not really neccessary to define the beat of allegro in
> Balkan music (like 3+3+2), I've never heard of such a definition in
> any other music notation context.

This kind of thing happens quite often in newer compositions, usually
implied by the note beaming, but sometimes written out explicitly in the
meter (e.g., 3+2 over 8 instead of 5 over 8).  Some notation software
allows this... I believe Finale is one of them.

John

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Simon Wascher]

James Allwright wrote:
> > I think we need to know whether "Allegro" is one of a small set of
> well-defined tempo descriptors (in which case it would be really nice
> to have the complete set together with their definitions) or one
> tempo definition in a large and vague set that spans the complete
> Italian language 

there are french baroque tempo definitions, german expressionist tempo
definitions , tempo definitions in all languages of the world which *do*
have their regional value. 
It would really be extremly rigid to stuck with those oldfashioned
classical music's set of italian  tempo descriptors which have in no way
a consistent well defined generally accepted meaning as every
musicologist can demonstrate.

Simon
-- 
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

[James Allwright]

On Mon 19 Nov 2001 at 01:34PM -, Laurie Griffiths wrote:
> 
> Some people (I think it was Frank that started it) say (and I'm putting
> words into their mouths) "Look, the Q: syntax is all very well for
> controlling the speed of a player program, but what I want to be able to do
> is to say 'play this at an Allegro speed' (or 'Lento' or some other word
> whose meaning I know.  And what 'Allegro' means is about 120 per minute.  I
> don't mind writing down what Allegro means once, but I shouldn't have to
> write it every time.  I mean Allegro is Allegro".
> 

I think we need to know whether "Allegro" is one of a small set of
well-defined tempo descriptors (in which case it would be really nice
to have the complete set together with their definitions) or one
tempo definition in a large and vague set that spans the complete 
Italian language and is interpreted at the performer's discretion.

James Allwright
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Simon Wascher]

Hello,

Laurie Griffiths wrote:
> So we find we've begged some questions.  OK, so Allegro is 120 per minute,
> but 120 of WHAT per minute??  It then became clear that if you are playing
> in 6/8 it would mean 120 3/8 notes but if you were playing in 2/4 it would
> mean 120 1/4 notes and if you were playing in 4/4 it would p-r-o-b-a-b-l-y
> mean 120 1/2 notes and then there's the Balkan and Turkish stuff

i did not participate in this "beat" topic since I do not use any of
these classical tempo words in my music (but sometimes others). 
But, maybe I make an idiot of me by askin such, why if the beat changes
with the meter, the meter (M:)  isnt the field which defines by its
content (I do *not* mean to add an extention to it) what Allegro (~120
beats per minute) means. what Laurie describes above is a clear
connection between M:6/8 or M:4/4 or M:2/4 , M:C, M:C| and the "beat" of
Q:Allegro.
I belive it is not really neccessary to define the beat of allegro in
Balkan music (like 3+3+2), I've never heard of such a definition in any
other music notation context. And for sure it would be an abuse of the
classical music's tempo word "Allegro". And if ever it will be possible
to use 3+3+2/8 in an abc M: field, we can find a way to define allegro
under such a M: field.

Simon


-- 
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

[Laurie Griffiths]

James, we're at cross purposes here.  In fact I think you are at
cross-purposes with everyone else.

We know that the existing Q: field works and it's well defined BUT
Some people (I think it was Frank that started it) say (and I'm putting
words into their mouths) "Look, the Q: syntax is all very well for
controlling the speed of a player program, but what I want to be able to do
is to say 'play this at an Allegro speed' (or 'Lento' or some other word
whose meaning I know.  And what 'Allegro' means is about 120 per minute.  I
don't mind writing down what Allegro means once, but I shouldn't have to
write it every time.  I mean Allegro is Allegro".

So he wanted to write

Q:Allegro

Well if Allegro is 120 then maybe this should sort of ought to mean in some
ideal world
Q:120
but that is already well defined and it doesn't mean what we want at all!!
(whether or not L: changes in the tune it still isn't what we want)..

So we find we've begged some questions.  OK, so Allegro is 120 per minute,
but 120 of WHAT per minute??  It then became clear that if you are playing
in 6/8 it would mean 120 3/8 notes but if you were playing in 2/4 it would
mean 120 1/4 notes and if you were playing in 4/4 it would p-r-o-b-a-b-l-y
mean 120 1/2 notes and then there's the Balkan and Turkish stuff

So now we had the notion that we need to define a "beat" and it's not the
same as the L: value. So we played with

Define "Allegro=120"  (using some syntax or other, but probably NOT that
one!)

X:100
T:Foo
L:1/8
Define Beat=1/4 (using some syntax or other, but probably NOT that one!)
K:G
Q:Allegro

or else maybe

Define "Allegro=120"  (using some syntax or other, but probably NOT that
one!)

X:100
T:Foo
L:1/8
K:G
Q:1/4=Allegro

where the fraction in the Q: seems to be defining what we were calling the
"Beat".
or else maybe any of several options that were floating around on this
thread.

And then there's the question of what's a sensible thing to display or print
?
Probably something like "Allegro" or possibly ".| = Allegro" or possibly
".|=120 (Allegro)" or possibly it's up to the particular display/print
program or a user-settable option or...

I hope this recap has helped.

We still have the "really simple" matter of nailing it down and making a
decision!

Laurie
- Original Message -
From: James Allwright <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 19, 2001 9:09 AM
Subject: Re: [abcusers] something really simple


> On Fri 16 Nov 2001 at 04:20PM -0800, John Walsh wrote:
> > I haven't been following closely enough to be sure, but I have the
> > impression that the idea of basing the tempo on the L: field has been
> > pretty well discarded, except possibly as a legacy from abc 1.6 in the
> > (deprecated) Q:120 syntax.  True?  I hope so, since it's an unstable
> > indicator: there can be times when the user makes an in-line change of
the
> > L: field to accomodate, say, a couple of bars chock-full of 1/32
> > notes---makes it easier to write, and to read too, for that matter---
and
> > it's a bit disconcerting to hear the playback speed up by a factor of
four
> > for for just those bars.
> >
>
> This was resolved ages ago. Q:120 takes the value of unit note length
> from the header. If there is a new L: field in the body of the tune,
> the tempo does not change with it because (as you point out) this would
> result in nonsense.
>
> James Allwright
> 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 really simple

[James Allwright]

On Fri 16 Nov 2001 at 04:20PM -0800, John Walsh wrote:
>   I haven't been following closely enough to be sure, but I have the
> impression that the idea of basing the tempo on the L: field has been
> pretty well discarded, except possibly as a legacy from abc 1.6 in the
> (deprecated) Q:120 syntax.  True?  I hope so, since it's an unstable
> indicator: there can be times when the user makes an in-line change of the
> L: field to accomodate, say, a couple of bars chock-full of 1/32
> notes---makes it easier to write, and to read too, for that matter--- and
> it's a bit disconcerting to hear the playback speed up by a factor of four
> for for just those bars.
> 

This was resolved ages ago. Q:120 takes the value of unit note length
from the header. If there is a new L: field in the body of the tune,
the tempo does not change with it because (as you point out) this would
result in nonsense.

James Allwright
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Frank Nordberg]

I haven't had time to follow this discussion closely recently. But I
have the impression this might be of interest at the present stage:

*
Reinlender
C
1/4=160
8
120 1.4
80 0.6
105 1.4
80 0.6
110 1.4
80 0.6
105 1.4
80 0.6

---

For those of you who doesn't know BarFly, this is a BarFly stress
program, and it already does something similar to the tempo macros Jack
was asking for.

A short explanation:

* - just a delimiter to mark the beginning of the program.

Reinlender - BarFly will look for matches to this in the R: field

C - BarFly will look for matches to this in the M: field

1/4=160 - if both the paramteres above match and there's no Q: field in the
  tune, BarFly will play back at this tempo

The rest of the stress program doesn't have anything to do with tempo,
so I'll leave it out for now.



Frank Nordberg
http://www.musicaviva.com

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[John Walsh]

I haven't been following closely enough to be sure, but I have the
impression that the idea of basing the tempo on the L: field has been
pretty well discarded, except possibly as a legacy from abc 1.6 in the
(deprecated) Q:120 syntax.  True?  I hope so, since it's an unstable
indicator: there can be times when the user makes an in-line change of the
L: field to accomodate, say, a couple of bars chock-full of 1/32
notes---makes it easier to write, and to read too, for that matter--- and
it's a bit disconcerting to hear the playback speed up by a factor of four
for for just those bars.

I will watch the discussion of "beats" with interest. 
The question may be a trifle delicate. For instance,
there's already a problem in the common reel---common in some places, at
least.  Although it has a pretty strong beat, there is a question "How
many?"  I think the prevailing opinion is that reels are "properly" 4/4,
but in most playing styles beats 2 and 4 are enough weaker than 1 and 3
that it may be a moot point. And indeed, they are written in either common
time, cut time--the practice is fairly evenly split--or (mostly in older
MS) in 2/4.  This makes no difference in the playing--they go by fast
enough that you can only tap your toe twice a measure anyway, so if you
tell a fiddler you play a certain reel at 120 bpm, it's understood you
mean 120 toe-taps per minute, and who cares about the time signature? But
I have noticed that there can be a misunderstanding with people coming
from other genres who see reels written in 4/4 and are likely to object
that you should say 240 bpm, not 120, counting each quarter note as one
beat.  (This may be the origin of the abcwin interpretation of the Q:
field.)  Classical musicians are *so* hard to convince that tempi should
be measured in toe-taps per minute.

Cheers,
John Walsh



To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laurie Griffiths]

James,  it looks as though you missed the beginning of this sub-thread:

The problem was if we define words to mean particular rates e.g. lento=60,
Allegro=120, vigorous skipping=95 etc, it begs the questions "60 what?",
"120 what?" etc.
120 L units seems to often give silly answers, so we are searching for a
better answer.  The answer seemed to be "120 beats" where a "beat" might be
a dance step for a dance or something a little less tangible, (but still
quite clear to a musician) in other cases.

So we were inventing yet more syntax to define a "beat" and were thinking if
there was a sensible default if it were not explicitly defined.
The thread below then picks up saying the L: value is not clever as this
default.
L.
- Original Message -
From: James Allwright <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 15, 2001 2:14 PM
Subject: Re: [abcusers] something really simple


> On Wed 14 Nov 2001 at 11:24AM -0500, [EMAIL PROTECTED] wrote:
> > 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)?
>
> Yes. See the 1.6 standard. Q:100 means 100 unit note lengths per
> minute.
>
> >
> > 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.
> >
>
> Then presumably you are not using the Q: field as defined.
>
> James Allwright
>
> 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 really simple

[Laura Conrad]

> "James" == James Allwright <[EMAIL PROTECTED]> writes:


>> 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.
>> 

James> Then presumably you are not using the Q: field as defined.

But we aren't discussing the current definition of the Q: field.  

What we're talking about is adding a new keyword, which should have a
default value for tunes where it isn't entered.  This doesn't
necessarily have anything to do with the default values of the current
fields.

The way I use the L: field is to simplify data entry; the way I use
the Q: field would be pretty unreadable to people who are used to
published metronome markings if it was always in terms of the L:
field.  That is, in music where the beat is divided into 2, 4, 8, or
more parts, I might very likely want to enter music with an L: of a
much shorter value than I would want to specify the beat.  I might
also change the L: field when I had no reason to change what the beat
was.  


-- 
Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ )
(617) 661-8097  fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[James Allwright]

On Wed 14 Nov 2001 at 11:24AM -0500, [EMAIL PROTECTED] wrote:
> 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)?

Yes. See the 1.6 standard. Q:100 means 100 unit note lengths per 
minute.

> 
> 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.
> 

Then presumably you are not using the Q: field as defined.

James Allwright

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Anselm Lingnau]

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

Re: [abcusers] something really simple

[Simon Wascher]

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] something really simple

[Anselm Lingnau]

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 .

Re: [abcusers] something really simple

[jhoerr]

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] something really simple

[Simon Wascher]

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 aga

Re: [abcusers] something really simple

[Anselm Lingnau]

Laurie Griffiths <[EMAIL PROTECTED]> writes:

> 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.

True. It turns out that most ABC header fields are of the

  x:yz

variety (I'm putting `x' here simply because it has no well-known
meaning that might be confusing), where `yz' is a magic word like `ADor'
or `1/4=120'. There is a bunch of headers like `T:' and `C:' where `yz'
is something free-form like a title or composer's name that extends up
to the end of the line or up to the spaces and '%' in front of an
in-line comment, and of course there is `N:'.

It is difficult to say things about all ABC-processing programs in
existence but chances are that when a program is looking at, e.g., a
`K:' line it will check that the first non-space characters after the
colon form one of the approved sequences for that field, and not pay too
much attention to the rest of the line. Thus the rest of the line can be
used to add stuff in a way that is likely to not be too disturbing. This
is the basic idea of the whole backwards-compatibility business -- of
course if we were to be completely backwards-compatible we would have to
either leave the line formats alone or hide all new extensions in
end-of-line comments, an idea that I personally find more than a bit
distasteful.

Having said that, the question remains of how to structure those bits
that come after the `leading' item on such an ABC header line. The most
straightforward idea -- and the one Simon promulgates in his tempo
proposal -- is to assign meaning to the following bits according to
their position in the line, with some separator (like a space) between
individual bits of information. If there is only one extra bit of
information after the `leading' item this is indeed a very enticing
idea, but the problem is that it doesn't scale well -- once three or
four additional items of information may or may not occur (according to
the situation) we get stuff like

  x:yz a bc - fgh

and users must be able to remember (or look up) which item means what.
It may also force users to specify things that they would rather not,
just so the appropriate slot is taken up and something important that
occurs farther right on that line ends up in the correct place. Besides,
we run into problems if the separator character can occur within a field
value -- this is a critical issue with Simon's tempo proposal, where

  x:yz a bc de fgh
^^ ^ ^ third field
 | +-- second field
 + first field

appears to be allowed. If a fourth field were to be added to this
specification we would have to come up with yet another (non-space)
separator to signal the end of the third field and the beginning of the
fourth. I wouldn't dare claim that this type of notation is still
`user-friendly and natural'.

The nice thing about the `key=value' approach is that the additional
bits can occur in any order and that unneeded items can easily be left
out altogether. In my examples so far I have included quotes around the
values but in fact this would only be strictly necessary if the values
were to include blanks (supposing that blanks, or, more generally,
`linear whitespace' will be used to separate individual `key=value'
items). Having to write `key=' in addition to the actual value may look
tedious at first but I think it is a small price to pay if we gain the
chance to introduce new keys as the need arises, without having to come
up with a way of rearranging the implicit-meaning fields on a line like
`x:yz a bc - fgh'.

> 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.

This is true but the important distinction is that `Q:1/4=120' is a
bona-fide property of the piece of music being described -- this is
being emphasized by the observation that it means something completely
different to a notation program than to a playback program -- while
`This will be printed like so in that place' is a property of the
software system used to process the piece of music. I don't think the
ABC standard's business is to describe software systems; it should
describe the meaning of the ABC notation and leave it to the individual
software systems to pick that up and run with it. I'm glad to hear that
we see eye to eye in this.

Anselm
-- 
Anselm Lingnau .. [EMAIL PROTECTED]
Jock, when ye hae naething else to do, ye may be aye sticking in a tree; it
will be growing, Jock, when ye're sleeping.
 -- Sir Walter Scott, *The Heart of Midlothian*

To subscribe/unsubscribe, point you

Re: [abcusers] something really simple

[Laurie Griffiths]

So how might it look using "key=value" and still trying to be easy to parse,
backward compatible, etc.  Again I'm going to write examples +explanation
rather than BNF because I feel it helps debate at this stage.

% In file header (ONLY in file header so as to keep BarFly happy)
Q:Allegro con moto=130
Q:Allegro = 120
Q:Skipping =105
Q:tres lentement= 40  % je n'ai pas d'accent grave ici, je m'excuse

%In tune header or in tune itself
M:beat=1/4
Q:Allegro

M:beat=3/8
Q:skipping

In the definition form of Q: it must occur in the file header and the first
thing after Q: is not a number.  For backward compatibility the thing
defined must not be a single letter (because
Q:C=130
already has a meaning.
After that everything up to = is the name of the thing to be defined.  It
can contain any character except linend, % or =.  [Open question do we take
the escape and allow "\%", "\=", "\n" and "\\" to represent "%", "=", linend
and "\" ?  It gives complete freedom of what we can write, but it dirties up
the parsing for little real gain].
For future discussion I will refer to the parts as
Q:=
Note that old software will probably barf because it looks nothing like an
old Q: line, but so what?  It's meaning is also nothing like an old Q:.

TempoName is to be case insensitive (so that QUICK, quick and Quick, or even
qUIcK all represent the same name).  Any leading or trailing blanks are to
be discarded, otherwise no changes are allowed, so "con moto" is *not* the
same as "conmoto".

TempoValue is always to be a single number which is the number of beats per
minute.  This is apparently a regression towards the older style (like
Q:120) as opposed to the newer style (like Q:1/4=120), but now M:beat=3/8 is
introduced.  This allows 120 to mean "Allegro" whether the piece is in 6/8,
4/4, 2/4, 2/2, or whatever.  [Open question - should there be a default if
no "beat" is defined or should the program barf and complain that Q:quick is
meaningless without a beat?]

(I thought of the syntax Q:name="Allegro con moto" value="130" but I
rejected it).


Actions to be taken by programs [sorry!  sorry! "what the notations really
mean"].
These are for tune header or tune body only:

Q:Allegro
Player programs start playing at the previously defined Allegro rate.
Printing programs print Allegro.  

Q:display=Quasi allegro
Player programs take no action, printing programs print "Quasi allegro"

Q:1/4=60 display=Allegro
Player programs play at 1/4=60, printers print Allegro 

Q:1/4=60 display=
Player programs play at 1/4=60, printers don't do anything.

Q:1/4=60
Player programs play at 1/4=60, printers print something sensible e.g. .|=60

Q:Allegretto display=very slowly
Yes, it's silly but it's impossible to ban it.

That's probably enough to argue about.  If it seems to be acceptable then we
can cook up some more formal syntax.

Laurie

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Anselm Lingnau]

Simon Wascher <[EMAIL PROTECTED]> writes:

> Bring up formal arguments and alternatives. 

Well, guess what I have been doing for the last few days?

> 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)

Great. So there's apparently some middle ground.

> 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).

Yes. And in the future we will need some more extended syntax for this
and even more extended syntax for that. What's wrong with at least
agreeing on a method like `key=value' that will allow us to bring in
more fields as they are needed, without having to worry about how
programs will be able to tell where this bit of the line ends and the
next one begins? At least the `key=value' specifications are trivial to
parse, and the same parsing code works for all ABC headers that use this
syntax. You could use the same subroutine to parse lines like

  K:Gm clef="bass"
  V:fl instrument="Flute" short="Fl."
  Q:3/8=69 display="Allegro"

and the code for the particular header would just have to look at the
`leader' and the various `options' with their values to figure out the
meaning. This as opposed to having to write a special subroutine for
every header to deal with that header's particular syntax.

Writing `Q:3/8=69 - Allegro' may seem `user oriented and natural' at
first sight but after the special syntax for the `Q:' field has been
extended three more times to support other new (and at that moment
certainly important and desirable) features it may not feel so `natural'
after all.

> 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.

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.

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. 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 or because the
tune title should be printed flush-left in 15-point Palatino instead of
centered in 12-point Times Roman.

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? (The `mode="accelerando"'
idea that I posted the other day, while of course meant strictly as an
illustration at this point, is the sort of thing that we might run into
in the future.) This sort of thinking is what Gianni would probably call
`short-sighted' if he were still around.

> [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

  %%abctypesetter dont-display-metronome-speeds

option line w

Re: [abcusers] something really simple

[Laurie Griffiths]

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 really simple

[Laurie Griffiths]

:-)  Peace!

Anselm wrote "... So we get a `-' here and a mandatory space delimiter there
..." and actually that's pretty much how I felt about it myself (but I also
thought they were "the lesser evil" - we'll see how it works out, soo with
luck).

Simon wrote "please try to stay at the formal side with your postings"

Yes, I know there's a bit of history that we are living down, but at the
moment the debate is going forwards and we are discussing ideas.  We do have
to say what's wrong when we don't like things!  I myself confess to having
used the word "silly" but I did *not* mean that the person who wrote it was
silly.  We all get silly ideas sometimes, in fact silly ideas often can be
stepping stones to good ideas.  OK, OK, let's all be extra polite for a day
or two.
L.


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Simon Wascher]

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

[Anselm Lingnau]

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

Re: [abcusers] something really simple

[Laurie Griffiths]

At the moment I think I like the
M:4/4 beat=2/4
proposal.  It would solve most of the problems and if there is some problem
with Allegro in 13/8 that doesn't matter - it still enables much more than
the current syntax and you can always fall back on a completely explicit
Q:5/8=74
or whatever in those tunes.  I'm not 100% sure what the right default is in
the absence of a "beat=".  Is it the L value (explicit or implied)?

Laurie
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 6:31 PM
Subject: Re: [abcusers] something really simple


> There is a complication here that I don't think anyone has addressed.  By
> defining "Allegro" as 1/4=120, whether this is done in the playback
> software or in abc, you are assuming that "Allegro" is always based on a
> quarter note beat.  Therefore, alla breve allegro, with a half note as the
> beat, would play back at 60 beats per minute.  6/8 allegro, with a dotted
> quarter as the beat, would play back at 80 beats per minute.
>
> One possible solution:  Allow a different "Allegro" to be defined for each
> meter.  1/4=120 in 4/4 would not conflict with 3/8=120 in 12/8.  One
> problem with this is that the list of "Allegro" definitions could grow
> very large (and still would never be comprehensive).  Another problem is
> that in some meters, particularly compound meters, the value of the beat
> is not always obvious.  For instance, 3/8 time can be counted with three
> eighth-note beats to the measure, or with a single dotted-quarter beat.
>
> Another possible solution:  Define "Allegro" as simply "120".  Then each
> piece that uses "Allegro" must explicitly state what its "beat" is. It's
> probably not safe to rely on the L: field for this, but the M: field is a
> possible candidate, e.g. "M:6/8 beat=3/8".  The problem with this is that
> there are some meters in which the beat is not necessarily constant (e.g.
> 7/8 or 5/8).  There may be some cases in which neither 1/8=120, 1/4=120
> nor 3/8=120 would be an appropriate "Allegro".
>
> Yet another possible solution:  Limit the scope of any "Allegro"
> definition so that such conflicts would never occur.  This would probably
> narrow the scope to the current meter in the current piece/movement, which
> would render symbolic tempo definitions all but useless.
>
> Which leads to the final option, which is to regard the idea of symbolic
> tempo definitions as hopelessly complex, and abandon it altogether. :-)
>
> John
>
> 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 really simple

[jhoerr]

There is a complication here that I don't think anyone has addressed.  By
defining "Allegro" as 1/4=120, whether this is done in the playback
software or in abc, you are assuming that "Allegro" is always based on a
quarter note beat.  Therefore, alla breve allegro, with a half note as the
beat, would play back at 60 beats per minute.  6/8 allegro, with a dotted
quarter as the beat, would play back at 80 beats per minute.

One possible solution:  Allow a different "Allegro" to be defined for each
meter.  1/4=120 in 4/4 would not conflict with 3/8=120 in 12/8.  One
problem with this is that the list of "Allegro" definitions could grow
very large (and still would never be comprehensive).  Another problem is
that in some meters, particularly compound meters, the value of the beat
is not always obvious.  For instance, 3/8 time can be counted with three
eighth-note beats to the measure, or with a single dotted-quarter beat.

Another possible solution:  Define "Allegro" as simply "120".  Then each
piece that uses "Allegro" must explicitly state what its "beat" is. It's
probably not safe to rely on the L: field for this, but the M: field is a
possible candidate, e.g. "M:6/8 beat=3/8".  The problem with this is that
there are some meters in which the beat is not necessarily constant (e.g.
7/8 or 5/8).  There may be some cases in which neither 1/8=120, 1/4=120
nor 3/8=120 would be an appropriate "Allegro".

Yet another possible solution:  Limit the scope of any "Allegro"
definition so that such conflicts would never occur.  This would probably
narrow the scope to the current meter in the current piece/movement, which
would render symbolic tempo definitions all but useless.

Which leads to the final option, which is to regard the idea of symbolic
tempo definitions as hopelessly complex, and abandon it altogether. :-)

John

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laurie Griffiths]

I have a worry about this definition and use thing.  Our band has a book of
music, most of which is dance music (the rest is party pieces for
interludes).  I want to spell out the tempo in "steps per minute" but for a
4/4 step-hop hornpipe this is 1/4 (for a step or a hop), for a 4/4 reel this
is 2/4 (2 steps per bar), for a waltz it's probably 3/4 since although
waltzes are written in 3/4 they really are just in 1, for a jig it's
probably 3/8 (a walking step or a complete hop-step making a skip), so how
do I say (I'll do it sort of COBOL style!)
DEFINE Walking AS 1/4=120 FOR REEL OR 3/8=120 FOR JIG
and so on.

(And writing Walking in Italian as Andante does not help - incidentally
what's the classical music/italian word for "skipping" which would be about
3/8=105 or "skipping con moto" which would be about 3/8=95 to allow more
time in the air?).

Laurie

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laurie Griffiths]

- Original Message -
From: Anselm Lingnau <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 3:00 PM
Subject: Re: [abcusers] something really simple


> Laurie Griffiths <[EMAIL PROTECTED]> writes:
>
> > > Q:1/4=120 note="Pretty quickly"  % [2] explicit tempo with advisory
note
> >
> > OK acceptable but not my preference.  "note" is a keyword that I scan
for
> > (no problem).  The use of quotes immediately brings up the question of
"what
> > if the string is to contain a quote?"  An escape mechanism is needed
such as
> > using \" to represent a quote (and therefore \\ to represent \ too).
That
> > has been argued before and not everyone liked it.  It's at best a
necessary
> > evil, if it can be avoided altogether then it should be.
>
> Yes, but we will need *some* delimiter (the same problem occurs
> elsewhere in ABC, and we should be consistent), and any character at all
> can occur in a tune title, so an escape mechanism would be necessary in
> any case. Quotes are, at least, well entrenched in the delimiter role.

Read my proposal carefully.  There was no delimiter and the syntax worked.
OK, to be exact, the delimiter was that the first character of the stuff
after the last number must not be a number.  Thus if I wanted to have
"1-2-3-4" printed as the tempo string I'd have to code
Q:3/8=105 1-2-3-4
as opposed to
Q:3/8=1051-2-3-4
But I could write
Q:3/8=105Larghetto
with or without any space.  This is so unobtrusive that most people would
not notice it and there is no need for any escape mechanism.  The trick was
to always have the number part first.

> Presumably the `key=value' syntax could be specified to require no
> spaces between `key' and `=' and `value'. This would make it easy to
> distinguish from the `key' occuring on its own in all but pathological
> cases.

Starting to get artificial and people will get it wrong - one of the lessons
in writing an ABC parser is that in real life spaces (end even line-breaks)
turn up in many places where they are not really allowed.  I don't like
this.

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).  Instead of saying yes
or no you sort of went off with your own.  You did suggest that it was too
complicated but to me it looks less complicated than yours.

We will never reach agreement unless people start saying so when things seem
acceptable.
if things are acceptable but you can see an improvement then you (everyone)
must say both things.  We can then perhaps start to build core proposals
that are acceptable and continue to work on the fringes.  Eventually there
may be enough core stuff to draft, approve, implement, release and use.  of
course we can still carry on arguing about the NEXT thing.

Laurie
"If you think education is expensive, try ignorance" - Mark Twain

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laurie Griffiths]

> I guess this is a bit like folk music, where the notes that are written
> down and the ones that actually get played are independent of each
> other :-)

Foul!  Foul!  Referee!!  Throw him off the list!! :-)
L.

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Simon Wascher]

Hello,

Phil Taylor wrote:
> I don't see the necessity to specify in the abc what the program should do
> with the data.  Surely (as Anselm has pointed out) these are local options
> to be set in a preferences file or command-line switch?

Even if so, it would be very helpfull to find a syntax that *can* be
parsed by a program for *this*. So there is no way passing the fact that
the ability of marking the part of the Q: string that is for display is
needed for programs to recognize it *also* if its just for a local
option. 

But:
I belive it must be possible within the standard for a main purpose:

a composer marked the composition with a tempo mark: lentement
this should be displayed. The default playback tempo usual programmes
choose is to fast and lentement is not defined in the programms internal
macros (even if it is it may not be implemented by a person who follows
the same music scientific school the transcriber does). So playback
tempo must be defined. As it is not original, the transcriber does not
want it to be printed with the score. To be precise: it is *purely* for
the abc player and *not* for the display. But its not a personal thing
that can be left to the local options. 

So here we are:
Q:3/8=20 - lentement

in fact this is the only way to make sure the playback tempo is
connected to the tune if it is extracted from the file. This will be the
case allways when a transcriber wants to make sure that a playback tempo
remains with a tune, but a textual tempo header should be displayed. 
So in all cases where macro scepticers want to use playback active
textual tempo indicators. 


Two more things: 
1) examples are for writing a syntax not ony a "what do I personally
need" but also testing ojects for the syntax. So the procedere is to
think about the weirdest "testing objects" and finding whether the
syntax can handle them or not. Sometimes like in the above case, both go
together, the testing object and the need.

2) as Guido remarked, one of the disadvantages of the current abc
standard is that it did not look far enough ahead and is quite narrow
therefore. I belive that it is important that the standeard can coope
with examples that are far from our immagination and understanding in
terms of "what is this for?"

(this is why my original proposal was:

If there is a n/n=n string right after the colon this will not be
printed if it is followed by any other character. everething else is
printed entirely. 

because this does not need a special character or something similar at
all. Just a "special case" as Laurie called it, the playback only with
the minus [or any other single charctrer we choose].)
 

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

[Laurie Griffiths]

Fine - so to fix your objections
1. definitions like
Q:3/8=largo
may only go in the "file header"

What's the definition of "File Header"?
Between start of file and first X: ? (What about all those files with
missing X: lines?)
Between start of file and first X: or T:? (are we allowed a file title?)

2. Given that there is something following the third number this must be a
definition not a default, but an old program might mistake that.  Not easy
to get round that without having a completely new syntax for the
definitions.  A hack is to put after the last definition a default for the
file that will be picked up by old software.  e.g.
Q:1/4=80 largo %definition
Q:1/4=160 presto %definition
Q:1/4=120  %default

Laurie
P.S. But now it turns out that I'm not happy - see next posting.

- Original Message -
From: Phil Taylor <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 12:40 PM
Subject: Re: [abcusers] something really simple


> Laurie wrote:
>
> >OK, Anselm, let me try.
> >First of all it is NOT complicated to implement.  It's pretty easy.
> >Secondly a language or a notation is not to be judged by whether or not
you
> >can say silly things.  (Anyone who judged a natural language by this
> >criterion would have to be barking in fact quite out of their tiny, so
let's
> >not get our Allen's twisted).
> >I can't imagine why anyone would want to write
> >Q:1/4=120 1/4=80
> >which would have the effect of playing at 120 while showing 80, so I am
not
> >interested in whether it's legal or not.  All non-trivial languages allow
> >you to write stupid things.  This sentence is a syntactically correct but
> >syntactically incorrect sentence.  This sentence is a colourless pink
> >banana.  2+2 = -3.7 and so on.
>
> OK.
>
> >So that leaves discussion of what you can do.
> >People wanted
> >a. The ability to define a name for a tempo OK - can do:
> >Anywhere outside the scope of another tune and before the X: of the tune
> >where it is to be used, write:
> >Q:1/4=80 largo
>
> I have two problems with this.  First (as I said before) it causes trouble
> for programs which treat an abc file as random-access if you allow the
macro
> definitions in between tunes (as opposed to in the file header).  Secondly
> Q: is already a legal field in the file header under the abc 1.6
definition,
> so you really need something to mark this out as a macro definition rather
> than a default setting for tempo to be used in all the following tunes.
>
> >b. The ability to use that tempo and have it displayed and played.  Can
do:
> >In the tune (body or header) write:
> >Q: largo
>
> OK.
>
> >c. The ability to say something meaningful to a computer about how it is
to
> >be played at the same time as writing something meaningful to a human
(and
> >preferably meaning the same thing) displayed.  Can do (but the bit about
> >meaning the same thing is not enforced).
> >In the header or body of the tune write
> >Q:1/4=80 largo
>
> OK.
>
> >d. The ability to have a tempo set for the computer to play the music but
> >without anything displayed.  Can do:
> >In the tune (body or header) write
> >Q:1/4=80 -
>
> I don't see the necessity to specify in the abc what the program should do
> with the data.  Surely (as Anselm has pointed out) these are local options
> to be set in a preferences file or command-line switch?
>
> >e. The ability to accept old style ABC.
> >Can do, for instance
> >Q: 1/4=80
>
> OK.
>
> >f. Do all this without upsetting old programs too much if they are fed
the
> >new.
> >As all the new stuff occurs on the end of a legal old-style command,
there
> >is reason to hope that old programs might not be too upset by versions c
or
> >d (and of course not by e).
>
> They don't faze current versions of BarFly as long as the numerical
> specification
> comes first.
>
> >g. Do all this in such a way that it is easy to implement in existing or
new
> >computer programs.
>
> OK.
>
> >Now, considering that all of this is optional so you never need to use
any
> >of it unless you actually want to do these things, I submit it is *not*
too
> >complicated but is about as simple as it could possibly be.  If you have
a
> >simpler scheme that does a..g, please say!
>
> I don't see any point in being able to write one tempo for display in the
> abc and another, different tempo for playback, but that the ability to do
> that is just a side effect of what is being proposed here.
>
> Phil Taylor
>
>
> 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 really simple

[Anselm Lingnau]

Laurie Griffiths <[EMAIL PROTECTED]> writes:

> > Q:1/4=120 note="Pretty quickly"  % [2] explicit tempo with advisory note
> 
> OK acceptable but not my preference.  "note" is a keyword that I scan for
> (no problem).  The use of quotes immediately brings up the question of "what
> if the string is to contain a quote?"  An escape mechanism is needed such as
> using \" to represent a quote (and therefore \\ to represent \ too).  That
> has been argued before and not everyone liked it.  It's at best a necessary
> evil, if it can be avoided altogether then it should be.

Yes, but we will need *some* delimiter (the same problem occurs
elsewhere in ABC, and we should be consistent), and any character at all
can occur in a tune title, so an escape mechanism would be necessary in
any case. Quotes are, at least, well entrenched in the delimiter role.

It would be possible to take an idea from XML and allow either
`key="..."' or `key='...'', where the `'' could occur inside `"..."' and
the `"' inside `'...'' (got that?). This would reduce the problematic
cases to those that include both single and double quotes. Personally I
don't see what is so bad about `\"' and `\\'; at least I can make out
little call for a backslash in tempo advisory notes, and given ABC's
roots in TeX it might actually be a good idea (memetically speaking).

> > Q:Allegro% [3] symbolic tempo specification, metronome
> > % speed (or range) defined elsewhere
> 
> Maybe OK, maybe not.  What's the syntax for the "Allegro" thing?

Jack Campin posted a BNF specification for that part of the proposal
ages ago. In his specification, the tempo labels may contain alphabetic
characters and spaces but not numerals or special characters. This
sounds reasonable to me.

> Is it too complicated?? What is the syntax of the
> "Allegro" part.  Can it be more than one word? e.g.
> Q:Allegro moderato note="Fairly quickly"

Sure, see above.

> Can it contain keywords such as "note"? e.g.
> Q:Allegro but see note from composer note="Pretty quickly"

Presumably the `key=value' syntax could be specified to require no 
spaces between `key' and `=' and `value'. This would make it easy to 
distinguish from the `key' occuring on its own in all but pathological 
cases.

> > Q:Allegro 1/4=120-128% [6] definition of range
> 
> Not OK.  For a player program this is just silly.  It can only play at one
> speed at a time.  I can't see any point in choosing a random number in the
> range given and I can't see in the near future a program that will have such
> intelligence that it can interpret the music by finding the best number in
> the range.  Better to just say 124.

This is from Jack's original proposal. IMHO it is nice to be able to
specify a range of metronome speeds in sheet music (which is something
that does occur in practice but which Simon's proposal conveniently
ignores). Player programs are free to pick a speed (any speed, but in
the absence of better ideas the arithmetic mean should be fine) from the
range, just like a human musician would be; the user should of course be
able to override this like any other speed specification.

> >...
> > Q:1/4=120 mode="accelerando"
> 
> This is a new departure that goes beyond anything discussed so far.

Of course. If you go back to my earlier message I think you will find
that this was only meant as an illustration of how the `key=value'
notation allows further extensions in the future with very little new
syntax needed. Simon's proposal would require the invention of more
ad-hoc special syntax to accommodate this on top of the special `Q:'
field syntax that is already there. I thought that I made this clear in
my original posting but apparently I didn't.

> Incidentally it still has the possibility of writing something like
> 
> Q:Prestissimo 1/4=220   %defines Prestissimo
> Q:Largo 1/4=40   % defines Largo
> ...
> Q:Largo note="Prestissimo"
> 
> which will play extremely slowly while displaying something meaning
> extremely fast.

You apparently misunderstood the original proposal regarding
`note="..."'. While I'm not about to prescribe what notation programs
`must' do, my suggestion for this combination (case [4] in my earlier
posting) is to display

  Largo (Prestissimo)

or

  Largo (Prestissimo) - .|=40

and we shall just have to see what musicians will make of this! :^)

The `note="..."' is just an advisory note that should influence neither
the displayed metronome speed nor the speed that a piece is played back
at. Given a notation program with enough degrees of freedom one could
probably figure out how to make the notation program generate just
`Prestissimo' and no metronome speed, while a player program would use
the 1/4=40 specification (as it should!). I can live with that -- at
least this possibility does not complicate the standard over and above
Jack's original proposal (modified to allow `note="..."'), which in
itself is fairly simple and minimal. If anything, your observation
corroborates the co

Re: [abcusers] something really simple

[James Allwright]

On Tue 13 Nov 2001 at 08:13AM -0500, Laura Conrad wrote:
> > "Phil" == Phil Taylor <[EMAIL PROTECTED]> writes:
> 
> 
> Lilypond, which is the printing program I'm actually using these days,
> has a MIDI block and a score block, so the two speeds are actually
> completely independent unless you do something to set up a macro to
> make them the same.
> 

I guess this is a bit like folk music, where the notes that are written
down and the ones that actually get played are independent of each
other :-)

James

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laura Conrad]

> "Phil" == Phil Taylor <[EMAIL PROTECTED]> writes:

Phil> But why would you want to record your proofreading speed in the abc for
Phil> posterity?  Surely you just want to override the given tempo using a
Phil> setting local to your program?

I might want to have a global proofreading speed that operates
whatever the actual speed of the 16th notes should be.

I just gave that as an example of why you would want to play at a
speed different from the speed you display to the human.  In my case I
pretty much only use the MIDI files for proofreading, so if they end
up with a "wrong" speed it doesn't bother me that much, but if the
printing program displays a "wrong" speed, it's a problem.

Lilypond, which is the printing program I'm actually using these days,
has a MIDI block and a score block, so the two speeds are actually
completely independent unless you do something to set up a macro to
make them the same.

-- 
Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ )
(617) 661-8097  fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: how to define textual header indicators was: Re: [abcusers] something really simple

[Laurie Griffiths]

Simon wrote:
...
> PS: how do you like my actual proposal for the Q:field ? (besides the
> macro topic)

OK. Acceptable.

Laurie

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laurie Griffiths]

In what lies below, Anselm wrote the bits with > at the start

>...
>The counter-proposal stands:

> Q:1/4=120% [1] explicit tempo specification

OK, No problem, backward compatibility etc.

> Q:1/4=120 note="Pretty quickly"  % [2] explicit tempo with advisory note

OK acceptable but not my preference.  "note" is a keyword that I scan for
(no problem).  The use of quotes immediately brings up the question of "what
if the string is to contain a quote?"  An escape mechanism is needed such as
using \" to represent a quote (and therefore \\ to represent \ too).  That
has been argued before and not everyone liked it.  It's at best a necessary
evil, if it can be avoided altogether then it should be.

> Q:Allegro% [3] symbolic tempo specification, metronome
> % speed (or range) defined elsewhere

Maybe OK, maybe not.  What's the syntax for the "Allegro" thing?
Is it a string which must have been defined before with no changes at all?
Is it to be recognised if the case of some letters are changed?
Are spaces allowed.  Is it regarded as different if spaces are changed?
Is it allowed to contain absolutely any character except linend and %?
Are numbers allowed?  How about /? How about "? How about =?

> Q:Allegro note="Pretty quickly"  % [4] symbolic tempo with advisory note

Maybe OK.  This goes beyond the other proposal.  It is more complicated than
the other proposal?  Is it needed?  It's a little more bother to implement
but is not hard.  Is it too complicated?? What is the syntax of the
"Allegro" part.  Can it be more than one word? e.g.
Q:Allegro moderato note="Fairly quickly"
Can it contain keywords such as "note"? e.g.
Q:Allegro but see note from composer note="Pretty quickly"

> Q:Allegro 1/4=120% [5] definition of symbolic tempo

Maybe OK. Again - what is the syntax of the "Allegro" part?  Now it looks as
though it must not contain any numbers.  Is it allowed to contain multiple
words?  Is it restricted to a single word with no spaces?  (I might want
"Allegro moderato" or "step hop"

> Q:Allegro 1/4=120-128% [6] definition of range

Not OK.  For a player program this is just silly.  It can only play at one
speed at a time.  I can't see any point in choosing a random number in the
range given and I can't see in the near future a program that will have such
intelligence that it can interpret the music by finding the best number in
the range.  Better to just say 124.

>...
> Q:1/4=120 mode="accelerando"

This is a new departure that goes beyond anything discussed so far.  I
presume that the idea is that the program should increase tempo smoothly
between this point and the next tempo given in the next Q:
It raises a lot of problems if there are repeats (or P: da capo or any other
non-sequential play indications around).  I'd prefer to postpone this one
until we've got the "really simple" thing sorted out.  That's a NO vote in
case I wasn't clear.

The things I see different in this set of proposals are
1. The ability to have a speed set by a symbol defined earlier (such as
Allegro) and displayed as something different again.  Is this required?

2. It is less clear how to parse it because a definition with numbers in
(e.g. 1/8=120) does not always occur as the first thing in the command, so
we need rigid rules as to how to find it.

3. The syntax is less clear because I don't know whether the identifier like
"Allegro" is required to be just a single word or what.

4. Introduction of "accelerando" which is for me a bridge too far when we
are still arguing about something "really simple"!!

Incidentally it still has the possibility of writing something like

Q:Prestissimo 1/4=220   %defines Prestissimo
Q:Largo 1/4=40   % defines Largo
...
Q:Largo note="Prestissimo"

which will play extremely slowly while displaying something meaning
extremely fast.  This is not a problem to me, but apparently was to Anselm
who, in the words of Shakespeare is "hoist on his own petard" (means blown
up by his own bomb).  [Lest anyone think I am smirking - I might add "been
there myself, done that myself"]

Laurie

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Phil Taylor]

Laurie wrote:

>OK, Anselm, let me try.
>First of all it is NOT complicated to implement.  It's pretty easy.
>Secondly a language or a notation is not to be judged by whether or not you
>can say silly things.  (Anyone who judged a natural language by this
>criterion would have to be barking in fact quite out of their tiny, so let's
>not get our Allen's twisted).
>I can't imagine why anyone would want to write
>Q:1/4=120 1/4=80
>which would have the effect of playing at 120 while showing 80, so I am not
>interested in whether it's legal or not.  All non-trivial languages allow
>you to write stupid things.  This sentence is a syntactically correct but
>syntactically incorrect sentence.  This sentence is a colourless pink
>banana.  2+2 = -3.7 and so on.

OK.

>So that leaves discussion of what you can do.
>People wanted
>a. The ability to define a name for a tempo OK - can do:
>Anywhere outside the scope of another tune and before the X: of the tune
>where it is to be used, write:
>Q:1/4=80 largo

I have two problems with this.  First (as I said before) it causes trouble
for programs which treat an abc file as random-access if you allow the macro
definitions in between tunes (as opposed to in the file header).  Secondly
Q: is already a legal field in the file header under the abc 1.6 definition,
so you really need something to mark this out as a macro definition rather
than a default setting for tempo to be used in all the following tunes.

>b. The ability to use that tempo and have it displayed and played.  Can do:
>In the tune (body or header) write:
>Q: largo

OK.

>c. The ability to say something meaningful to a computer about how it is to
>be played at the same time as writing something meaningful to a human (and
>preferably meaning the same thing) displayed.  Can do (but the bit about
>meaning the same thing is not enforced).
>In the header or body of the tune write
>Q:1/4=80 largo

OK.

>d. The ability to have a tempo set for the computer to play the music but
>without anything displayed.  Can do:
>In the tune (body or header) write
>Q:1/4=80 -

I don't see the necessity to specify in the abc what the program should do
with the data.  Surely (as Anselm has pointed out) these are local options
to be set in a preferences file or command-line switch?

>e. The ability to accept old style ABC.
>Can do, for instance
>Q: 1/4=80

OK.

>f. Do all this without upsetting old programs too much if they are fed the
>new.
>As all the new stuff occurs on the end of a legal old-style command, there
>is reason to hope that old programs might not be too upset by versions c or
>d (and of course not by e).

They don't faze current versions of BarFly as long as the numerical
specification
comes first.

>g. Do all this in such a way that it is easy to implement in existing or new
>computer programs.

OK.

>Now, considering that all of this is optional so you never need to use any
>of it unless you actually want to do these things, I submit it is *not* too
>complicated but is about as simple as it could possibly be.  If you have a
>simpler scheme that does a..g, please say!

I don't see any point in being able to write one tempo for display in the
abc and another, different tempo for playback, but that the ability to do
that is just a side effect of what is being proposed here.

Phil Taylor


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Anselm Lingnau]

Simon Wascher <[EMAIL PROTECTED]> writes:

> The problem is that there are situations where it is necessary to have
> part of the tempo indicator displayed and parts not.
> 
> Example:
> 
>   Q:1/4=120 - Allegro % displaying "Allegro" and playing 1/4=120
> 
> In your proposal how can this be done ?

  Q:1/4=120 note="Allegro"  % and switch off display of metronome speeds

Again: Whether or not a metronome marking is displayed should depend on
a style setting within the notation program. It doesn't need to, and in
fact shouldn't, be specified in the ABC standard. The ABC standard
doesn't specify the font and point size of tune titles, either
-- if I want to prepare a publication using ABC-notated music this is a
stylistic decision on my part since I am designing the publication.
Similarly, it is a stylistic decision on my part whether I want
metronome markings or historical notes displayed with the music, or how
far the staves should be from each other, or how wide the margins are,
and so on. An ABC file should contain all the requisite information but
should make as few stipulations as possible about what programs will
actually do with that information.

For example, in a book of traditional Scottish reels and jigs for
dancing there is no need to include metronome speeds, since these are
obvious to a SCD musician, but they can still be useful for a playback
program. So you just set your notation program to suppress the `Q:' line
metronome speeds. But the same ABC-notated tune could figure in a book
of dance tunes from all over the world, and since it wouldn't be obvious
to somebody who plays Scandinavian or Israeli dance music how fast a jig
or reel should be played (or `Ivanica', for a Scottish musician), you
will probably want to include metronome speeds after all. So you switch
them on in your notation program. Why should you have to change the
ABC-notated tune to control exactly what is being printed?

> > supposed to do). We don't need special syntax for every single ABC
> > header field when there is a general pattern that we can apply, like the
> > `key=value' convention outlined above.
> 
> Remember : the minus sign only is used in cases where something is *not*
> printed. so it is additional syntax, not alternative.

Yes, but we don't put

  C:W. A. Mozart -

if we don't want the composer to be printed. We tell the notation 
program to leave that field out. This makes your `Q:' syntax a special 
case. Unnecessary special cases are ... well, unnecessary.

Anselm

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laurie Griffiths]

OK, Anselm, let me try.
First of all it is NOT complicated to implement.  It's pretty easy.
Secondly a language or a notation is not to be judged by whether or not you
can say silly things.  (Anyone who judged a natural language by this
criterion would have to be barking in fact quite out of their tiny, so let's
not get our Allen's twisted).
I can't imagine why anyone would want to write
Q:1/4=120 1/4=80
which would have the effect of playing at 120 while showing 80, so I am not
interested in whether it's legal or not.  All non-trivial languages allow
you to write stupid things.  This sentence is a syntactically correct but
syntactically incorrect sentence.  This sentence is a colourless pink
banana.  2+2 = -3.7 and so on.

So that leaves discussion of what you can do.
People wanted
a. The ability to define a name for a tempo OK - can do:
Anywhere outside the scope of another tune and before the X: of the tune
where it is to be used, write:
Q:1/4=80 largo

b. The ability to use that tempo and have it displayed and played.  Can do:
In the tune (body or header) write:
Q: largo

c. The ability to say something meaningful to a computer about how it is to
be played at the same time as writing something meaningful to a human (and
preferably meaning the same thing) displayed.  Can do (but the bit about
meaning the same thing is not enforced).
In the header or body of the tune write
Q:1/4=80 largo

d. The ability to have a tempo set for the computer to play the music but
without anything displayed.  Can do:
In the tune (body or header) write
Q:1/4=80 -

e. The ability to accept old style ABC.
Can do, for instance
Q: 1/4=80

f. Do all this without upsetting old programs too much if they are fed the
new.
As all the new stuff occurs on the end of a legal old-style command, there
is reason to hope that old programs might not be too upset by versions c or
d (and of course not by e).

g. Do all this in such a way that it is easy to implement in existing or new
computer programs.

Now, considering that all of this is optional so you never need to use any
of it unless you actually want to do these things, I submit it is *not* too
complicated but is about as simple as it could possibly be.  If you have a
simpler scheme that does a..g, please say!

Laurie

- Original Message -
From: Anselm Lingnau <[EMAIL PROTECTED]>
...
> I think this is much too complicated. I'm still waiting for you (or
> anybody) to explain why an ABC tune should contain one prescribed
> explicit metronome speed for display and another, different, prescribed
> explicit metronome speed for playback, and why this would be preferable
> to letting users set their own playback speeds `ad hoc', external to the
> ABC representation, with the ABC-provided speed as a (reasonable) default.
>
> Anselm


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Phil Taylor]

Laura Conrad wrote:
>> "Anselm" == Anselm Lingnau <[EMAIL PROTECTED]> writes:
>
>Anselm> I'm still waiting for you (or anybody) to explain why an
>Anselm> ABC tune should contain one prescribed explicit metronome
>Anselm> speed for display and another, different, prescribed
>Anselm> explicit metronome speed for playback,
>
>Because you might want to tell a human player what speed you think the
>piece sounds good at, but you want to tell the computer what speed you
>want to proofread your transcription at?

But why would you want to record your proofreading speed in the abc for
posterity?  Surely you just want to override the given tempo using a
setting local to your program?

Phil Taylor


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Simon Wascher]

Hello Anselm,

Anselm Lingnau wrote:
> Simon Wascher <[EMAIL PROTECTED]> writes:
> > Lets say you are right, its completely impossible that someone needs
> > that.
> I'm not claiming that it is impossible for anybody to need this. But if
> this is a sensible proposal then surely there must be an example of an
> application that requires it? Obviously if there isn't an actual
> requirement for this notation (other than `Simon says so') there is no
> need to clutter up the standard with it.

Anselm, I posted examples about three times.

> > So why bother about its syntax if you cannot imagine someone may need it?
> I do bother about the proposed syntax because I want the ABC standard to
> stay as simple and straightforward as possible (while still being as
> expressive as is reasonable). If this means we have to think more and
> harder instead of catering for every whim at a moment's notice then
> `tough'.

If you *read* the standard I proposed, You will see that in all cases
you or Frank asked for this syntax reacts completely straightforward an
simple and also in many of the odd examples Laurie gave. In fact it
always reacts straitforewardn and simple.

> The counter-proposal stands:
> 
>   Q:1/4=120% [1] explicit tempo specification
>   Q:1/4=120 note="Pretty quickly"  % [2] explicit tempo with advisory note
>   Q:Allegro% [3] symbolic tempo specification, metronome
>% speed (or range) defined elsewhere
>   Q:Allegro note="Pretty quickly"  % [4] symbolic tempo with advisory note
>   Q:Allegro 1/4=120% [5] definition of symbolic tempo
>   Q:Allegro 1/4=120-128% [6] definition of range


The problem is that there are situations where it is necessary to have
part of the tempo indicator displayed and parts not.

Example:

Q:1/4=120 - Allegro % displaying "Allegro" and playing 1/4=120

In your proposal how can this be done ?

I only found the solution of using two Q: lines, one definition line and
one tempo line but how should this work? It would make a definition line
before the X: line mandatory ! *this* is what I call failling of a
syntax. 
Or maybe you repair it by allowing definition *and* playback Q: fields
side by side inside a header. again: *this* is really a worst case
syntax.

having a syntax that allowes such: 
Q:1/4=120 - Allegro % displaying "Allegro" and playing 1/4=120
is usefull for: simply for those who want to include a program readable
but userdefined tempo indicater in a file where "Allegro" should be
displayed (for example because just "Allegro" is what the composer
indicated). 


> supposed to do). We don't need special syntax for every single ABC
> header field when there is a general pattern that we can apply, like the
> `key=value' convention outlined above.

Remember : the minus sign only is used in cases where something is *not*
printed. so it is additional syntax, not alternative.

Yes there should be a unique header expansion syntax (actually there is
no agreement on which). 
I have no problems if quotes are used or minus or pound signs . they are
as good or bad as nearly every other separator (and create other limits
to the syntax). 
I might just add that all your examples come from *draft* and till now
there is no agreement on whether this will become standard.

> > allegro is not more or less musical information or convention than
> > 1/4=120
> Wrong. 

Anselm. Some composers/musicians/transcribers want this some that.
Inside an abc tune 1/4=120 is the only way to influence a playback
function user/transcriber controled. 

> > . If implemented, it would, among other things, make it
> > > possible to control the tempo of a bunch of tunes without having to
> > > change the `Q:' line for every single one, which I find quite appealing.
> > You can have this by now by using your playback programes player
> > settings ;-) .
> > Or using a program that allows active R:fields
> 
> Active `R:' fields are quite another can of worms as long as their
> meaning is hard-coded in the player programs (like with abc2midi, 

In your own words: let these things to the program packages.

> Besides, what would you put in the active `R:' fields of, say, Bach's
> inventions or Chopin's études so their speed can be controlled?

This is slightly off topic, but if you really want to know, I could
figure out and send it to you of list. 
The main question for sure would be to give the playback function of the
program I use a definition for the tempo to play (as not to fall to some
default) and at the same time display whatever Bach or Chopin sugested
as a textual tempo indicator.


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

[Phil Taylor]

>Simon slipped in the words "external macro file".
>No!!  I am very much against this.  Although it may be convenient for
>writers of ABC it's horrid for readers.  It makles it even harder to extract
>a tune and the probability would be very high that we should find orphan
>bits of ABC floating round with macros used but not defined.

I don't really object to external macro files (BarFly uses one already for
ornaments), but I do think that some care is required in deciding where
macro definitions can be placed.  Currently BarFly permits macro and symbol
definitions (and global fields) to be placed in the tune header, in the file
header (i.e. between the start of the file and the first tune) or in a single
external file.  Note that they don't work if placed between tunes.  The
reason for this is that the program does not parse the file from beginning
to end;  it allows the user to jump from one tune to another in any order,
and only parses each selected tune on demand.  Under these circumstances it
would be very difficult to keep track of which macros apply to which tunes
if they were permitted between tunes.

It does seem to me that if you use verbal descriptions of tempo, you should
not expect other programs to play the music at the exact same pace.  After
all, that applies to human musicians too.  A metronome marking implies that
the composer wants the piece played at that exact speed, while a verbal
indication is a rough guide which the musician may interpret as he sees fit.

Phil Taylor


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Anselm Lingnau]

Laura Conrad <[EMAIL PROTECTED]> writes:

> Anselm> I'm still waiting for you (or anybody) to explain why an
> Anselm> ABC tune should contain one prescribed explicit metronome
> Anselm> speed for display and another, different, prescribed
> Anselm> explicit metronome speed for playback, 
> 
> Because you might want to tell a human player what speed you think the
> piece sounds good at, but you want to tell the computer what speed you
> want to proofread your transcription at?

The `proofreading speed' does not belong in the ABC notation (various
people might want to proofread at different speeds, and once the tune is
properly proofread, i.e., by the time one is ready to share the ABC file
with the world at large, the proofreading speed specification is no
longer required at all). It is much better to set this up using a
command-line option/interactive slider/... of the playback program, and
playback programs should offer such a method of overriding the `Q:'
speed.

This is analogous to the case of wanting to extract single voices from a
multi-voice piece (so every musician can have their own part instead of
having to deal with the whole lot). This is also done much more
conveniently using, e.g., command-line options to a notation program,
rather than by having to change the ABC file eight times for an octet. I
often practice SCD piano accompaniment by playing along with an
ABC-based rendition of the melody line, and it is much nicer to be able
to set up the playback speed in the playback program than it is to edit
the ABC file, if the only thing I want is `everything a bit slower'.

I think that in this case the new ABC standard would be better for an
application of Occam's razor.

Anselm


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Frank Nordberg]

James Allwright wrote:
> 
> What programmers cannot do is re-write applications retrospectively.
> Adding new syntax that is incompatible with the old syntax causes
> hassles for everyone who uses abc.

I understand that. In this case the problem would of course be older
programs that can't make sense of text in the Q: field and are not able
to just ignore it.
But the only way to solve that would be to add not one, but *two*
separators. Something like:

Q:1/4=120 %%playback Allegro %%display Allegro

FRank Nordberg
http://www.musicaviva.com

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laura Conrad]

> "Anselm" == Anselm Lingnau <[EMAIL PROTECTED]> writes:

Anselm> I'm still waiting for you (or anybody) to explain why an
Anselm> ABC tune should contain one prescribed explicit metronome
Anselm> speed for display and another, different, prescribed
Anselm> explicit metronome speed for playback, 

Because you might want to tell a human player what speed you think the
piece sounds good at, but you want to tell the computer what speed you
want to proofread your transcription at?


-- 
Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ )
(617) 661-8097  fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Anselm Lingnau]

Simon Wascher <[EMAIL PROTECTED]> writes:

> Lets say you are right, its completely impossible that someone needs
> that. 

I'm not claiming that it is impossible for anybody to need this. But if
this is a sensible proposal then surely there must be an example of an
application that requires it? Obviously if there isn't an actual
requirement for this notation (other than `Simon says so') there is no
need to clutter up the standard with it.

> So why bother about its syntax if you cannot imagine someone may need it?

I do bother about the proposed syntax because I want the ABC standard to
stay as simple and straightforward as possible (while still being as
expressive as is reasonable). If this means we have to think more and
harder instead of catering for every whim at a moment's notice then
`tough'.

The counter-proposal stands:

  Q:1/4=120% [1] explicit tempo specification
  Q:1/4=120 note="Pretty quickly"  % [2] explicit tempo with advisory note
  Q:Allegro% [3] symbolic tempo specification, metronome
   % speed (or range) defined elsewhere
  Q:Allegro note="Pretty quickly"  % [4] symbolic tempo with advisory note
  Q:Allegro 1/4=120% [5] definition of symbolic tempo
  Q:Allegro 1/4=120-128% [6] definition of range

  and it is up to individual notation programs how they will display
  these bits of information, while player programs should default to
  the metronome speeds that are specified either explicitly in the tune
  or, in the case of symbolic tempo specifications, elsewhere, while
  giving users the chance to override the speed if they want.

  Suggestions for tempo display by notation programs:

  [1] .|=120
  [2] Pretty quickly - .|=120
  [3] Allegro
  Allegro - .|=120 % if desired, and if `Allegro' is defined accordingly
  [4] Allegro (Pretty quickly)
  Allegro (Pretty quickly) - .|=120
  [5] and [6] will not be displayed.

  Notation programs could also offer to display just metronome speeds or
  just advisory notes, or to suppress metronome speeds or advisory notes
  altogether.

The `note="..."' construction may seem wordy but in fact it is
consistent with similar notation elsewhere in (de-facto) ABC such as the
`V:' and `K:' fields. This is a lot better than inventing ad-hoc syntax
for every single field, such as the `Q:n/n=n - Andante' proposal seen
earlier on. In fact at some point in the future it could allow us to say
something like

  ... some music ...
  Q:1/4=120 mode="accelerando"
  ... more music ...
  Q:1/4=140
  ... even more music ...

to express a dynamic change of speed between two points in time. This
falls naturally out of the `key=value' syntax, while in your proposal
one would have to invent even more ad-hoc syntax on top of what is
already there to allow this.

> It is neccesary to encounter the edges of a choosen syntax to be able if
> it is stringent, search deeply for the worst cases it produces. This is
> how a syntax is developed. Every syntax has its dark corners and all we
> can do is turn the pockets around till we find the least important
> corner in our proposal to contain the blackest hole of our syntax. So
> here it is: Q:n/n=n N/N=N andante, dark and sinister but without any
> meaning in real life.

I disagree. To apply some wisdom that I think goes back to Antoine de
St. Exupéry, a common fallacy in language design is to consider a
language complete when there is nothing left to add. (This leads us to
abominations like C++.) In fact, a design is usually much better when
there is nothing left to take away (and it still does what it is
supposed to do). We don't need special syntax for every single ABC
header field when there is a general pattern that we can apply, like the
`key=value' convention outlined above.

Anselm
-- 
Anselm Lingnau .. [EMAIL PROTECTED]
When the gods wish to punish us they answer our prayers.
 -- Oscar Wilde, *An Ideal Husband*

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

how to define textual header indicators was: Re: [abcusers] something really simple

[Simon Wascher]

Hello,

Laurie Griffiths wrote:
> 
> Simon slipped in the words "external macro file".
> No!!  I am very much against this.  Although it may be convenient for
> writers of ABC it's horrid for readers.  It makles it even harder to extract
> a tune and the probability would be very high that we should find orphan
> bits of ABC floating round with macros used but not defined.

definable textual tempo indicaters were the start of this topic: 
Jack Campin wrote on 03Nov01:
> Okay: tempi in words.
> It ought to be possible to write
> 
>Q:allegro
> in a tune header or
>[Q:allegro]
> in a tune body, and optionally define outside the tune (earlier in
> the same file or maybe in a separate settings file) what "allegro"
> might mean in numerical terms, with a line like this:
> 
>Q:allegro 1/4=120

and till now nobody objected as far as I remember. "in a separate
settings file" very much sounds like "external macro".
About yesterday evening (lokal time :-) ) I sugested to separate the
play/display and the textual tempo indicater topics into two separate
subjects as they are not really related.

_Ok lets talk about where to define textual tempo indicaters_

Jacks first proposal was only to allow textual tempo indicaters (no
playback, only display or maybe a playback definition whitin the
program-package)
no playback, only display is what you also get from a tune that is cut
of from its macro files.
A playback definition within a program is package dependend. After
export, same result: no definition, just display and default in action.

"earlier in the same file" as Jack also sugested ends up with the same
problem at any export from the file, for example by the tunefinder. same
result: no definition, just display and default in action.

"or maybe in a separate settings file" as I mentioned sounds very much
like "external macro file"

I personally use the R: fields playback functions whith BarFly and never
found them a problem. The text in the R:field has a meaning of its own
if the tune is cut of from its macro file and so it would be with tempo
indicators.
Its true its not standard. So it must undergo discussion anyway.

Simon

PS: how do you like my actual proposal for the Q:field ? (besides the
macro topic)

-- 
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

[Simon Wascher]

Anselm Lingnau wrote:
> Simon Wascher <[EMAIL PROTECTED]> writes:
> > Example
> > X:1
> > Q:n/n=n N/N=N andante
> I think this is much too complicated. I'm still waiting for you (or
> anybody) to explain why an ABC tune should contain one prescribed
> explicit metronome speed for display and another, different, prescribed
> explicit metronome speed for playback, and why this would be preferable
> to letting users set their own playback speeds `ad hoc', external to the
> ABC representation, with the ABC-provided speed as a (reasonable) default.

Anselm you have to decide: 

you say you find this feature unneccessary. OK. 
Lets say you are right, its completely impossible that someone needs
that. 
So why bother about its syntax if you cannot imagine someone may need it
?

either want it to be easier to use OR say nobody needs it.

_the truth about syntax_

It is neccesary to encounter the edges of a choosen syntax to be able if
it is stringent, search deeply for the worst cases it produces. This is
how a syntax is developed. Every syntax has its dark corners and all we
can do is turn the pockets around till we find the least important
corner in our proposal to contain the blackest hole of our syntax. So
here it is: Q:n/n=n N/N=N andante, dark and sinister but without any
meaning in real life.

(by the way I wrote more than once that I know what I want to use it
for. And discribed it. I can live with the syntax, but I think I found a
better one which I posted)

Simon

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

[Anselm Lingnau]

Laurie Griffiths <[EMAIL PROTECTED]> writes:

> No!!  I am very much against this.  Although it may be convenient for
> writers of ABC it's horrid for readers.  It makles it even harder to extract
> a tune and the probability would be very high that we should find orphan
> bits of ABC floating round with macros used but not defined.

It's not as bad as all that. In the case of tempo specifications, a
player program could always fall back to a list of standard speeds (like
the ones given on a honest-to-goodness wind-up metronome) while
outputting a warning to its user that the tempo specification is
undefined. Notation programs are likely to output just the macro `name',
anyway (like `Allegro'), so it doesn't really matter whether there is a
speed associated with it or not.

The nice thing about Jack's original proposal (which the silly
discussion on `display' vs. `playback' speeds has managed to obscure
quite thoroughly) is that it abstracts musical information (like
`Allegro') from presentation issues and/or matters of taste/convention
(like `1/4=120'). If implemented, it would, among other things, make it
possible to control the tempo of a bunch of tunes without having to
change the `Q:' line for every single one, which I find quite appealing.

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

Re: [abcusers] something really simple

[Laurie Griffiths]

Simon slipped in the words "external macro file".
No!!  I am very much against this.  Although it may be convenient for
writers of ABC it's horrid for readers.  It makles it even harder to extract
a tune and the probability would be very high that we should find orphan
bits of ABC floating round with macros used but not defined.
Laurie





To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Anselm Lingnau]

Simon Wascher <[EMAIL PROTECTED]> writes:

> Example 
> X:1
> Q:n/n=n N/N=N andante 
> 
> will playback n/n=n and display N/N=N andante
> 
> so if a numeral tempo indicator is on the very beginning of such a
> string it must be written a second time for the display.
> 
> If no tempo indicator should be displayed but a playback tempo set this
> can be done using a "-" after the numeral tempo indicator.

I think this is much too complicated. I'm still waiting for you (or
anybody) to explain why an ABC tune should contain one prescribed
explicit metronome speed for display and another, different, prescribed
explicit metronome speed for playback, and why this would be preferable
to letting users set their own playback speeds `ad hoc', external to the
ABC representation, with the ABC-provided speed as a (reasonable) default.

Anselm
-- 
Anselm Lingnau .. [EMAIL PROTECTED]
Python is a truly wonderful language. When somebody comes up with a good idea
it takes about 1 minute and five lines to program something that almost does
what you want. Then it takes only an hour to extend the script to 300 lines,
after which it still does almost what you want.   -- Jack Jansen (1992)

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Frank Nordberg]

Laurie Griffiths wrote:
> 
> Jack, Frank (and other users) even if this isn't ideal, is it acceptable?

That's easy:

Acceptable:
Anything that lets me write abc to display any imaginable tempo
indication and play it back at a sensible speed.

Ideal:
Anything that lets me just write the tempo indication into the Q: field
and forget about it.


Frank Nordberg
http://www.musicaviva.com
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Simon Wascher]

Hello,

nearer to an optimum than before :o) 
( I know I should wait a moment and do it at once)

here, Separator ideas (the "-") and order ideas are integrated.


Syntax for Q field after a definition by Laurie Grifiths (with Lauries
use of the minus!)

(follows after the standard Q:field definition)

for setting the tempo, also textual tempo indicaters like "allegro" can
be defined for a whole or part of a file, outside the tune before the
tune header, or in an external macro file. 

Q:1/4=120 Allegro  % Outside any header, defines Allegro

The first tempo indicator that is identified in a Q:line will be used
for playback.

Example 
X:1
Q:andante

if "andante" is defined as textual tempo indicator it will be used for
playback, if not the default value is used, "andante" is displayed.

Example 
X:1
Q:andante n/n=n 

if "andante" is defined as textual tempo indicator it will be used for
playback, if not n/n=n is used for playback, the whole string is
displayed: "andante n/n=n".


Example
X:1
Q:n/n=n 

will playback n/n=n and display "n/n=n" 


Example 
X:1
Q:n/n=n andante 

will playback n/n=n and display "n/n=n andante"

Only numeral tempo indicators of the n/n=n format are supported in this
extended mode. Old versions of setting the tempo like Q:60 cannot be
expanded, so

Example:
X:1
Q:60  Andante 

will be displayed as: "60 Andante" if "Andante" is predefined as textual
tempo indicator playback will use this, if not the default tempo will be
used.

(Q:60 - Andante would work!)


The content of the Q: field is usually displayed by programs entirely
but may contain separated playback and display information. To allow
playback only information or some additive text for display, the
following expanded syntax can be used. 

In the following example parts of the Q: filed are not displayed:
A - (minus symbol) can be used to indicate that the part of the text
that comes before it is not displayed.

Example 
X:1
Q:n/n=n - andante 

will playback n/n=n and display "andante"

Example
X:1
Q:andante - gehend
if "andante" is defined as textual tempo indicator it will be used for
playback, otherwise "gehend" if defined, if not the default tempo is
used for playback. "gehend" is displayed 

If no tempo indicator should be displayed but a playback tempo set this
can be done using just the "-" after the  tempo indicator:

Example:
X:1
Q:n/n=n -

X:1
Q:andante -



regards,

Simon
Simon Wascher - Vienna, Austria
http://members.chello.at/simon.wascher/

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: what should be content of abc files, was: Re: [abcusers] something really simple

[Anselm Lingnau]

Simon Wascher <[EMAIL PROTECTED]> writes:

> It is not trivial to
> tell where music ends and side information beginns. And as a transcriber
> of historical sources it is often very important to cover some "side"
> information within the exchangeable file, not just in the printed output
> (for file exchange). This "non musical" information  does influence the
> musicans output and therefore is in a way part of the music.
> Abc formatting would be worthless to transcribers if it is limited to
> pure audible phaenonenons. 

Nobody says that ABC should be limited to `pure audible phenomena'. We
do have repeat signs and so on which are not audible (at least not in a
direct sense). However we should not try to define the meaning of the
ABC notation in terms of playback and notation programs, but in terms of
the musical ideas which are being transported. Saying in the standard
that various bits of such-and-such a field must be displayed in
such-and-such a way is a bad idea -- it is much better to say that the
field *means* this-and-so in musical terms and leave it to the software
authors to figure out what to do with that piece of information. This
means that the information is all there in the file for anybody to look
at it, but that the authors of ABC processing software have maximum
flexibility to make use of it (or not). There is absolutely no need to
clutter up an ABC tune with special notation that says whether `1/4=120'
must be printed with a little quarter note or `1/4' or not at all, or to
the top left or bottom right of the music or whatever, when it is a lot
easier to put options like `PrintMetronomeMarking: true' in an ABC
notation program's format file, or `--print-metronome-marking' on the
command line, or a check box in an interactive dialog or whatever.

As far as your `side information' is concerned that should only show up 
in the exchangeable file, not in the printed output: The ABC does 
provide the notion of `comments', i.e., lines that start with a `%'.

> I understand that you are not interested in these aspects of music
> notation, and I can tell you that I am working hard that you will never
> come accross those features you do not need, simply do not use them and
> never read the readme file description on those features. I am very much
> concerned that simple abc remains simple but in the same time please
> accept that other people do expand features you never heard of and never
> will use. 

Please don't second-guess me. I'm quite interested in seeing the ABC
standard develop and improve, thank you very much. However we should try
and avoid the mistakes that others have made, such as deliberately
mixing presentation and content, and we should try to keep the notation
as simple as possible. This is why I am in favour of Jack's proposal for
tempo macros, and also why I like Phil Taylor's macro mechanism for
decorations much more than the idea of inventing two hundred little
special symbols within the ABC language just so the urtext of Bach's
inventions can be represented in ABC. I am not prepared to accept the
idea that the ABC language needs to be cluttered up, say, with magical
end-of-line comments that have special meanings in some header fields
just so something can be expressed which nobody really actually needs to
begin with.

Anselm

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Simon Wascher]

Hello,

Laurie Griffiths wrote:
> 
> That would be acceptable.
> 
> Actually I proposed that instead of having to write it twice it would be
> done the other way.
> If the text of the displayed tempo is a single minus sign then it has the
> special meaning "display nothing"
> Q:1/4=80   %display "1/4=80" and use it for the player program too
> Q:1/4=80 -  %change the tempo on playback but display nothing here.
> Q:1/4=80 dreary  % display "dreary", use 1/4=80 for playback.


Oh , we can have it the other way round, if the minus sign has the
meaning: do not display whats before me.

like 
Q:1/4=80 - dreary % display only "dreary" and use 1/4=80 for playback.

If this is nearer to your idea of this I share it at once. Would make: 
(stated that the first identified active tempo indicator [numeral or
textual] applies)

Q:1/4=80   %display "1/4=80" and use it for the player program too
Q:1/4=80 -  %change the tempo on playback but display nothing here.
Q:1/4=80 dreary  % display "1/4=80 dreary", use 1/4=80 for playback.
Q:1/4=80 - dreary % display only "dreary" and use 1/4=80 for playback.

if textual tempo signs are defined (macros enabled):

Q:adagio   %display "adagio" and use it for the player program too
Q:adagio -  %change the tempo to adagio on playback but display nothing
here.
Q:adagio dreary  % display "adagio dreary", use adagio for playback.
Q:adagio - dreary % display only "dreary" and use adagio for playback.

if no textual tempo signs are defined (macros disabled),  
Q:adagio   %display "adagio" and use default for the player program
Q:adagio -  %use default on playback and display nothing here.
Q:adagio dreary  % display "adagio dreary", use default for playback.
Q:adagio - dreary % display only "dreary" and use default for playback.

makes for these examples:
Q:Allegro ma non troppo 1/4 = 120 %works, either allegro or 1/4=120 
Q: Like movement 1 (1/4=110) but slightly slower % will play 1/4=110
Q:Like the first 1/2 1/2=120 % works, will play 1/2=120
Q: Like the first 1/21/2=120 % will use default, is not clear in ascii
too
Q:Like the 1/4=120 part but a but in 6/8 time 3/8=120 %will play 1/4=120 
Q: Like the first 1/2 % will use default 
Q: Slow then getting quicker the first 1/2 about 80 but by the last 1/4 
about 140 %will use default

Q: Slow then quicker, 1st 1/2 = 80, last 1/4 = 140 % will use 1/2=80
this is something  new: a changing tempo. Wonder which player could
handle this. Maybe we can start a new topic on this :o) .

Q: Parts A and B =120, C=140 % will use default

Simon


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

[Simon Wascher]

Hello,

here some sugestions which are, I belive quite near to an optimum.

Syntax for Q field after a definition by Laurie Grifiths.

(after standard Q:field definition)

for setting the tempo, also textual tempo indicarters like "allegro" can
be specified in an external macro file or can be defined for the whole
or part of a file, outside the tune, bevore the tune header.
Q:1/4=120 Allegro  % Outside any header, defines Allegro


The content of the Q: field is usually displayed by programs entirely
but may contain separated playback and display information. To allow
playback only information or some additive text for display, the
following expanded syntax can be used. 
The first tempo indicator that is defined will be used for playback.

Example 
X:1
Q:andante

if "andante" is defined as textual tempo indicator it will be used for
playback, if not the default value is used, "andante" is displayed.

Example 
X:1
Q:andante n/n=n 

if "andante" is defined as textual tempo indicator it will be used for
playback, if not n/n=n is used for playback, the whole string is
displayed: "andante n/n=n".


Example
X:1
Q:n/n=n 

will playback n/n=n and display "n/n=n" 

In the following example the playback temo is not displayed: If a
numeral tempo indicator follows directly after the Q: it will not be
displayed if it is followed by other characters

Example 
X:1
Q:n/n=n andante 

will playback n/n=n and display "andante", similar

Example 
X:1
Q:n/n=n N/N=N andante 

will playback n/n=n and display N/N=N andante

so if a numeral tempo indicator is on the very beginning of such a
string it must be written a second time for the display.

If no tempo indicator should be displayed but a playback tempo set this
can be done using a "-" after the numeral tempo indicator.

Example:
X:1
Q:n/n=n -

Old versions of setting the tempo like Q:60 cannot be expanded, so

Example:
X:1
Q:60  Andante 
will be displayed as: "60 Andante" if "Andante" is predefined as textual
tempo indicator playback will use this, if not the default tempo will be
used.



regards,

Simon
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

[Laurie Griffiths]

That would be acceptable.

Actually I proposed that instead of having to write it twice it would be
done the other way.
If the text of the displayed tempo is a single minus sign then it has the
special meaning "display nothing"
Q:1/4=80   %display "1/4=80" and use it for the player program too
Q:1/4=80 -  %change the tempo on playback but display nothing here.
Q:1/4=80 dreary  % display "dreary", use 1/4=80 for playback.

I would also be quite happy with a SEPARATOR (I prefer the word delimiter)
e.g.
Q:1/4=80   %display that and use it for the player program too
Q:1/4=80:  %change the tempo on playback but display nothing here.
Q:1/4=80: dreary  % display "dreary", use 1/4=80 for playback.
and I'd be happy with pretty much any character as delimiter EXCEPT
/ (because it occurs in the tempo string and could cause confusion)
= (same reason)
  [space] because it is likely to be found in the tempo string
% (because it already has a legal meaning as start-of-comment)

Jack, Frank (and other users) even if this isn't ideal, is it acceptable?
Other programmers - is this as easy to implement as it seems to me?

Laurie
- Original Message -
From: Simon Wascher <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 12, 2001 1:49 PM
Subject: Re: [abcusers] something really simple


Hello Laurie,

I think maybe now we got it:

The golden rule could be:

If there is a n/n=n string right after the colon this will not be
printed if it is followed by any other character.
everething else is printed entirely.

this restricts "playback only" fields to n/n=n what is acceptable, and
implicates that in one certain case a part of the time string has to be
writen twice:
Q:n/n=n n/n=n (+ text ad libidum) %(important: the space after Q:n/n=n),
displaying: n/n=n (+ text ad libidum)

Simon :-)

Laurie Griffiths wrote:
>
> I think that I am now in favour of syntax that allows this:
> Any lines containing % are meta-comments meaning that they are just me
> talking to you about the example and would not be part of the example -
> though I guess they'd be legal as comments anyway
>
> Q:1/4=120 Allegro  % Outside any header. Defines Allegro.  No display,
just
> remember .
> Q:3/8=160 Running % Defines Running
>
> X:12
> Q:Allegro %Display Allegro, play at 1/4=120
>
> X:13
> Q:3/8=100 % display either 3/8=100 or preferably  symbol>=100
>
> Q:Allegro ma non troppo %Display that lot. Play at default rate since
there
> is nothing recognisable for a player program to use
>
> Q:Alegro % Same again.  Spelling errors are not tolerated!
>
> Q: Allegro  % but the odd space is OK, play 1/4=120
>
> Q: running % and so is change of case.  Play 3/8=160
>
> Q: 3/8=100 - % Special case.  A single minus sign means "no display"
>
> Q:1/4=110Andante % Two points here.  Firstly no SEPARATOR character is
> required.  Secondly if this is between X: (or T: with a missing X:  ???)
and
> the next blank line then it does NOT define Andante for future use, it
just
> prints it.  Any command EITHER defines a symbol OR causes an action, not
> both.  Outside a header/tune it defines, inside it causes action.  In this
> case the action is to set the speed to 1/1=110 and print Andante.
>
> Q:60 Andante %SYNTAX ERROR! Only the preferred form of the tempo
syntax
> may be used with the new extensions.  Deprecated old versions must be
> complained about.
>
> Q: Allegro 1/4=120 % Display that lot, play at default rate.  Numbers come
> first.
>
> That last one is probably the most objectionable but I don't see any easy
> line between that and Jack's "pull the tempo string out from wherever you
> find it".  It's an implementor's can of worms and worse - if some
programmer
> did hack up something that sort of works for some cases it would be a
> blasted nightmare.
>
> Formal syntax can be cooked up easily, but i'm not sure it will aid
> discussion at this stage.
> PRO: Allows definition and later use (this has its pros and cons but it
> seems to be part of abc, even though I personally don't like it)
> PRO: Not too hard to implement
> PRO: Allows printable version only, allows display version only, allows
> both.
> CON: More restrictive that Jack's idea
>
> In order to make progress - I feel that we need an "Approval voting"
scheme.
> English spelling has never been reformed because although many people
agree
> that the current version is stupid they can't agree on which of many
> alternatives to go with, even though almost any of them would be a great
> improvement.  So if you reckon that a particular scheme is ACCEPTABLE,
even
> though you might PREFER a different scheme, (whether slightly different or
> very differ

Re: [abcusers] something really simple

[Laurie Griffiths]

In these examples it is easy to extract the tempo - but only because the
non-tempo part has been restricted to a single word followed by a space.  I
can scan for a space in lots of simple ways (I gave two in an earlier mail).
What can not be done so easily is to extract a tempo string from somewhere
in a line of text that may or may not actually contain one. e.g.
Q:Allegro ma non troppo 1/4 = 120
Q: Like movement 1 (1/4=110) but slightly slower
Q:Like the first 1/2 1/2=120
Q: Like the first 1/21/2=120
Q:Like the 1/4=120 part but a but in 6/8 time 3/8=120
Q: Like the first 1/2
Q: Slow then getting quicker the first 1/2 about 80 but by the last 1/4
about 140
Q: Slow then quicker, 1st 1/2 = 80, last 1/4 = 140
Q: Parts A and B =120, C=140
and so on and so on.

The reason I proposed having the formal bit first and the free format bit
last was to eliminate the problem of having to parse inside the free format
stuff.  Instead we can just scan for line-end.

Incidentally I do still do the odd magic trick.  Making a pack of cards all
(seem to) change colour is one of my favourites.  :-)

Laurie
- Original Message -
From: Frank Nordberg <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 12, 2001 11:58 AM
Subject: Re: [abcusers] something really simple


> Simon Wascher wrote:
> >
> > my *exemplary* proposal for a separator was not % but %%display or
> > %display (the second can be ruled out by reason of keeping the standards
> > syntax stringent).
>
> OK, now have a look at this:
>
> Example 1
> Displayed tempo: Allegro 1/4=120
> Playback tempo:  1/4=120
>
> Q:Allegro 1/4=120
> or:
> Q:1/4=120 %%display Allegro 1/4=120
>
> ---
>
> Example 2
> Displayed tempo: Allegro
> Playback tempo:  1/4=120
>
> Q:Allegro [1/4=120]
> or:
> Q:1/4=120 %%display Allegro
>
> 
>
> Example 3
> Displayed tempo: Allegro
> Playback tempo:  determined by an external definition of "Allegro"
>
> Q:Allegro
> or:
> Q:Allegro %%display Allegro
>
> ---
>
> Now, tell me exactly ow much more difficult it would be for a playback
> program to interpret the first alternative (the one without the
> "%%display").
> Remember that the first alternative has a few minor advantages:
>*It's more human-readable.
>*It's easier to understand for a non-programmer.
>*It'll require a shorter text string - sometimes far shorter.
>*It retains the connection between displayed and played tempo.
>*It is completely backwards compatible on file level, that is
> files that are written according to the old abc standard are
> played and displayed exactly the same way they as they were.
>
> I know I sometimes expect too much from the programmers. Like so many
> non-programmers I tend to view them as some kind of magicians always
> ready to pull a handful of miracles out of their sleeve.
> If you tell me you can't do it this time, I guess I just have to accept
> that. But at least give it a serious try!
>
> Please!  :-)
>
>
> Frank Nordberg
> http://www.musicaviva.com
>
>
> 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

what should be content of abc files, was: Re: [abcusers] something really simple

[Simon Wascher]

Hello,

Anselm Lingnau wrote:
> This is purely a presentation issue and does not pertain to the actual
> ABC standard, which should describe the contents of ABC files.

It is simply not true that the abc standard does not contain
presentation issues. Even the question which clef to use is purely
optical and does not change one bit of the "music". It is not trivial to
tell where music ends and side information beginns. And as a transcriber
of historical sources it is often very important to cover some "side"
information within the exchangeable file, not just in the printed output
(for file exchange). This "non musical" information  does influence the
musicans output and therefore is in a way part of the music.
Abc formatting would be worthless to transcribers if it is limited to
pure audible phaenonenons. 

I understand that you are not interested in these aspects of music
notation, and I can tell you that I am working hard that you will never
come accross those features you do not need, simply do not use them and
never read the readme file description on those features. I am very much
concerned that simple abc remains simple but in the same time please
accept that other people do expand features you never heard of and never
will use. 

simon

-- 
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

[James Allwright]

On Mon 12 Nov 2001 at 12:58PM +0100, Frank Nordberg wrote:
> 
> I know I sometimes expect too much from the programmers. Like so many
> non-programmers I tend to view them as some kind of magicians always
> ready to pull a handful of miracles out of their sleeve.
> If you tell me you can't do it this time, I guess I just have to accept
> that. But at least give it a serious try!
> 
> Please!  :-)
> 

What programmers cannot do is re-write applications retrospectively.
Adding new syntax that is incompatible with the old syntax causes
hassles for everyone who uses abc. That is why it important for new
ideas to make use of existing syntax and be added in harmoniously
if at all possible. Rather than propose specific syntax, maybe you
need to be saying "I'd like this new feature, what syntax do we need
to support it?" . 


James Allwright
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Simon Wascher]

Hello Laurie,

I think maybe now we got it:

The golden rule could be: 

If there is a n/n=n string right after the colon this will not be
printed if it is followed by any other character. 
everething else is printed entirely. 

this restricts "playback only" fields to n/n=n what is acceptable, and
implicates that in one certain case a part of the time string has to be
writen twice: 
Q:n/n=n n/n=n (+ text ad libidum) %(important: the space after Q:n/n=n),
displaying: n/n=n (+ text ad libidum) 

Simon :-)

Laurie Griffiths wrote:
> 
> I think that I am now in favour of syntax that allows this:
> Any lines containing % are meta-comments meaning that they are just me
> talking to you about the example and would not be part of the example -
> though I guess they'd be legal as comments anyway
> 
> Q:1/4=120 Allegro  % Outside any header. Defines Allegro.  No display, just
> remember .
> Q:3/8=160 Running % Defines Running
> 
> X:12
> Q:Allegro %Display Allegro, play at 1/4=120
> 
> X:13
> Q:3/8=100 % display either 3/8=100 or preferably  symbol>=100
> 
> Q:Allegro ma non troppo %Display that lot. Play at default rate since there
> is nothing recognisable for a player program to use
> 
> Q:Alegro % Same again.  Spelling errors are not tolerated!
> 
> Q: Allegro  % but the odd space is OK, play 1/4=120
> 
> Q: running % and so is change of case.  Play 3/8=160
> 
> Q: 3/8=100 - % Special case.  A single minus sign means "no display"
> 
> Q:1/4=110Andante % Two points here.  Firstly no SEPARATOR character is
> required.  Secondly if this is between X: (or T: with a missing X:  ???) and
> the next blank line then it does NOT define Andante for future use, it just
> prints it.  Any command EITHER defines a symbol OR causes an action, not
> both.  Outside a header/tune it defines, inside it causes action.  In this
> case the action is to set the speed to 1/1=110 and print Andante.
> 
> Q:60 Andante %SYNTAX ERROR! Only the preferred form of the tempo syntax
> may be used with the new extensions.  Deprecated old versions must be
> complained about.
> 
> Q: Allegro 1/4=120 % Display that lot, play at default rate.  Numbers come
> first.
> 
> That last one is probably the most objectionable but I don't see any easy
> line between that and Jack's "pull the tempo string out from wherever you
> find it".  It's an implementor's can of worms and worse - if some programmer
> did hack up something that sort of works for some cases it would be a
> blasted nightmare.
> 
> Formal syntax can be cooked up easily, but i'm not sure it will aid
> discussion at this stage.
> PRO: Allows definition and later use (this has its pros and cons but it
> seems to be part of abc, even though I personally don't like it)
> PRO: Not too hard to implement
> PRO: Allows printable version only, allows display version only, allows
> both.
> CON: More restrictive that Jack's idea
> 
> In order to make progress - I feel that we need an "Approval voting" scheme.
> English spelling has never been reformed because although many people agree
> that the current version is stupid they can't agree on which of many
> alternatives to go with, even though almost any of them would be a great
> improvement.  So if you reckon that a particular scheme is ACCEPTABLE, even
> though you might PREFER a different scheme, (whether slightly different or
> very different), please ...
> 
> SAY WHEN YOU FEEL A SCHEME IS ACCEPTABLE whether or not it is ideal.  We
> have to start collecting YES votes if we are going to go forward.
> Unconstrained discussion tends to look like NO votes.
> 
> For instance if you feel that it would be better with £ as a delimiter (that
> was an English pound sign) then if you merely say that, then it looks like
> you are arguing and not agreeing.  If you actually feel that any delimiter
> or no delimiter is acceptable, but you have a preference for £ then make
> sure you say that.  At the risk of repeating myself: We have to start
> getting YES votes to go forwards.
> 
> Laurie
> 
> 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 really simple

[Anselm Lingnau]

Simon Wascher <[EMAIL PROTECTED]> writes:

> there are several reasons for this, most important to me is the
> transcribers request that information given in the source is passed on
> in the abc file.

I don't see the problem there. You put in your `Q:' header whatever the 
original source said. If you want metronome markings as well as a 
verbose tempo specification then say

  Q:Allegro 1/4=120
  Q:Allegro "Pretty quickly"

and use a notation program that will let you propagate the actual 
numerical definition of a macro like `Allegro' into the typeset output, 
so you get something along the lines of

  Allegro (Pretty quickly) - .|=120

This is purely a presentation issue and does not pertain to the actual
ABC standard, which should describe the contents of ABC files.
 
> included in the topic is the separated proposal to allow program active
> textual tempo markers by the use of macros, maybe we can excluse this
> from the actual discussion since it seems to be quite common sense and
> does not directly touch the playback/display problem.

I disagree. This is where the discussion started, and I think Jack's 
proposal is eminently sensible. A `solution' that ignores this original 
issue is not a solution at all.
 
> the core problem is the impossibility of playback only (B) in the actual
> standard.

Playback-only tempo is something that you set in a player program, no?

> the second the impossibility to have display only (C) in a way that the
> text in question is identified as tempo indication (relys on B) too !)

A tempo indication, by current definition, is whatever is in the `Q:'
field. Whether this is for display or playback or both depends on what 
the programs that look at the ABC make of it.

> the third the desire to have both in one (D), and this in a intuitive
> clear syntax.

That is exactly what I have suggested.

> There is no way passing the fact that displayed and playback tempo
> indicaters are two totally different (but related) topics that both
> should be covered by abc. 

I don't buy this. A composer comes up with a tune and suggests a speed
at which it should be played. This is what he puts on his manuscript. So
where do you (the transcriber) come in to say `no, what it says there is
wrong, this piece must be played at 2/3 the speed and the ABC file that
I will give out to everybody must say so'. This will only serve to
confuse people who listen to the ABC file as played at `playback tempo'
by an ABC player while looking at the sheet music as output by an ABC
notation program giving the `display tempo'.

There is nothing wrong with having a tempo associated with a metronome
number using Jack's proposal as well as an explanatory note in the 
manner that I suggested. What I think is unnecessary is having two 
conflicting metronome numbers within the same ABC tune. This is 
something which is much better handled using Jack's macros and/or a 
player program that will let you override the actual speed from outside 
of the ABC-notated tune to be played.

> Leaving the display matters to the display programs alone as you sugest
> sounds intriguing and covers B) but failes to handle C) and D).
> The "q:" solution (extra field for displayed tempo indicaters) covers
> the identification of "display only tempo indicaters" (C) and with the
> support of an "not display Q: option" in the displaying programs that
> you sugested all possibilities could be handled. The SEPARATOR in this
> solution is a "d:" field plus an optional feature in the displaying
> programs. 
> I do not like this solution much since it relies on program options
> which are not part of the standards syntax and its very likely that this
> causes misunderstandings by users, but for my purposes this would work
> if its covered by abc2ps.

This is a mess. I don't like the idea of specifying in the ABC standard 
what programs should do with the information in an ABC tune. The ABC 
standard should explain what the various bits and pieces in the 
notation *mean* -- in musical terms -- but not how programs should make 
use of that information. For example, IMHO it is OK to say

  The `Q:' field indicates the speed of the subsequent material, either
  by a metronome reference such as `1/4=120' or by a reference to a
  previously defined macro such as `Allegro'.

(of course this is not detailed enough to be an actual specification)
but not

  The `Q:' field indicates the speed of the subsequent material, and
  its contents should be printed at the top left of the first staff,
  with a note of the appropriate value to the left of the equals sign
  and the numerical tempo specification to the right.

These details should be left to notation programs in the same vein that
ABC right now doesn't specify, e.g., the widths of the margins, the font
and size of the tune title and so on. Similarly, player programs should
use the contents of the `Q:' field as a default speed but allow the user
to override this in the same manner that notation

Re: [abcusers] something really simple

[Frank Nordberg]

Simon Wascher wrote:
> 
> my *exemplary* proposal for a separator was not % but %%display or
> %display (the second can be ruled out by reason of keeping the standards
> syntax stringent).

OK, now have a look at this:

Example 1
Displayed tempo: Allegro 1/4=120
Playback tempo:  1/4=120

Q:Allegro 1/4=120
or:
Q:1/4=120 %%display Allegro 1/4=120

---

Example 2
Displayed tempo: Allegro
Playback tempo:  1/4=120

Q:Allegro [1/4=120]
or:
Q:1/4=120 %%display Allegro



Example 3
Displayed tempo: Allegro
Playback tempo:  determined by an external definition of "Allegro"

Q:Allegro
or:
Q:Allegro %%display Allegro

---

Now, tell me exactly ow much more difficult it would be for a playback
program to interpret the first alternative (the one without the
"%%display"). 
Remember that the first alternative has a few minor advantages:
   *It's more human-readable.
   *It's easier to understand for a non-programmer.
   *It'll require a shorter text string - sometimes far shorter.
   *It retains the connection between displayed and played tempo.
   *It is completely backwards compatible on file level, that is
files that are written according to the old abc standard are
played and displayed exactly the same way they as they were.

I know I sometimes expect too much from the programmers. Like so many
non-programmers I tend to view them as some kind of magicians always
ready to pull a handful of miracles out of their sleeve.
If you tell me you can't do it this time, I guess I just have to accept
that. But at least give it a serious try!

Please!  :-)


Frank Nordberg
http://www.musicaviva.com


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laurie Griffiths]

I think that I am now in favour of syntax that allows this:
Any lines containing % are meta-comments meaning that they are just me
talking to you about the example and would not be part of the example -
though I guess they'd be legal as comments anyway

Q:1/4=120 Allegro  % Outside any header. Defines Allegro.  No display, just
remember .
Q:3/8=160 Running % Defines Running

X:12
Q:Allegro %Display Allegro, play at 1/4=120

X:13
Q:3/8=100 % display either 3/8=100 or preferably =100

Q:Allegro ma non troppo %Display that lot. Play at default rate since there
is nothing recognisable for a player program to use

Q:Alegro % Same again.  Spelling errors are not tolerated!

Q: Allegro  % but the odd space is OK, play 1/4=120

Q: running % and so is change of case.  Play 3/8=160

Q: 3/8=100 - % Special case.  A single minus sign means "no display"

Q:1/4=110Andante % Two points here.  Firstly no SEPARATOR character is
required.  Secondly if this is between X: (or T: with a missing X:  ???) and
the next blank line then it does NOT define Andante for future use, it just
prints it.  Any command EITHER defines a symbol OR causes an action, not
both.  Outside a header/tune it defines, inside it causes action.  In this
case the action is to set the speed to 1/1=110 and print Andante.

Q:60 Andante %SYNTAX ERROR! Only the preferred form of the tempo syntax
may be used with the new extensions.  Deprecated old versions must be
complained about.

Q: Allegro 1/4=120 % Display that lot, play at default rate.  Numbers come
first.

That last one is probably the most objectionable but I don't see any easy
line between that and Jack's "pull the tempo string out from wherever you
find it".  It's an implementor's can of worms and worse - if some programmer
did hack up something that sort of works for some cases it would be a
blasted nightmare.

Formal syntax can be cooked up easily, but i'm not sure it will aid
discussion at this stage.
PRO: Allows definition and later use (this has its pros and cons but it
seems to be part of abc, even though I personally don't like it)
PRO: Not too hard to implement
PRO: Allows printable version only, allows display version only, allows
both.
CON: More restrictive that Jack's idea

In order to make progress - I feel that we need an "Approval voting" scheme.
English spelling has never been reformed because although many people agree
that the current version is stupid they can't agree on which of many
alternatives to go with, even though almost any of them would be a great
improvement.  So if you reckon that a particular scheme is ACCEPTABLE, even
though you might PREFER a different scheme, (whether slightly different or
very different), please ...

SAY WHEN YOU FEEL A SCHEME IS ACCEPTABLE whether or not it is ideal.  We
have to start collecting YES votes if we are going to go forward.
Unconstrained discussion tends to look like NO votes.

For instance if you feel that it would be better with £ as a delimiter (that
was an English pound sign) then if you merely say that, then it looks like
you are arguing and not agreeing.  If you actually feel that any delimiter
or no delimiter is acceptable, but you have a preference for £ then make
sure you say that.  At the risk of repeating myself: We have to start
getting YES votes to go forwards.

Laurie

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Simon Wascher]

Hello Anselm,

Anselm Lingnau wrote:
>   Q:Allegro "Pretty quick"
> Thus, a notation program could display something along the lines of
>   Allegro (Pretty quick)

the problem is that the tempo information may be a compilation of
information for

A) playback and display  (that is the acctual standard)
B) playback only (not possible in the acctual standard)
C) display only (only possible as a really unsatifying hack in the
actual standard)
D) a chunk for display(only) and a chunk for playback(only) (not
possible in the acctual standard)

there are several reasons for this, most important to me is the
transcribers request that information given in the source is passed on
in the abc file.

included in the topic is the separated proposal to allow program active
textual tempo markers by the use of macros, maybe we can excluse this
from the actual discussion since it seems to be quite common sense and
does not directly touch the playback/display problem.

the core problem is the impossibility of playback only (B) in the actual
standard.

the second the impossibility to have display only (C) in a way that the
text in question is identified as tempo indication (relys on B) too !)

the third the desire to have both in one (D), and this in a intuitive
clear syntax.

There is no way passing the fact that displayed and playback tempo
indicaters are two totally different (but related) topics that both
should be covered by abc. 

Leaving the display matters to the display programs alone as you sugest
sounds intriguing and covers B) but failes to handle C) and D).
The "q:" solution (extra field for displayed tempo indicaters) covers
the identification of "display only tempo indicaters" (C) and with the
support of an "not display Q: option" in the displaying programs that
you sugested all possibilities could be handled. The SEPARATOR in this
solution is a "d:" field plus an optional feature in the displaying
programs. 
I do not like this solution much since it relies on program options
which are not part of the standards syntax and its very likely that this
causes misunderstandings by users, but for my purposes this would work
if its covered by abc2ps.

I would prefer a syntax that recognises whether Q: field info is for
display and playback or just for playback. If so, I belive the just for
display information *could* also be recongnised and be included here. If
not it can be put into a "q:" field.

>   Q:Allegro "Pretty quick"
>   C:[Traditional]

I would prefer not to use quotes as Separators as they are very common
characters and cant see why they are better than square brackrets.

> under the stipulation that a tune would not have a `display speed' 
> of 1/4=90 and a `playback speed' of 1/4=120,

Its likely that exactly this is desired: One metronome number comes with
the source and another is used for actuall playback.


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

[Simon Wascher]

Hello,

Phil Taylor wrote:
> Frank Nordberg wrote:
> >Oh, I think that is settled already. One of Simon's arguments was
> >compatibility with older applications, and the only character that would
> >work for that is %.
> 
> No!  % alone indicates that the rest of the string should be ignored.
> Use a two character string starting with % if necessary, otherwise
> there's no way to put a comment in a tempo field.


my *exemplary* proposal for a separator was not % but %%display or
%display (the second can be ruled out by reason of keeping the standards
syntax stringent).

Simon

-- 
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

[Frank Nordberg]

[EMAIL PROTECTED] wrote:
> 
> It might not be safe to assume that MIDI is the only way playback can/will
> occur.

Well, yes and no. A non-midi ABC player application should be able to
interpret ABC playback commands even though they are named "MIDI", but I
can agree the phrasing might be a bit confusing. How about %%PLAY (as
Laurie suggested) instead?
Provided we want to use the %% syntax in the ABC standard at all, of
course. There are two other rather obvious alternatives, either to
introduce a special "playback-only" header field (q: would be the
obvious choice) or to include the playback-only tempo indications in the
Q: field but with some kind of marker that tells a display program not
to show this e.g.:
Q:Allegro %%1/4=128
or:
Q:Allegro [1/4=128]
---
Laurie Griffiths wrote:
> 
> I thought that %%MIDI meant stuff for abc2midi.

You're right. But there isn't *necessarily* anything wrong in
integrating features from a specific program into the standard. I don't
think this would be the first time it happened.

That being said, I do feel a bit wary about introducing %% commands to
the standard. The syntax is just such a wonderful way for programmers to
incorporate their own specialities without being in danger of creating
tunes unreadable by other applications.
---
Laura Conrad wrote:
> 
> The point is that you might want to specify a tempo for a MIDI player,
> but not print it for a human player.

In other words: even if you trust a human musician to be able to pick a
sensible tempo for the tune him-/herself, you don't necessarily trust a
computer to do so.

> 
> Or to specify a tempo in quarter notes per minute for a MIDI player
> but with a word like "allegro" for the human.

I thought *that* was supposed to be a separate issue here. OTOH this
might be a nice shortcut around lots of parsing problems and complex
encoding. You simply put anything you like for a human to read in the Q:
field and then allows another separate code to aid a poor computer who
has never learned the difference between presto and pesto.


Frank Nordberg
http://www.musicaviva.com

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Jack Campin]

> The point is that you might want to specify a tempo for a MIDI player,
> but not print it for a human player.
> Or to specify a tempo in quarter notes per minute for a MIDI player
> but with a word like "allegro" for the human.

That's exactly my motivation for wanting this added to BarFly, but
BarFly uses QuickTime as its usual playback mechanism - MIDI is
supported as an export format, but the program itself doesn't play
MIDIs.

This make a difference for pipe tunes - the MIDI-exported versions
don't have the continuous drone that BarFly can add to them, as MIDI
can't represent a note that long while QuickTime can.

If we are going to have this sort of environment-specific control,
wouldn't it better to layer it into three levels, so that at the top
level you had a distinction between sound, graphic and database-
related aspects, at a lower level distinctions between the file formats
involved (MIDI, AIFF, QT, GIF, EPS, PDF, BibTeX, SYLK...) and at the
lowest level distinctions between specific programs?

But there's no reason why a sound-generating program couldn't make
sense of "allegro", via an external table of tempi or the syntax
I suggested, so there's no need to go down that road for this issue.

===  ===


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laura Conrad]

> "Laurie" == Laurie Griffiths <[EMAIL PROTECTED]> writes:

Laurie> I'm not sure if I buy it anyway.  Why would one want to have a 
playback-only
Laurie> field that did not apply to a human player too?  Perhaps an example would
Laurie> clarify?

The point is that you might want to specify a tempo for a MIDI player,
but not print it for a human player.

Or to specify a tempo in quarter notes per minute for a MIDI player
but with a word like "allegro" for the human.


-- 
Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ )
(617) 661-8097  fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] something really simple

[Laurie Griffiths]

I thought that %%MIDI meant stuff for abc2midi.
If %%MIDI means stuff which all programs which convert ABC to MIDI must
interpret then sort of OK, but this is not MIDI specific.  If it was
converted to WAV or MP3 it would still apply, so %%PLAY would be better.

I'm not sure if I buy it anyway.  Why would one want to have a playback-only
field that did not apply to a human player too?  Perhaps an example would
clarify?

Laurie

- Original Message -
From: Laura Conrad <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 03, 2001 2:20 PM
Subject: Re: [abcusers] something really simple


>>>>> "Frank" == Frank Nordberg <[EMAIL PROTECTED]> writes:

Frank>+We'll probably need a way to define playback-only Q: fields
Frank> as well. It's tempting to use the old style "number only"
Frank> syntax for that, but I'm not sure if that's a good idea.

If it's playback only, wouldn't it make sense to put it in a %%MIDI line?


--
Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ )
(617) 661-8097 fax: (801) 365-6574
233 Broadway, Cambridge, MA 02139
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 really simple

[jhoerr]

On 3 Nov 2001, Laura Conrad wrote:

> If it's playback only, wouldn't it make sense to put it in a %%MIDI
> line?

It might not be safe to assume that MIDI is the only way playback can/will
occur.

John

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html