date:20011112


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


On Sat 10 Nov 2001 at 06:39PM +0100, Frank Nordberg wrote:
 
 
 Jack Campin wrote:
  
   The solution is to put everything inside a single pair of quotes with
   spaces between the individual chord symbols, such as:
  
   CCDEF|CE2 Dm7  G7D2|C F CC4|]
  
  How is a player program supposed to know how to time those chords?
 
 As far as I know, no playback program is able to interpret this at all.
 Multiple chord symbols on a single note is certainly yet another issue
 that could be adressed in a future version of the standard.

You can do multiple chord symbols already in yaps with e.g.

Dm7 G D2

The current standard implies that this is how it should be done.

James Allwright

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

Re: [abcusers] Special characters in PostScript


On Fri 09 Nov 2001 at 11:18AM -0600, Taral wrote:
 On Fri, Nov 09, 2001 at 09:47:25AM +, James Allwright wrote:
  
  Well, no-one has requested this, but I thought I'd post it all
  the same. This is my little bit of PostScript to insert sharp
  and flat symbols in a text string. It works, but the new
  symbols look out of place.
  
 
 I recommend using a font instead of this... the rendering engine is far
 better about making things look 'in place'. Also, overriding '#' and 'b'
 especially seems to be kind of over-the-top... better to create new
 symbols /sharp and /flat and let the user create appropriate encodings.
 
 If necessary, I'll code it up for anyone who wants.

Yes please, I'd like to see how this approach works. There are no sharp and
flat characters in the standard character sets for PostScript, so
you need to get your own glyphs in there somehow.

James Allwright


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

Re: [abcusers] blasphemy! A separate project...?


Hello Guido,

Guido Gonzato wrote:
 Let me tell you the dark side of my ABC point of view: ABC is _very_ nice,
 but is _way_ too limited. It was designed with too little goals in mind. As
 a real-world musician, I want to tweak current ABC so that it can do my
 choral scores reasonably well. As a computer guy, I already have a new
 syntax ready that just waits to be put down on paper...
 
 I let you guess the reasons why I didn't put it down on paper. But if you're
 interested, wave your hand at me.

I also see the sometimes hurting limits of the abc standard as it is.
the problem is that there is a real big pile of content that uses the
actuall standard. I looked into my files, and found that the abc files I
transcribed are a pile of about 3 MB (plain ASCII). Assuming that other
peoples who are listed as large collections at the abc homepage also
have big collections besides what is in the net right now we are talking
of at least 60 MB of content (another approximation is to multiply the
14000 titles of the www abc index with an single tune size of about 20KB
makes 280.000 KB ).

So if an entirely new syntax appears how will this syntax interprete
this pile ? what are your solutions?
will you write an all plattform automatic conversion tool and is it sure
that no part of thecontent gets lost in this process? 

I am honestly interested and my questions are not cynical. But there are
serious problems that would be created by a new standard. 


Simon Wascher - Vienna, Austria

PS: this big pile of content is why I belive that bachkwards
compatability in files overrules backwards comatability in programs.

http://members.chello.at/simon.wascher/

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

Re: [abcusers] developing the standard ......

2001-11-12 Thread Bryancreer

Anselm Lingnau said -

Nothing should go in the
standard unless it has been proved that it is actually implementable
with reasonable effort. This may mean that sooner or later one might hit
a dead end with some feature or other, but it will be much harder to get
the standard fixed if the feature in question is already part of it,
than to get the feature fixed *before* it goes into the standard. Of
course if implementors insist that once they have implemented something
then it must absolutely stay the way it is, then this approach doesn't
work. However I think there is merit in trying things on a strictly
experimental basis without encouraging users to base their multimegabyte
ABC archives on those particular features that are being tested.

There is no "sooner or later" or about it. This is what is already happening. A notable example being the V: command. There is a sort of Catch 22 which says "Well I have to try it out to see if it works" followed by "I've put all that work into it and my users like it so I'm not taking it out now."

I don't think we can stop developers innovating but can we get them to at least keep everybody else informed and modify what they are doing if there is a clash?

Phil Taylor recently said -

Before you start work, download BarFly, MUSE, Melody Assistant
and all the other programs which you don't normally use. Read
the documentation and use the programs until you know what they
are capable of.

The wrong way round I feel. Surely it is the responsibility of developers to keep the rest of the community informed of their innovations; not just just in their own documentation but in some central easily accessible place.

Bryan Creer

Re: [abcusers] something really simple


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

Re: [abcusers] blasphemy! A separate project...?

2001-11-12 Thread Bryancreer

Guido Gonzato said -

As a computer guy, I already have a new
syntax ready that just waits to be put down on paper...

I let you guess the reasons why I didn't put it down on paper. But if you're
interested, wave your hand at me.

Might be a good idea Guido. It would take the pressure of a simple system that is already groaning at the seams trying to cope with everything everybody is throwing at it. I was toying with the idea of going the opposite way and coming up with a definition for abc lite or perhaps acbxp (exchange protocol) based solely on the principle of exchanging relatively simple musical and documentary information regardless of the use to which it would be put. Anybody interested?

Bryan Creer

Re: [abcusers] developing the standard was:Re: [abcusers] (Attention please) - starting the new ABC draft

2001-11-12 Thread Frank Nordberg




Anselm Lingnau wrote:
 
 [EMAIL PROTECTED] (Phil Taylor) writes:
 
  One thing I might suggest though.  If we do get a new draft standard
  out of this, please developers DON'T WRITE A LINE OF CODE UNTIL
  A VOTE HAS BEEN TAKEN AND THE STANDARD BECOMES OFFICIAL.  Writing
  code sets the mistakes in stone; we have to be sure that there are
  no serious mistakes in what is proposed, and if that requires very
  prolonged discussion so be it.
 
 Actually I think this is the wrong way round. Nothing should go in the
 standard unless it has been proved that it is actually implementable
 with reasonable effort.

You must always begin with the idea of an ideal world, Anselm!
I'd say the best way of working would be: first we find out exactly what
we really want, then we see if it's actually possible and make the
modifications required by reality (that is the limitations of
programming languages), *then* we drag out the stone tablets and write
it down for eternity.

Frank Nordberg
http://www.musicaviva.com


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

Re: [abcusers] blasphemy! A separate project...?

2001-11-12 Thread Frank Nordberg


Guido Gonzato wrote:
 
 As a computer guy, I already have a new
 syntax ready that just waits to be put down on paper...

Does anybody have any idea how many ascii based music notation formats
there are?
I mean if we're talking about a brand new standard, we ought to have a
look at the full picture, not just abc.

Simon Wascher wrote:
 
 (another approximation is to multiply the
 14000 titles of the www abc index with an single tune size of about 20KB
 makes 280.000 KB ).

Actually the www abc index is too outdated to be of much value here. I
know of individual sites with more than 14 000 tunes each. It's hard to
estimate the total number of abc tunes out on the web, but it's
certainly more than 50 000 and probably far more than 100 000.

Frank Nordberg
http://www.musicaviva.com


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

Re: [abcusers] blasphemy! A separate project...?


Simon Wascher [EMAIL PROTECTED] writes:

 I looked into my files, and found that the abc files I
 transcribed are a pile of about 3 MB (plain ASCII). Assuming that other
 peoples who are listed as large collections at the abc homepage also
 have big collections besides what is in the net right now we are talking
 of at least 60 MB of content (another approximation is to multiply the
 14000 titles of the www abc index with an single tune size of about 20KB
 makes 280.000 KB ).

I would say that much of this material is such that it can use the
current ABC definition till kingdom comes -- `Celtic' folk music and
other one-melody-line-plus-chords stuff. At least this applies to the
several megabytes of ABC-notated music on my machine. It seems that
therefore a great portion of that corpus will never have to be
translated into another representation.

If people do come up with a new notation that is better for multivoice
music, complicated classical scores etc. then by all means use that for
those kinds of music. I for one am quite happy with ABC the way it is
because it fits my requirements pretty much perfectly (with some
tweaking which could be made unnecessary without throwing all of ABC out
the window). Any completely-new notation had better be as simple as ABC
for my uses before I personally am going to jump ship.

Mind you, I'm all in favour of updating the ABC standard but not if new
functionality is invented wholesale. Let's try and bring the various
implementations together and build from there.

 So if an entirely new syntax appears how will this syntax interprete
 this pile ? what are your solutions?
 will you write an all plattform automatic conversion tool and is it sure
 that no part of thecontent gets lost in this process? 

I'm sure something could be worked out. A conversion tool doesn't
necessarily have to work on all platforms -- there could be a Web-based
conversion service for those who cannot or will not run, e.g., Perl
locally to convert their files.

Anyway, if a backwards-incompatible version of the ABC language (rather
than something entirely new and separate) is agreed upon then there
should be a way of tagging new-style files so that ABC processing
software can still work with both flavours without having to guess. We
could do it XML-style so that the first line of a file (or tune?) reads

  %%ABC version=2.0

(and this would also be the natural place to put `encoding=utf-8' and
such-like if desired).

Anselm

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

Re: [abcusers] something really simple


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

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


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

[abcusers] possible abctab2ps extensions

2001-11-12 Thread Christoph Dalitz


Dear abc users and devellopers,

meanwhile all originally planned tablature features are
realised in abctab2ps and I plan to do other music extensions,
mostly in the realm of early music.

Before I introduce some other incompatible set of abc extensions,
I would like to ask the other devellopers whether and how
they already have addressed some of the following issues.

1) figured bass

Both abctab2p2 and abcm2ps support line breaks (\n) and accidentals
(\# \b \=) in guitar chords; I have adopted the syntax of abcm2ps
in order to be compatible. Although I think that natural signs
should be avoided in figured bass (most historic sources only use
b for diminished intervals and # for augmented intervals) because
they break transposibility, it was an oft requested feature.

There is still a problem: more than one different chord/figure on
a single note (eg. a 5\n4 3# cadenza). Most historic sources place
the two figures centered above the bass note; most modern editions
however place them like an individual voice on the time axis. 

As the second solution is more desirable for readability reasons,
I am looking for a solution to emulate it. A possible solution
could be a voice parameter to print only the guitar chords of this
voice as guitar chords above a different voice. Example:

V:Flute clef=treble space=+10 bracket=2
V:Bass clef=bass
V:figures figuresof=Bass

Any better ideas?

2) rhythm of grace notes

abc supports grace notes, which are printed by abc2ps as eigth notes
in reduced size. A single grace note is printed as an eigth note
with an oblique stroke (ie. a short appogiatura in 19th century
context).

While doing some transcriptions of viol sonatas, I need grace notes
which are not eigth notes. The straightforward implementation 
(allowing rhythm factors in braces: {a//g//f//a//}) has a compatibility
issue: according to the old abc standard (or its interpretation that
was implemented in abc2ps), grace notes without a rhythm factor are 
of the length 1/8 rather than that of the L: field.

Any suggestions?

3) meter ambiguity

In early music, M:C| can mean M:4/2, M:4/1 or M:4/4.
And triple time M:3 can mean M:3/2, M:3/1 or M:3/4.
In other words, the mathematical meter differs from the meter symbol.

Thus I would suggest that the M: filed always means the
mathematical meter (which is importand for automatic barnumbering),
and that a diverging meter symbol can be specified via a pseudocomment
like
%%metersymbol 4/1=C|
%%metersymbol 3/2=3
This could mean: print C| whenever the meter is 4/1 and 3 whenever
it is 3/2.

Unfortunately I had introduced the syntax M:3 which was quickly
adopted by J.F.Moine for abcm2ps and even extended to stuff like M:2.

Maybe we could withdraw this extension and replace it with the
pseudocomment solution?

4) more clef types

There are 3 different clefs (G, C and F) which can appear on different
staff lines. Which names are currently used for the various clefs
in the different abc-programs? What identifiers are used for the
french violin clef (G1) for instance?


I stop at this point, because if this mail becomes even longer
noone will read it ;)

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

Re: [abcusers] possible abctab2ps extensions


On Mon 12 Nov 2001 at 04:18PM +0100, Christoph Dalitz wrote:
 
 Before I introduce some other incompatible set of abc extensions,
 I would like to ask the other devellopers whether and how
 they already have addressed some of the following issues.
 
 1) figured bass
 
 Both abctab2p2 and abcm2ps support line breaks (\n) and accidentals
 (\# \b \=) in guitar chords; I have adopted the syntax of abcm2ps
 in order to be compatible. 

I am not sure what a line break character would mean in the context
of a guitar chord. I allow ; as a shorthand for two guitar chords
together e.g.

A Db  could be written as A;Db

These are printed out one above the other by yaps.

Is this what you mean ?

 
 4) more clef types
 
 There are 3 different clefs (G, C and F) which can appear on different
 staff lines. Which names are currently used for the various clefs
 in the different abc-programs? What identifiers are used for the
 french violin clef (G1) for instance?
 

From memory, yaps supports clef=bass, treble, soprano, mezzosoprano,
and alto. These are all names that came out of one of my music 
textbooks.

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

Re: [abcusers] something really simple


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

Re: [abcusers] developing the standard ......




Actually the latest round of V: discussion that I 
remember reading contained an example which was acceptable to BarFly together 
with a conjecture that Muse probably wouldn't like it, but in fact it was quite 
acceptable to Muse. I believe that in fact there is a large common 
subset. (In this case I think Muse is a bit more generous because Muse 
digests the whole file and translates it into an internal format whereas BarFly 
formats the bars on the fly as it were and so has what is sort of equivalent to 
the usual sort of "one pass" syntax restrictions.

Laurie

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

Re: [abcusers] something really simple


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

Re: [abcusers] possible abctab2ps extensions

2001-11-12 Thread Ewan A. Macpherson


Christoph Dalitz [EMAIL PROTECTED] wrote:

 2) rhythm of grace notes
 
 abc supports grace notes, which are printed by abc2ps as eigth notes in
 reduced size. A single grace note is printed as an eigth note with an
 oblique stroke (ie. a short appogiatura in 19th century context).
 
 While doing some transcriptions of viol sonatas, I need grace notes
 which are not eigth notes. The straightforward implementation (allowing
 rhythm factors in braces: {a//g//f//a//}) has a compatibility issue:
 according to the old abc standard (or its interpretation that was
 implemented in abc2ps), grace notes without a rhythm factor are of the
 length 1/8 rather than that of the L: field.
 
 Any suggestions?

The draft standard includes the idea that grace notes should have 
modifiable lengths just like regular notes, and suggests that the 
software package should set the default length, although it might be 
more prudent to add this info to an extended L: field or create a new 
field so that all the info is in the tune.  This length should 
definitely *not* be derived from the standard L: field itself.  One 
shouldn't have to change the way grace notes are indicated based on 
changes in L:, and I defintely don't want to have to write a Highland 
pipe jig (typical grace = 1/32) like:

L:1/8
K:HP
{g//}A{d//}A{e//}A {g//e//f//}e2 f | {g//}ec{G//}c {g//e//f//}e2

instead of the much more legible

L:1/8
K:HP
{g}A{d}A{e}A {gef}e2 f | {g}ec{G}c {gef}e2

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

Re: [abcusers] possible abctab2ps extensions

2001-11-12 Thread Christoph Dalitz


James Allwright wrote:
 
  1) figured bass
 
  Both abctab2p2 and abcm2ps support line breaks (\n) and accidentals
  (\# \b \=) in guitar chords; I have adopted the syntax of abcm2ps
  in order to be compatible.
 
 I am not sure what a line break character would mean in the context
 of a guitar chord. I allow ; as a shorthand for two guitar chords
 together e.g.
 
 A Db  could be written as A;Db
 
 These are printed out one above the other by yaps.
 
 Is this what you mean ?
 
Yes. 

I wrote line break because I do not understand the abc guitar chords
only as guitar chords, but more general as arbitrary text printed above
a note. This includes guitar chords, basso continuo figures and dynamic
marks.

Admittedly \n is not very consistent, because abc mostly uses the TeXish
\\ for line breaks.

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

Re: [abcusers] something really simple


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

[abcusers] ABC used as tablature

2001-11-12 Thread Jack Campin


Another reason why BarFly's syntax for multiple voices can be useful.
This may not be as readable as honest-to-god real tablature but it's
still quite a bit easier than the original manuscript (which used
letters for the frets rather than note names and a separate rhythm
line).  It was for the mandour, a sort of five-course ukelele.

By using BarFly's text colouring capability you can make the x's less
conspicuous (or colour them white and make them vanish entirely) which
improves readability.

The staff notation this generates isn't as good as if you'd written the
ABC optimally for that, but it's usable.

X:1
T:Adew Dundie
S:Skene MS, early 17th century Scotland
S:Dauney, Ancient Scotish Melodies (1843)
V:1 program 1 46   down % a
V:2 program 1 46 merge down % d
V:3 program 1 46 merge down % A
V:4 program 1 46 merge down % D
V:5 program 1 46 merge down % A,
M:3/4
L:1/4
Q:3/4=56
K:D Dorian
V:1 x  x  x |x  x  x |x  x  x |x  x  x |a2c'|a2c'|a  x  x |x  x  x:|
V:2 x  d  d |d2d |x  x  d |e  g2   |x  x  x |x  x  x |x  g  e |d2x:|
V:3 A  x  x |x  x  x |c2x |A2x |A2x |A2x |x  x  x |x  x  x:|
V:4 x  x  x |D2x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |D2D:|
V:5 A, x  x |x  x  x |C2x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x:|
%
V:1 a  c' c'|c'2   c'|x  x  x |x  x  x |a  d' d'|d'2   d'|d' c' b |a3  |
V:2 x  x  x |x  x  x |x  x  d |e  g2   |x  x  x |x  x  x |x  x  x |x  x  x |
V:3 x  x  x |c2x |c2x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |
V:4 x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |A3  |
V:5 x  x  x |x  x  x |C2x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |
%
V:1 a  c' c'|c'2   c'|x  x  x |x  x  x |a2c'|a2c'|a  x  x |x  x  x|]
V:2 x  x  x |x  x  x |x  x  d |e  g2   |x  x  x |x  x  x |x  g  e |d3 |]
V:3 x  x  x |c2x |c2x |x  x  x |A2x |A2x |A2x |x  x  x|]
V:4 x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |D3 |]
V:5 x  x  x |x  x  x |C2x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x|]

(Phil - your mode guessing utility gets this one badly wrong, and it seems
fairly clear why).


=== http://www.purr.demon.co.uk/jack/ ===


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


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


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

2001-11-12 Thread 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

[abcusers] what clefs are available?

2001-11-12 Thread Katy Mulvey


Am I correct in my reading of the documentation of ABC (I use the 
http://www.gre.ac.uk/~c.walshaw/abc/ site) that a clef indication is a 
commonly available extension to the K keyword, but is not part of the real 
1.6 standard?

I was just wondering if there was any way to indicate that the treble clef 
was transposed an octave, using the 8 indication above or below the G-clef 
symbol. It's not mentioned at all in the extensions section of Steve 
Mansfield's ABC tutorial, so I was wondering if it was just not available.

(I also see I've stumbled on to the list at a time when there's much 
discussion about moving on to a new standard. I wish you all the best of 
luck with the process.)

Thanks,
   Katy

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

Re: [abcusers] something really simple


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] possible abctab2ps extensions


Tablature
1. Muse supports ABC to fretted instrument tab generation by giving string
information after the duration, using a semicolon to delimit it.  e.g. E2;4
Play E for 2 time units on string number 4.  On the whole it's only
necessary to give this information for a few notes, the rest can be
interpolated.  I have no idea how abctab2ps represents this information and
you didn't say, but I'd guess this is fundamental.  Where there is no
explicit string information, Muse just tries to do something sensible (it
enumerates all possible fingerings for the whole piece and selects the one
with the lowest difficulty score).

Clefs
Muse supports treble (G glef, G above middle C on 2nd line up), alto (C
middle C on middle line), tenor (middle C on 2nd line down) and bass (F
below middle C on 2nd line down).  Muse also supports what I think might be
a soprano clef (looks like treble clef but 8ve written above the staff and
plays an octave above treble clef) and can likewise play transposed an
octave down (8ve written below staff).  In fact Muse can play transposed by
just about any amount.  Muse also supports independently transposing of
guitar chords (so you can have music written for clarinet accompanied by
guitar with capo on 2nd fret. The chords will play a tone up and the
tadpoles a tone down!  This is currently indicated by ABC with the K:
command, but it would be easy to move it to V: or to come new command so
long as the syntax didn't change.
The syntax is based on comma separated sets of keyword=value e.g.
K: clef=bass, transpose=12

Laurie

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

Re: [abcusers] possible abctab2ps extensions

2001-11-12 Thread Ewan A. Macpherson


Anselm Lingnau [EMAIL PROTECTED] wrote:

 How about
 
   L:1/8 grace=1/32
   K:HP
   {g}A{d}A{e}A {gef}e2 f | {g}ec{G}c {gef}e2

Seems reasonable.  Or maybe just

L:1/8 {1/32}

 ? (In the case that `grace' is not specified we could fall back to,
 e.g., a standardized default of `grace=1/8'. 

Except for K:Hp or K:HP, where the default should be 1/32 .

 Within a tune, the
 `grace' attribute should probably persist across `L:' changes that don't
 introduce a new `grace' setting, for convenience.)

Indeed!

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

Re: [abcusers] something really simple


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


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

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


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