Re: [abcusers] ABC 1.7 standard?

[Ulf Bro]

> I don't post a lot to the list, but I can't let this pass without giving
> you my two cents...
>
> What the abc 'movement' needs is someone who takes responsibility over
> the standard. Ever since Chris stopped active participation, a lot of
> very good extensions to the standard have been made, but because there
> is no real leader, these changes remain, well, apocryphal.

I don't post much either, although I use abcm2ps every single day the whole 
year around. It's just that the things I write is mostly copyrighted material 
and there is no way to put this on the web and make it available to other 
people, just see how Atte Andre Jensen's wonderful Jazz Songbook disappeared 
because Atte began fearing being sued...

Anyway, I think things have gone so far by now that we have to accept the 
multistave development etc. so that we actually have to discuss not abc1.7 
but abcplus, the expression Guido uses on his homepage.

There is no way to isolate a standard from the software that uses it and there 
is no way of avoiding shared interests between software developer and 
standard setter. We have seen this in the development of another very common 
standard, the HTML...

So I actually think that one should - more or less - accept the additions 
which abcm2ps has introduced and set this as a new standard.

I think Guido's "Manual" is the best book that has been written on abc and the 
simple fact that this book exists, I think, is enough to qualify it as a sort 
of standard.



There is no doubt that the best solution would be to find a professor who 
works at a university somewhere in the world, and has time to take care of 
such things, and gets paid for it...

Even if most development has taken place in Western Europe I have a hunch that 
the abc system could be of great importance to the future members of the EU 
like Poland, Hungary etc - countries which have abundant folk music that's 
just waiting to be coded in abc.

So - apart from thinking that Guido is the best one to take care of all this, 
which he does in his free time without getting paid for it, I would like to 
see an Estonian professor or something like it, founding a 
"Department of ABC"...

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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[Bernard Hill]

In message <[EMAIL PROTECTED]>, Frank Nordberg
<[EMAIL PROTECTED]> writes
>
>
>Manuel Reiter wrote:
>...
>
>
>but I'd very much appreciate a list of
>> all (or most ;-) ) available accents.
>
>Go to
>http://www.musicaviva.com/abc/abcyclopedia/view.tpl?kw=Special%20characters
>
>(that URL is so long it may be broken up by some email client - if so, 
>copy and paste - or you can go to 
>http://www.musicaviva.com/abc/abcyclopedia/index.tpl and select "S" and 
>then "Special characters")
>

Just no mention of how to get the \ character itself... ?

Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

[abcusers] Accented characters in lyrics (abc2ps)

[Jack Campin]

> I just plop the characters i want in the abc file, like, for example:

>   z D   E | G2  G G2  F  | E2  E z  F   G | A2   G (FE)   D |  F2 E
>  w: v-  o   et  por- que jus-  ti- a  t-  en d'el et  de-* rei-  tu-ta,

> I use jcabc2ps to render the file, but any program should be able to 
> handle this.

Are we to assume there were some non-ASCII characters in there?  My mail
client didn't show any, which kinda points to the problem with that...

High-bit characters also map onto different things in different systems.


:> To use accented letter, type the following:
:> \`a  => "a with grave" [...]
:> \~n  => "n with tilde"

It would be far more partable if ABC software used HTML standards
for this and deprecated TeXisms.  TeX is never going to get wider
use; HTML/XML/XHTML is where all the development is going on and
there are far more machines out there with installed software that
uses it.  And it seems it's increasingly going to be built into
the OS with Windows (not in itself any bad thing regardless of the
sleazy politics involved).


: What's wrong with simply putting the correct accent in the text?
: They're all part of the extended character set, and pretty much a
: standard these days.

What standard?  I got an emailed document from a Word for Windows
user today that had a whole pile of n-tildes in it (hex 96, decimal
150).  They were presumably typed by that pathetic slave of Satan
with the intention that they should be some sort of punctuation or
bullet character, but I've no idea what.

Many editors (at least on the Mac) can translate the local character
set to HTML, so there's no need ever to ship non-portable forms to
other people who might have different platforms, however convenient
the type-it-straight-in approach might be for you.

-
Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760
 * food intolerance data & recipes,
Mac logic fonts, Scots traditional music files, and my CD-ROM "Embro, Embro".
--> off-list mail to "j-c" rather than "abc" at this site, please <--


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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[Manuel Reiter]

Hi again,

> but I'd very much appreciate a list of
> > all (or most ;-) ) available accents.
> 
> Go to
> http://www.musicaviva.com/abc/abcyclopedia/view.tpl?kw=Special%20characters

Great, thanks, that's exactly what I was looking for.

Unfortunately, the hacek and breve accents did not seem to work with my
versions of either abc2ps or jcabc2ps when I tried them yesterday
(guessing, then), they were just rendered as 'u' or 'v' preceding the
would-be-accented letter. I'll have to check versions when I'm back home,
but if anybody knows off the top of their head which abc2ps clones can
handle these, I'd be grateful for the hint.

Thanks also to everyone else who answered.

Cheers,

  Manuel

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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[I. Oppenheim]

On Tue, 1 Jul 2003, Jack Campin wrote:

> :> To use accented letter, type the following:
> :> \`a  => "a with grave" [...]
> :> \~n  => "n with tilde"
>
> It would be far more partable if ABC software used HTML standards
> for this and deprecated TeXisms.

There's nothing wrong with these TeXisms: they are easy
to remember, can be entered on every computer system
around the world, are currently implemented in ABC
software, and last but not least: they do their job!

I prefer typing [\'a] over [á] If you prefer
the latter, why not write a preprocessor that converts
it back to \'a


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] Accented characters in lyrics (abc2ps)

[Manuel Reiter]

On Tue, 1 Jul 2003, Bernard Hill wrote:
> Just no mention of how to get the \ character itself... ?

While I can't imagine it being important for too many song lyrics, I'd
guess '\\' will or at least should do the trick.

Greetings,

  Manuel

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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[Guido Gonzato]

On Tue, 1 Jul 2003, I. Oppenheim wrote:

> I prefer typing [\'a] over [á] If you prefer
> the latter, why not write a preprocessor that converts
> it back to \'a

it already exists, I wrote it: abcpp (http://abcplus.sourceforge.net/#abcpp)
But it's much simpler to use TeX-like sequences. IMHO.


Ciao,
 Guido =8-)

-- 
Guido Gonzato, Ph.D.  - Linux System Manager
Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN.
Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy)
Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri

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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[Bernard Hill]

In message <[EMAIL PROTECTED]>, Jack Campin
<[EMAIL PROTECTED]> writes
>> I just plop the characters i want in the abc file, like, for example:
>
>>   z D   E | G2  G G2  F  | E2  E z  F   G | A2   G (FE)   D |  F2 E
>>  w: v-  o   et  por- que jus-  ti- a  t-  en d'el et  de-* rei-  tu-ta,
>
>> I use jcabc2ps to render the file, but any program should be able to 
>> handle this.
>
>Are we to assume there were some non-ASCII characters in there?  My mail
>client didn't show any, which kinda points to the problem with that...
>
>High-bit characters also map onto different things in different systems.
>
>
>:> To use accented letter, type the following:
>:> \`a  => "a with grave" [...]
>:> \~n  => "n with tilde"
>
>It would be far more partable if ABC software used HTML standards
>for this and deprecated TeXisms.  TeX is never going to get wider
>use; HTML/XML/XHTML is where all the development is going on and
>there are far more machines out there with installed software that
>uses it.  And it seems it's increasingly going to be built into
>the OS with Windows (not in itself any bad thing regardless of the
>sleazy politics involved).

Well I can go with that if we must have an alternative.
>
>
>: What's wrong with simply putting the correct accent in the text?
>: They're all part of the extended character set, and pretty much a
>: standard these days.
>
>What standard?  I got an emailed document from a Word for Windows
>user today that had a whole pile of n-tildes in it (hex 96, decimal
>150).  They were presumably typed by that pathetic slave of Satan
>with the intention that they should be some sort of punctuation or
>bullet character, but I've no idea what.

In that case your user probably used a font which is not in your system,
or a version of word later than yours.
>
>Many editors (at least on the Mac) can translate the local character
>set to HTML, so there's no need ever to ship non-portable forms to
>other people who might have different platforms, however convenient
>the type-it-straight-in approach might be for you.

But this avoids the question of what *is* the character set? For the
Americans £ (pound!) and Euro are extended characters yet of course for
a European accented characters of all sorts are right there on the
keyboard and are typed into the document! To make a Frenchman type \'a
when it's a key on the keyboard is pretty strange, if not insulting!

... and what's the \?? code for £ anyway ?


Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[Laura Conrad]

> "Bernard" == Bernard Hill <[EMAIL PROTECTED]> writes:

Bernard> But this avoids the question of what *is* the character
Bernard> set? For the Americans £ (pound!) and Euro are extended
Bernard> characters yet of course for a European accented
Bernard> characters of all sorts are right there on the keyboard
Bernard> and are typed into the document! To make a Frenchman type
Bernard> \'a when it's a key on the keyboard is pretty strange, if
Bernard> not insulting!

I admit to being lazy enough to type á instead of \'a myself, but if I
(or your hypothetical Frenchman) really cared about portability, we
would either type the \'a or use a system like X-Symbol (for emacsen)
that substitutes the correct TeX or HTML for what we type.

Speaking of which, do any of the ABC emacs modes play correctly with
X-Symbol?

-- 
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] Accented characters in lyrics (abc2ps)

[Bernard Hill]

In message <[EMAIL PROTECTED]
uni-frankfurt.de>, Manuel Reiter <[EMAIL PROTECTED]>
writes
>On Tue, 1 Jul 2003, Bernard Hill wrote:
>> Just no mention of how to get the \ character itself... ?
>
>While I can't imagine it being important for too many song lyrics, I'd
>guess '\\' will or at least should do the trick.

Certainly... but it must be in the standard.

(Could be useful for filenames [titles?] for abc's kept on one's own
system)

Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

RE: [abcusers] Accented characters in lyrics (abc2ps)

[Christophe Declercq]

> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] la part de Bernard Hill
> Envoyé : mardi 1 juillet 2003 09:56
> À : [EMAIL PROTECTED]
> Objet : Re: [abcusers] Accented characters in lyrics (abc2ps)
>
[...]
>
> But this avoids the question of what *is* the character set? For the
> Americans £ (pound!) and Euro are extended characters yet of course for
> a European accented characters of all sorts are right there on the
> keyboard and are typed into the document! To make a Frenchman type \'a
> when it's a key on the keyboard is pretty strange, if not insulting!

I am a French MS-WINDOWS user but I know that there is several character
encoding systems on this planet even for latin alphabets, so I don't find
that strange at all.

Usage of TeX-like accented characters is in ABC from the beginning. It needs
less typing than html so it's OK for me (yes, I'am a TeX/LaTeX user...).

Christophe

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

[abcusers] The abc standard

[Phil Taylor]

I've held back from this discussion so far to see where it was going
but I think it's time to add my 2p.

Over the past year or so, this group has become dominated by discussion
of abcm2ps; it shows a strong tendency to become the abcm2ps users
group.  Now abcm2ps is an excellent program, but it is extremely
limited; all it does is convert abc to postscript.  If that's all
you want to do with abc you will be perfectly happy to see the abc
standard redefined in terms of what abcm2ps does.  The language is,
however much more than source code for musical typesetting.  It is
an abstract method of representing music in a human-readable format,
and its development must not be tied to one particular use, any more
than it should be tied to one particular musical genre.

So, if we are going to hand over the development of the standard to
one person, that person is going to need to have a wide range of
musical interests, and be very familiar with the existing corpus of
abc and the ways in which it is used.  He is going to be equally
familiar with all three of the major platforms on which abc software
is run, and with the major abc programs which run on those platforms.
He is going to be familiar with programs which do fast onscreen
display of abc music, programs which play abc, programs which do
musical analysis or use abc for archival or database purposes etc.
He's also going to have lots and lots of time available.

I don't think such a person exists.  It's a job for a committee.

Perhaps a different approach is called for.  A while back, I made
a study of the way in which different programs handle multivoice
abc.    It was
a lot of work to do, but it proved useful, and since I put that
document online, the major abc programs have actually moved closer
together.  Maybe what we need to do is to publicly document the
remaining differences between programs in such a way that all of
the developers can see what's already been done, and

a) avoid reinventing the wheel.*
b) support multiple existing formats where they exist.

Certainly, whatever way we take forward, the first step is to
document the existing programs in a comparative way.  The way in
which your favourite program does it is not necessarily the best
way, and until you have done the comparison you really don't know.

Phil Taylor


* actually I'm not averse to doing that myself, since if nobody
had ever reinvented the wheel your car would still run on log rollers.


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

RE: [abcusers] Accented characters in lyrics (abc2ps)

[I. Oppenheim]

On Tue, 1 Jul 2003, Christophe Declercq wrote:

> I am a French MS-WINDOWS user but I know that there
> is several character encoding systems on this planet
> even for latin alphabets, so I don't find that
> strange at all.

I'm a Dutch ABC user and also do not find it strange at
all. But it seems that English software writers, who do
not need those accents themselves, have difficulty
understanding the need for a portable transcription
system such as [\'a].


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] ABC 1.7 standard?

[John Chambers]

Jeff Bigler writes:
| > In message <[EMAIL PROTECTED]>, John Chambers
| > >Bernard Hill writes:
| > >| Just one comment: having a software developer in charge of standards is
| > >| a conflict of interests. S/he can drive the standard in the direction of
| > >| his/her own software.
| > >
| > >Yeah, and I'd like to add that we also shouldn't have a  musician  in
| > >charge  of  the  standard,  since  s/he can drive the standard in the
| > >direction of his/her own favorite musical styles.
| > >be good to avoid this.)
...
| Agreed on all counts.  I think the comment about musicians was meant to
| be tongue-in-cheek.

Hmm ...  That's how I took it, and I wasn't expecting anyone to  take
my comment as anything other than totally absurd.  (I even included a
smiley.) However, I was hoping that  someone  else  would  follow  my
comment  with something even sillier.  I'm not sure how one could top
the absurdity of a standard for music notation developed by  a  group
that excludes musicians, but I hoped that someone would find a way.

We are getting into what news people call the Silly Season ...



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

Re: [abcusers] ABC 1.7 standard?

[A.M. Kuchling]

On Tuesday, July 1, 2003, at 06:58  AM, John Chambers wrote:
Both of these argue against any real significance to a standard. Some
implementers  don't  care about following standards, and won't change
their code to match a new (or old) standard.  Other implementers want
to  do  things outside the standard, and show a history of discussing
ideas openly and avoiding conflicts.  In both cases,  a  standard  is
not particularly helpful.
Lack of a standard reduces the probability of new implementations, 
though.  I've just joined the list because I'd like to try writing an 
abc-to-SVG converter; that would entail writing a new parser.  However, 
I don't want to have to reverse-engineer the current
state of the ABC language by reading an outdated spec, reading specs 
for various extensions, figuring out which of those extensions made it 
into deployed software and
which were just vaporware, and reading code to figure out extensions 
that haven't had specs written.

This means I can't really assess how complicated the task of writing an 
ABC parser is.  Competing specifications such as MusicXML are uglier to 
read and not really authorable by hand, but at least there's a MusicXML 
specification available.

Google doesn't turn up either the 1.7 or 2.0 drafts that have been 
recently mentioned.
As a start, it would be very helpful if current versions of these 
drafts were available on the web somewhere, because they'd provide a 
clearer picture of ABC's current complexity.

--amk

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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[John Chambers]

David Webber writes:
| From: "Guido Gonzato" <[EMAIL PROTECTED]>
|
| > and many others. A more complete list will be available in the
| upcoming
| > ABC 2.0.0 draft.
|
| On that topic, let me add that the jump from 1.6 to 2 (rather than
| 1.7) seems well merited by the introduction of parallel voices,
| which is a very big improvement in capability.

Maybe not. There is a fairly well-established convention in
the  computer  biz  that the first digit should change only
when you break backward compatibility.  The V  lines  don't
break any pre-existing abc.  They are a pure extension, not
a change of any sort. So this should probably not warrant a
jump to a version starting with "2.".

Of course, such things are merely conventions, and lots  of
companies have violated them.  A big number change is often
done for marketing purposes, to convince  users  that  it's
something they should spend money on.

I guess it mostly seems silly to see that we'd  be  telling
people that there are two versions of abc, 1.6 and 2.  This
sounds like a parody of how computer people do things.

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

Re: [abcusers] The abc standard

[I. Oppenheim]

On Tue, 1 Jul 2003, Phil Taylor wrote:

> Over the past year or so, this group has become
> dominated by discussion of abcm2ps;

Probably because it is the best and least "limited" ABC
implementation around: it implements an extensive set
of features, is actively developed, runs on all
computer platforms that we use and gives excellent
ouput quality!

> So, if we are going to hand over the development of
> the standard to one person,

No one suggested that just 1 person should do all of
the work.

> He is going to be familiar with programs which do
> fast onscreen display of abc music, programs which
> play abc, programs which do musical analysis or use
> abc for archival or database purposes etc.

Phil, this are all implementation specific issues which
a standard should not address. As you indicated
yourself, ABC is just an *abstract* computer
representation of a computer score; all that the
standard should do is to define this representation in
an abstract way. Whether the *concrete* ABC files are
to be played, displayed, printed or analyzed is up to
the end user. What the internal data format of the
handling program should be, is up to the software
developer and depends on the task at hand.


As several software developers already indicated, no
major software package will consider to import or
export ABC unless there exists a clear, well-defined
and uptodate ABC standard. As such, I think we are by
far better off with a possibly sub-optimal standard
than with no standard at all!

No standard can make all users or developers happy at
the same time; no one can oblige all software
developers to implement the standard.

All we can do as an user group is to define a clear
standard for those users and developers that feel a
need for it and are willing to comply. To make sure
that this will work out, we need a couple of "leaders"
who make the final decisions based on input from this
e-mail group. As I already stated, possibly sub-optimal
decisions are better than no decisions at all!

So, Jef and Guido, what do you think? Are you willing
to discuss your ideas with us?


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] ABC 1.7 standard?

[I. Oppenheim]

On Tue, 1 Jul 2003, A.M. Kuchling wrote:

> Google doesn't turn up either the 1.7 or 2.0 drafts
> that have been recently mentioned. As a start, it
> would be very helpful if current versions of these
> drafts were available on the web somewhere, because
> they'd provide a clearer picture of ABC's current
> complexity.

Currently, the latest version of the ABC standard is
1.7.6:
http://www.gre.ac.uk/~c.walshaw/abc/abc-draft.txt

There is also a BNF representation available:
http://www.norbeck.nu/abc/abcbnfx.htm

For an overview of the current state of the ABC
language, I suggest you look here:
http://abcplus.sourceforge.net/abc_manual_en.pdf


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*

 Chazzanut Online:
 http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] Accented characters in lyrics (abc2ps)

[John Chambers]

Manuel Reiter writes:
| > Go to
| > http://www.musicaviva.com/abc/abcyclopedia/view.tpl?kw=Special%20characters
|
| Great, thanks, that's exactly what I was looking for.
|
| Unfortunately, the hacek and breve accents did not seem to work with my
| versions of either abc2ps or jcabc2ps when I tried them yesterday
| (guessing, then), they were just rendered as 'u' or 'v' preceding the
| would-be-accented letter. I'll have to check versions when I'm back home,
| but if anybody knows off the top of their head which abc2ps clones can
| handle these, I'd be grateful for the hint.

You're right.  I've been wanting this from  the  beginning,
and I've even used notation like \^s and \^c in a few tunes
with  the  hope  that  I  would  eventually  learn  how  to
implement it in my abc2ps clone. It's been a few years, and
I still have no clue whatsoever.  On my  home  printer  (HP
LaserJet  4L),  I  once  saw  it  produce  a Polish slash-l
character, which is a hint of a possibility. But I couldn't
reproduce it.  The manual doesn't help me.

The original abc2ps, and probably all clones,  will  accept
just  about  any 8-bit bytes and pass them on to a printer.
But they're just 8-bit bytes, and what comes  out  is  what
the  printer  decides  they should look like.  I don't know
whether PostScript  (or  PDF)  even  has  a  way  to  doing
anything  different.   PS just contains text as a string of
bytes.  What they look like is determined by what you  feed
the file to, and what fonts it has installed.

I don't know if there's  any  way  for  a  program  on  the
computer to know how to make a specific 8-bit byte come out
on paper as a particular glyph.  The problem here  is  that
abc2ps  just  produces  PostScript.  It can't possibly know
what you're going to do with  that.   It  can't  query  the
printer  to  see what fonts are installed, because it can't
know what printer you are going to use, if any.

Consider, for example, my Tune Finder, which can return  PS
files.   Presumably  you  are going to print them, or maybe
feed them to a PS display program.  How would a CGI  script
on  my server query your printer or PostScript renderer for
its list of installed fonts?

This is a rhetorical question, of course. You'd better hope
that my script can't query the hardware on your machine. In
fact, it probably can't connect to your machine at all.  If
you're  behind any sort of firewall, this would be blocked,
is as it should be.  And even if it could get in, it  still
has  no way of knowing what you'll do with a PS file, so it
doesn't know what to query for a font list.

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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[John Chambers]

Bernard Hill writes:
|
| ... and what's the \?? code for £ anyway ?

\163

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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[I. Oppenheim]

On Tue, 1 Jul 2003, John Chambers wrote:

> | Unfortunately, the hacek and breve accents did not seem to work with my
> | versions of either abc2ps or jcabc2ps when I tried them yesterday

I believe these hacek and breve accents are only
handled by TeX and not by any of the abc2ps clones.
I guess that the abc2ps clones can only handle the
French, Scandinavian, and German accents.

> I don't know if there's any way for a program on the
> computer to know how to make a specific 8-bit byte
> come out on paper as a particular glyph.

You won't like my answer: you will have to embed a
suitable font. That is exactly what TeX does.


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*

 Chazzanut Online:
 http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] The abc standard

[David Webber]

From: "John Chambers" <[EMAIL PROTECTED]>
>
> Maybe not. There is a fairly well-established convention in
> the  computer  biz  that the first digit should change only
> when you break backward compatibility.

Well I must admit I believe that "well established" is a slight
exaggeration - different people do all sorts of things.

> Of course, such things are merely conventions, and lots  of
> companies have violated them.  A big number change is often
> done for marketing purposes, to convince  users  that  it's
> something they should spend money on.

As you say, especially if they're selling them: in that case
changing the second digit is not nearly so good at generating
upgrade sales .   But no matter, I'm not particularly attached to
the idea one way or the other.

> The V  lines  don't
> break any pre-existing abc.  They are a pure extension, not
> a change of any sort. So this should probably not warrant a
> jump to a version starting with "2.".

I'm too new around here to know what traditional abc apps do when
they find a V: line - append it

> I guess it mostly seems silly to see that we'd  be  telling
> people that there are two versions of abc, 1.6 and 2.

In the Windows world we're used to a lot worse:  3.0 - 3.1 - 95 -
NT3.1 - NT3.5 - NT4 - 98 - Me - 2000 - XP.  A choice between 1.6 and
2.0 would look positively sane.  :-)

> This sounds like a parody of how computer people do things.

Self-parody is a noble art.  :-)

Anyway to put my oar in the water properly:  I am not primarily
concerned about whether new developments in abc initially favour one
kind of musician or another.  (As a sax player I find my needs are
rarely considered by anybody - but that's another story.)  The
reason for my lack of concern is that, having read one or two of the
documents I have been pointed at, I see current developments as
moving abc towards a point where it can represent a vastly wider
selection of music, with V: being the really major development,
which people have apparently implemented slightly differently.  If
abc"1.7" or "2" or "plus" can define a standard for that, and
persuade authors to come together to the new standard, then I'm sure
further developments will be easier rather than harder.

My interest is in having MOZART  (initially) import abc.  The one
thing I *don't* want is to have to do it 23 different ways according
to which package wrote the file.   So if there is a standard I can
read it.  If not, then, abc starts to look like something which
"would have been nice but...".   I am sure many other software
authors who have not yet implemented abc will feel the same way, and
so a properly defined standard (including V:) may actually make abc
take off at a much greater rate - even if it doesn't cover
absolutely everything (yet).

Casting a (very) fresh eye, over abc, I see various things which I
would like it to do (and maybe it does some of them and I have
missed it).  But I am going to refrain from specific comment a
little longer, because I understand Guido is writing a draft
standard for "abc plus", which is almost ready to see the light of
day.  I understand he is trying to maximise compatibility with those
who have already extended the standard.  Given that he calls it a
"draft", it seems that he is inviting comment (and I intend to ).
I don't know the history of who has written which app, or whether
anyone has an axe to grind or not, but given that Guido is actually
doing something (which is usually more effective than talking about
doing something), I would very much hope that some group of
interested parties could coalesce around his draft, and, with that
as a starting point, agree on a standard (and how to maintain it as
a standard).

If I write an abc importer, I don't want people creating files in 6
months time which will break it. If I write an exporter, I would
really like the exported files to be readable by as many packages as
possible.  Next year too.

Dave
David Webber
Author of MOZART the music processor for Windows -
http://www.mozart.co.uk
Member of the North Cheshire Concert Band
http://www.northcheshire.org.uk


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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[Bernard Hill]

In message <[EMAIL PROTECTED]>, John Chambers
<[EMAIL PROTECTED]> writes
>Bernard Hill writes:
>|
>| ... and what's the \?? code for £ anyway ?
>
>\163
>
>;-)
>To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/list
>s.html

(Actually it's not: it's either 156 or 0163 :-)


Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[Bernard Hill]

In message <[EMAIL PROTECTED]>, John Chambers
<[EMAIL PROTECTED]> writes
>David Webber writes:
>| From: "Guido Gonzato" <[EMAIL PROTECTED]>
>|
>| > and many others. A more complete list will be available in the
>| upcoming
>| > ABC 2.0.0 draft.
>|
>| On that topic, let me add that the jump from 1.6 to 2 (rather than
>| 1.7) seems well merited by the introduction of parallel voices,
>| which is a very big improvement in capability.
>
>Maybe not. There is a fairly well-established convention in
>the  computer  biz  that the first digit should change only
>when you break backward compatibility.  The V  lines  don't
>break any pre-existing abc.  They are a pure extension, not
>a change of any sort. So this should probably not warrant a
>jump to a version starting with "2.".

I've never heard of that! In fact in my opinion NO program should break
backward compatibility!

MS Word 2000 reads Word 97, Word 6, Word 2 files


And USB 2 works with USB1.1 afaik...


>
>Of course, such things are merely conventions, and lots  of
>companies have violated them.  A big number change is often
>done for marketing purposes, to convince  users  that  it's
>something they should spend money on.

Maybe so, but I would agree with Dave Webber that a large change such as
multi-voices really requires a unit increase to 2.0

>
>I guess it mostly seems silly to see that we'd  be  telling
>people that there are two versions of abc, 1.6 and 2.  This
>sounds like a parody of how computer people do things.

I don't see why it's a parody, or silly. "There are versions of abc:
version 1.6, and some big extensions in the new version 2".



Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

Re: [abcusers] The abc standard

[Laura Conrad]

> "David" == David Webber <[EMAIL PROTECTED]> writes:

>> The V  lines  don't
>> break any pre-existing abc.  They are a pure extension, not
>> a change of any sort. So this should probably not warrant a
>> jump to a version starting with "2.".

David> I'm too new around here to know what traditional abc apps do when
David> they find a V: line - append it

I don't know for sure about V:, but I've certainly run into a bunch of
apps that crash when they see w:.

-- 
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] The abc standard

[Bernard Hill]

In message <[EMAIL PROTECTED]>, David Webber
<[EMAIL PROTECTED]> writes
>
>My interest is in having MOZART  (initially) import abc.  The one
>thing I *don't* want is to have to do it 23 different ways according
>to which package wrote the file.   So if there is a standard I can
>read it.  If not, then, abc starts to look like something which
>"would have been nice but...".   I am sure many other software
>authors who have not yet implemented abc will feel the same way, and
>so a properly defined standard (including V:) may actually make abc
>take off at a much greater rate - even if it doesn't cover
>absolutely everything (yet).

I'm in a slightly worse position, Dave. Music Publisher 5's abc import
facility is almost at the finished stage and I don't want to undo any
code writing!

But the "23 different ways" is with us already it seems to me.
Downloading files from various sources on the net has given a LOT of
differences which can't all be correct at the same time. I even asked
for advice from Chris Walshaw but no reply.


>
>Casting a (very) fresh eye, over abc, I see various things which I
>would like it to do (and maybe it does some of them and I have
>missed it).  But I am going to refrain from specific comment a
>little longer, because I understand Guido is writing a draft
>standard for "abc plus", which is almost ready to see the light of
>day.  I understand he is trying to maximise compatibility with those
>who have already extended the standard.  Given that he calls it a
>"draft", it seems that he is inviting comment (and I intend to ).
>I don't know the history of who has written which app, or whether
>anyone has an axe to grind or not, but given that Guido is actually
>doing something (which is usually more effective than talking about
>doing something), I would very much hope that some group of
>interested parties could coalesce around his draft, and, with that
>as a starting point, agree on a standard (and how to maintain it as
>a standard).

I'll go with that.

>
>If I write an abc importer, I don't want people creating files in 6
>months time which will break it. 

Too late I think. Unless you can prove otherwise ... :-)

>If I write an exporter, I would
>really like the exported files to be readable by as many packages as
>possible.  Next year too.




Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

Re: [abcusers] Accented characters in lyrics (abc2ps)

[David Webber]

From: "Bernard Hill" <[EMAIL PROTECTED]>

>In fact in my opinion NO program should break
> backward compatibility!

Hello there Bernard.  We must stop meeting like this.  :-)

I think the problem is more a question of  *forward* compatibility.
If one has .abc files written to the new standard (if we have one)
and .abc files written to the old 1.6 standard, the question is what
the old apps do when they meet one of the new files.  AFAIK there
was no version stamp in the old files so that well written apps
could check it and say "sorry can't read this" if it was too late a
version.

Some effort therefore seems to be aimed at creating a standard so
that old apps will not choke on it.   abc is structured so that this
is almost possible, but in the end it depends on the old apps in
question and I suspect it is doomed to failure.

Dave
David Webber
Author of MOZART the music processor for Windows -
http://www.mozart.co.uk
Member of the North Cheshire Concert Band
http://www.northcheshire.org.uk


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

Re: [abcusers] The abc standard

[I. Oppenheim]

On Tue, 1 Jul 2003, Bernard Hill wrote:

> But the "23 different ways" is with us already it seems to me.
> Downloading files from various sources on the net has given a LOT of
> differences which can't all be correct at the same time. I even asked
> for advice from Chris Walshaw but no reply.

As soon as there is an uptodate standard, your
program can claim that it handles only standard ABC,
and the "22 other ways" will be deprecated. Users will
be adviced to only use software products that comply to
the new standard.

It is a very good idea to add an ABC version field to
the header, to distinguish old ABC from new ABC.


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

[abcusers]New version, old software

[Bernard Hill]

In message <[EMAIL PROTECTED]>, David Webber
<[EMAIL PROTECTED]> writes
>
>From: "Bernard Hill" <[EMAIL PROTECTED]>
>
>>In fact in my opinion NO program should break
>> backward compatibility!
>
>Hello there Bernard.  We must stop meeting like this.  :-)
>
>I think the problem is more a question of  *forward* compatibility.
>If one has .abc files written to the new standard (if we have one)
>and .abc files written to the old 1.6 standard, the question is what
>the old apps do when they meet one of the new files.  AFAIK there
>was no version stamp in the old files so that well written apps
>could check it and say "sorry can't read this" if it was too late a
>version.

Yes, I agree there. You or I would have done it differently ;-)

>
>Some effort therefore seems to be aimed at creating a standard so
>that old apps will not choke on it.   abc is structured so that this
>is almost possible, but in the end it depends on the old apps in
>question and I suspect it is doomed to failure.

Agreed.

However one possibility is that the new files should be given a new
extension. (How about - gasp - ".abc2"?) That warns off old software in
a sense yet the customer can get round it by renaming and "having a go",
since it might well have been created by new software yet use no new
fields.


Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

Re: [abcusers] The abc standard

[Bernard Hill]

In message <[EMAIL PROTECTED]>, I. Oppenheim
<[EMAIL PROTECTED]> writes
>

>It is a very good idea to add an ABC version field to
>the header, to distinguish old ABC from new ABC.

That gets my vote. And/or a change of file extension.

Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

Re: [abcusers] The abc standard

[David Webber]

From: "Bernard Hill" <[EMAIL PROTECTED]>

> I'm in a slightly worse position, Dave. Music Publisher 5's abc
import
> facility is almost at the finished stage and I don't want to undo
any
> code writing!

I have made a lot of progress with MOZART's abc import, but as you
indicate I still have a long way to go.  I am trying to steer clear
of multipart files until a spec turns up.

(MOZART's main difficulty is that it is fussy about the number of
beats in a bar.  I know Music Publisher isn't.  There are swings and
roundabouts - but given that a lot fo Chris Walshaw's first simple
examples - an obvious place to start - do not respect the number of
beats in a bar, I suspect you had an easier time of starting than I
did.)

> But the "23 different ways" is with us already it seems to me.
> Downloading files from various sources on the net has given a LOT
of
> differences which can't all be correct at the same time.

That is what I was afraid of.

> I even asked
> for advice from Chris Walshaw but no reply.

Me too.  I gather he seems to have let go of abc.

> >If I write an abc importer, I don't want people creating files in
6
> >months time which will break it.
>
> Too late I think. Unless you can prove otherwise ... :-)

Always the optimist eh Bernard?

Still one can always try :-)

Dave
David Webber
Author of MOZART the music processor for Windows -
http://www.mozart.co.uk
Member of the North Cheshire Concert Band
http://www.northcheshire.org.uk

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

Re: [abcusers] The abc standard

[Phil Taylor]

Suggestions that we change the abc file extension to something other
than .abc are kind of missing the point.  File extensions are irrelevant
in Classic MacOS, so BarFly will open any text file, regardless of
extension.  If the file contains any lines which start with X: it
will treat what follows as an abc tune on request.

Likewise, the oft-repeated suggestion that file headers should start
with a version number which identifies the version of abc won't work
either because users mostly won't bother.

You have to remember that most users write their abc using a text editor.
They make mistakes, and they leave things out.  Now you might say
that programs should be strict about interpreting it, and point out
the errors.  The problem there is that the net is full of erroneous
abc, and if a program is too strict in it's interpretation, it's a
pain in the arse to use, and users will choose to go elsewhere.

So, interpreting abc is rather like interpreting a natural language.
Whatever the standard says you have to bear in mind that this is a
language which people use to communicate music to each other, with
no computers involved (other than in the transmission part of the
process).  For this reason, interpreting abc is much, much harder
than interpreting MusicXML (despite the fact that MusicXML is a much
more complete language).

Phil Taylor


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

Re: [abcusers] The abc standard

[Phil Taylor]

I. Oppenheim wrote:
>On Tue, 1 Jul 2003, Phil Taylor wrote:
>
>> Over the past year or so, this group has become
>> dominated by discussion of abcm2ps;
>
>Probably because it is the best and least "limited" ABC
>implementation around: it implements an extensive set
>of features, is actively developed, runs on all
>computer platforms that we use and gives excellent
>ouput quality!

Have you ever used any other abc software?

>> So, if we are going to hand over the development of
>> the standard to one person,
>
>No one suggested that just 1 person should do all of
>the work.
>
>> He is going to be familiar with programs which do
>> fast onscreen display of abc music, programs which
>> play abc, programs which do musical analysis or use
>> abc for archival or database purposes etc.
>
>Phil, this are all implementation specific issues which
>a standard should not address. As you indicated
>yourself, ABC is just an *abstract* computer
>representation of a computer score; all that the
>standard should do is to define this representation in
>an abstract way. Whether the *concrete* ABC files are
>to be played, displayed, printed or analyzed is up to
>the end user. What the internal data format of the
>handling program should be, is up to the software
>developer and depends on the task at hand.

Sorry, I don't understand what you're trying to say here.
Are you suggesting that a standard can be developed
without giving any consideration to what it's going to
be used for?

Phil Taylor


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

Re: [abcusers] The abc standard

[Bernard Hill]

In message <[EMAIL PROTECTED]>, Phil Taylor
<[EMAIL PROTECTED]> writes
>Suggestions that we change the abc file extension to something other
>than .abc are kind of missing the point.  File extensions are irrelevant
>in Classic MacOS, so BarFly will open any text file, regardless of
>extension.  If the file contains any lines which start with X: it
>will treat what follows as an abc tune on request.
>
>Likewise, the oft-repeated suggestion that file headers should start
>with a version number which identifies the version of abc won't work
>either because users mostly won't bother.
>
>You have to remember that most users write their abc using a text editor.
>They make mistakes, and they leave things out.  Now you might say
>that programs should be strict about interpreting it, and point out
>the errors.  The problem there is that the net is full of erroneous
>abc, and if a program is too strict in it's interpretation, it's a
>pain in the arse to use, and users will choose to go elsewhere.
>
>So, interpreting abc is rather like interpreting a natural language.
>Whatever the standard says you have to bear in mind that this is a
>language which people use to communicate music to each other, with
>no computers involved (other than in the transmission part of the
>process).  For this reason, interpreting abc is much, much harder
>than interpreting MusicXML (despite the fact that MusicXML is a much
>more complete language).
>
>Phil Taylor

All good points. However it's when some peoplen use ~ to mean a roll and
others use it to mean a turn that there are problems. Of course you can
specify which you want with U: field but most examples I've seen don't.

I don't believe it's only the ~ which has a problem either...


Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

Re: [abcusers] The abc standard

[Laura Conrad]

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

Phil> Likewise, the oft-repeated suggestion that file headers
Phil> should start with a version number which identifies the
Phil> version of abc won't work either because users mostly won't
Phil> bother.

It won't work to require it, if for no other reason because of all the
millions of ABC files already there that don't have it, but if there's
software that gives some benefit to having it, people who want that
benefit will use it.

In lilypond it's optional, and most people who write their lilypond
from scratch in a text editor probably don't bother to use it, but if
you have it, and you want to convert from an earlier to a later
version of lilypond, convert-ly will use it.

And people like me who hardly ever write lilypond from scratch have
it, because abc2ly puts it there for us.

-- 
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] The abc standard

[Bernard Hill]

In message <[EMAIL PROTECTED]>, David Webber
<[EMAIL PROTECTED]> writes
>
>From: "Bernard Hill" <[EMAIL PROTECTED]>
>
>> I'm in a slightly worse position, Dave. Music Publisher 5's abc
>import
>> facility is almost at the finished stage and I don't want to undo
>any
>> code writing!
>
>I have made a lot of progress with MOZART's abc import, but as you
>indicate I still have a long way to go.  I am trying to steer clear
>of multipart files until a spec turns up.

Well I'm revealing no secret to say that that is also my intention.

>
>(MOZART's main difficulty is that it is fussy about the number of
>beats in a bar.  I know Music Publisher isn't.  There are swings and
>roundabouts - but given that a lot fo Chris Walshaw's first simple
>examples - an obvious place to start - do not respect the number of
>beats in a bar, I suspect you had an easier time of starting than I
>did.)

Perhaps so.

>
>> But the "23 different ways" is with us already it seems to me.
>> Downloading files from various sources on the net has given a LOT
>of
>> differences which can't all be correct at the same time.
>
>That is what I was afraid of.

Consider:

Is ~ a roll or a turn?

[..] is the symbol for a chord, but I've seen +..+ also used

Change of time sig (etc) can be done with [M:3/4] in the middle of a
line or M:3/4 on a line by itself. But I've seen music with M:3/4
without brackets in a mid-line.

My biggest wail is the end-of-line. The standard says that the end of
line is the end of music line (unless terminated with \ character). But
many tunes have silly numbers of bars, on a line, like 10,9,1 on 3
consecutive lines. Clearly needing relayout but then when to relayout a
line, when not?

>
>> I even asked
>> for advice from Chris Walshaw but no reply.
>
>Me too.  I gather he seems to have let go of abc.

That explains it. Although the courtesy of a reply would be nice.


Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

Re: [abcusers] The abc standard

[I. Oppenheim]

On Tue, 1 Jul 2003, Phil Taylor wrote:

> Have you ever used any other abc software?

Yep, under both Linux and Windows (I do not have a
mac). Currently I'm using mostly abcm2ps and abc2midi
with a midi player, sometimes I use nwc2abc.

> Are you suggesting that a standard can be developed
> without giving any consideration to what it's going
> to be used for?

It's going to be used to represent music scores in a
way both comprehensible by human beings and computer
parsers.

>From this it follows that the standard should define
(1) musical elements that the members of this list want
to be able to notate, in a way that is (2) convenient
for human beings to read and write and (3) for
computer systems to parse.

If these three concerns are addressed by the standard,
I do not see why it is important to know what happens
with the ABC code after it gets parsed.


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*

 Chazzanut Online:
 http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] the abc standard

[Henrik Norbeck]

So, let's get down to the real business now, instead of just saying 
how it should be, or what kind of person .
I suggest the following ABC standards committee with motivations 
why everyone is suggested. Comments and changes welcome, 
and those suggested are also welcome to say no.

Jef Moine (because of abcm2ps)
John Chambers (because of the tune finder, jcabc2ps, etc)
Phil Taylor (because of BarFly)
Henrik Norbeck (because of AbcMus and bnf spec)
Guido Gonzato (because of abcplus and lots of other stuff)

I suggest that if the committee cannot decide unanimously on 
parts of the standard, a majority vote is performed if we decide we 
really need that part of the standard.
Is there really any need for just one person who runs it? No. We 
can divide some hands-on tasks among the committee (e.g. 
Henrik writes the bnf spec).

Note that I have not included two people who have been important 
to abc development: Chris Walshaw and Jim Vint. I never see 
them discuss on this list, so I guess their current interest is 
minimal.


Henrik Norbeck, Stockholm, Sweden
[EMAIL PROTECTED]
http://www.norbeck.nu/ My home page
http://www.norbeck.nu/abcmus/  AbcMus player program
http://www.norbeck.nu/abc/ >1900 ABC tunes
http://www.norbeck.nu/blackthorn Irish trad music band
http://www.rfod.se/folklink/   Links to Swedish trad music
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] The abc standard

[I. Oppenheim]

On Tue, 1 Jul 2003, Bernard Hill wrote:

> Is ~ a roll or a turn?

According to ABC 1.7.6, it's a roll:

<<
$ The standard set of definitions (if you do not
$ redefine them) is:
$ U: ~ = !roll!
$ U: T = !trill!
$ U: H = !fermata!
$ U: L = !emphasis!
$ U: M = !lowermordent!
$ U: P = !uppermordent!
$ U: S = !segno!
$ U: O = !coda!
$ U: u = !upbow!
$ U: v = !downbow!
>>

If the user wants different behaviour, he can change
the definition.

> [..] is the symbol for a chord, but I've seen +..+ also used

The + notation has since long been deprecated.

> Change of time sig (etc) can be done with [M:3/4] in
> the middle of a line or M:3/4 on a line by itself.

correct.

> But I've seen music with M:3/4 without brackets in a
> mid-line.

incorrect. Should give either a warning or an error
message.

> My biggest wail is the end-of-line. The standard says
> that the end of line is the end of music line (unless
> terminated with \ character). But many tunes have
> silly numbers of bars, on a line, like 10,9,1 on 3
> consecutive lines. Clearly needing relayout but then
> when to relayout a line, when not?

All the standard says is : << Generally one line of abc
notation will produce one line of music, although if
the music is too long it will overflow onto the next
line.>>

So a newline does not force (but only suggests) a line
break, and it is up to the program to come up with a
sound layout algorithm.


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*

 Chazzanut Online:
 http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] The abc standard

[Henrik Norbeck]

Bernard Hill wrote:
> [..] is the symbol for a chord, but I've seen +..+ also used

+...+ for chords is obsolete long, long ago.
 
> Change of time sig (etc) can be done with [M:3/4] in the middle of a
> line or M:3/4 on a line by itself. But I've seen music with M:3/4
> without brackets in a mid-line.

That's probably because of the infamous line-breaking daemon. 
M:3/4 without brackets mid-line has never been supported by any 
abc application as far as I know.
 
> My biggest wail is the end-of-line. The standard says that the end of
> line is the end of music line (unless terminated with \ character). But
> many tunes have silly numbers of bars, on a line, like 10,9,1 on 3
> consecutive lines. Clearly needing relayout but then when to relayout a
> line, when not?

Also blame the infamous daemon! Much of the abc available on 
the web has been sent through e-mail at some time. You just 
have to have a user option for when to relayout line breaks.


Henrik Norbeck, Stockholm, Sweden
[EMAIL PROTECTED]
http://www.norbeck.nu/ My home page
http://www.norbeck.nu/abcmus/  AbcMus player program
http://www.norbeck.nu/abc/ >1900 ABC tunes
http://www.norbeck.nu/blackthorn Irish trad music band
http://www.rfod.se/folklink/   Links to Swedish trad music
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] The abc standard

[Calum Galleitch]

On Tuesday 01 July 2003 7:08 pm, Phil Taylor wrote:

> Sorry, I don't understand what you're trying to say here.
> Are you suggesting that a standard can be developed
> without giving any consideration to what it's going to
> be used for?

Essentially yes.  That's what W3C try to do with their web standards; they are 
trying to create data description systems that are totally device and usage 
independant, so that well written pages can be used in a device independent 
manner (speech readers and so forth are just the beginning).

I think the point is that ABC can be put to more uses than standards writers 
can think of, and if the standards writers are just active software 
developers, then a truly flexible and multi-purpose standard may not be 
attained.  WItness how HTML almost lost its semantic purpose in the face of 
the extension wars between Netscape and Explorer, because the people who were 
approving the standards at Netscape and Microsoft weren't interested in any 
of that; they just wanted to win a features war.

Which leads me nicely onto my thoughts on the subject...

It seems to me that their are several different competing uses for ABC as it 
stands.

There are the simple folk tune-swapping uses, where people even jot down ABC 
on scraps of paper (anyone else seen this practice, incidentally?); there are 
folk like Guido, who are trying to develop ABC into something that can take 
on Lilypond.  Us pipers could reel off (no pun intended) a dozen ideas that 
would make ABC easier for us, the early music people have their enhancements, 
and the microtonalists have been shoving their foot in the door as well.  
>From beginnings as a symbolic representation for diatonic music, ABC is 
becoming a tool for many diverse kinds of musician.

When you try and incorporate all these enhancements and not break backwards 
compatability, you end up creating a Frankenstein's monster (those who saw my 
attempt at typesetting piobaireachd will be nodding their heads here).

What I think is needed is a core language, (perhaps; this is an example only!) 
essentially ABC+ as implemented by abcm2ps.  On top of that, build some kind 
of scripting and pre-processing system with vast power.  Then take over the 
world.  Buahahaha.

Here's a sort of psuedoexample, in a kind of CSS(ish) notation, for the 
microtonal stuff that was discussed earlier:

"!#\n" { // Insert !#nn where nn is 1-6 for a range of pitch bend symbols
switch n
case n=1
  {
  draw
{
//draw routine
}
  sound
{
post_associate; //associate symbol with note after it
pitch_bend(10 cents)
}
case n=2
{
blah blah.  OK, perhaps a switch isn't the best way to do this, but never 
mind
}
  }

This isn't too far away from what some of us do with abcm2ps, adding lots of 
PostScript to create whatever it is our twisted needs demand.  The difference 
is this is designed to be extensible and comprehensible by different 
software.  The idea is that MagicABCPlayer doesn't pay any attention to the 
drawing instructions, and abcm2ps couldn't care less about what the pitch 
bend for the !#3 symbol is.

There could be a standard library of routines for different users; I'm 
thinking:

#include

and then instead of the standard ABC notation, we have a slightly simplified 
notation for pipers, where we use nine unique letters, and have capitals 
represent gracenotes:

a2 GDGEa>b HCDcEa

where we use H, I for high G and high A.  There could be a 
#include for refugees from that hideous pipe-music typesetting 
software.  It would be *really* cool to have an #include mode (three 
line staff in multiple colours)

There might be an #include.  #include, for fiddlers.  
#include would let music renderers like abcm2ps draw tab 
directly.  Got any ideas of your own?

This is thinking out loud sort of stuff, but I would suggest it offers a 
powerful way forward.

Some questions:

What is the purpose of ABC?  If the standard is too broad or too narrow, 
either ignoring V:,w:, or breaking existing implementations badly, then it is 
hardly any standard at all, as authors in HTML 3.2 might recall.  

Is it a description language, simply designed to describe monophonic melody 
lines, or maybe polyphony, if we push it?  Or is it a typesetting language, 
needing powerful customisation facilities?  Should we give up and say; this 
is silly.  You microtonalists should go and develop your own system, our's 
wasn't designed for the likes of you?  It's an option, though not one I think 
we need take too seriously.

If ABC is to be a serious attempt and contender at a come-all-ye, I think it 
needs some kind of ability to build powerfully beyond:

X:0
T:A Traditional Reel
agfa f2 ec | dcBd A2 Ac...

I know the quickfire response to this is "Well then, get writing!"  I'm no 
coder (Dilbert fans can call me the ideas rat), nor do I have a clear idea of 
exactly how what I'm driving at should work, though the above is a starting 
point.  There are better mi

Re: [abcusers] The abc standard

[John Chambers]

I. Oppenheim writes:
| On Tue, 1 Jul 2003, Bernard Hill wrote:
|
| > Is ~ a roll or a turn?
|
| According to ABC 1.7.6, it's a roll:

Of course, a lot of people would ask "What's the difference?" ;-) And
a  lot  of  arrogant  musicians  (like me) would say "Who cares?" and
interpret it as a suggestion to ornament the note,  deciding  on  the
spur of the moment what ornament to play.

| The + notation has since long been deprecated.

Which does remind me of a suggestion I've long thought of making: Any
Baroque  musician  is familiar with the convention that a '+' above a
note means "Ornament this note somehow".  It's a generic,  unspecific
ornament symbol. I personally would like it to mean this in abc. This
really just means that '+' would be added to  the  list  of  ornament
symbols, and the default display form is merely a '+' above the note.
It should be definable, of course.  And a clever abc  player  program
could pick a random ornament from its repertoire.

Of course, a really clever player program  could  do  this  with  any
ornament  symbol, preferably looking at the note's length and picking
an ornament that fits within that length.  Then the program would  be
approaching the level of an arrogant musician.


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

Re: [abcusers] The abc standard

[I. Oppenheim]

On Tue, 1 Jul 2003, John Chambers wrote:

> This really just means that '+' would be added to the
> list of ornament symbols, and the default display
> form is merely a '+' above the note.

Something like:
U: X = "^+" ?


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*

 Chazzanut Online:
 http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

[abcusers] + symbol

[Henrik Norbeck]

John Chambers wrote:
> > This really just means that '+' would be added to the
> > list of ornament symbols, and the default display
> > form is merely a '+' above the note.
Irwin Oppenheim wrote:
> Something like:
> U: X = "^+" ?

Or rather
U: +="^+"

But I think we should reserve +, which is one of the few unused 
characters in abc, for some important purpose.
We only have a few unused ascii characters in the abc code:
@#$&?+;`
(note that some of these are used in for example w: lines)
The following are used:
space, a-z, A-Z, 0-9, ! " ' % / \ ( ) { } [ ] | < > - _ ~ * . , : ^ =
BTW, is * considered obsolete abc nowadays?


Henrik Norbeck, Stockholm, Sweden
[EMAIL PROTECTED]
http://www.norbeck.nu/ My home page
http://www.norbeck.nu/abcmus/  AbcMus player program
http://www.norbeck.nu/abc/ >1900 ABC tunes
http://www.norbeck.nu/blackthorn Irish trad music band
http://www.rfod.se/folklink/   Links to Swedish trad music
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

[abcusers] Abc levels

[I. Oppenheim]

On Tue, 1 Jul 2003, Calum Galleitch wrote:

> There could be a standard library of routines for
> different users; I'm thinking:
>
> #include. There might be an
> #include.  #include, for
> fiddlers.  #include would let music
> renderers like abcm2ps draw tab directly.  Got any
> ideas of your own?

The standard committee could decide to define various
levels of the ABC language, each which its own features
set.

In the version field, one could then define the ABC
level that is used: 2M for microtonality, 2B for
bagpipes, 2G for guitar tabs, 2GM for microtonal
guitar music, etc.

Software that doesn't want to deal with microtonality
or bagpipes etc. could decide not to implement these
ABC levels, and to give a message if it encounters a
file that is written in such a level of ABC.

In this scheme a software package could decide to
implement a minimal amount of ABC if that's all what's
needed, and still be standard complying.


 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*

 Chazzanut Online:
 http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] The abc standard

[John Chambers]

Irwin Oppenheim wrote:
| On Tue, 1 Jul 2003, John Chambers wrote:
|
| > This really just means that '+' would be added to the
| > list of ornament symbols, and the default display
| > form is merely a '+' above the note.
|
| Something like:
| U: X = "^+" ?

No, more like:

... | fe +d2 | c4 |]

where the d has a '+' drawn above the note head.  Of course, for  the
benefit  of  people  who  want to make the music a bit more specific,
they could add

U: + = trill

to the headers, and then they'd get the "Tr" ligature above the  note
head.   That  would  satisfy Romantic-era musicians, who mostly don't
know this notation.  But Baroque musicians would of course  sneer  at
that,  and prefer the plain '+' that doesn't presume to tell them how
to ornament the note.

(Then they'd complain about ABC's lack of all those  overly-intricate
ornaments that some Baroque composers liked to use.  ;-)

I just thought that we could get '+' added to the  list  of  official
ornament  symbols  before it gets gobbled up for some other use.  And
then, if you don't see the point in that notation, you can  use  a  U
line  to use it for something else.  There are lots of potential uses
of '+' in musical notation.  Maybe you'd like it for  a  quarter-tone
sharp sign. (I've seen people use '+' this way. It makes sense, since
visually '+' is half of a '#'.   But  this  visual  metaphor  doesn't
extend to quarter-tone flats.)


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

Re: [abcusers] + symbol

[I. Oppenheim]

On Tue, 1 Jul 2003, Henrik Norbeck wrote:

> We only have a few unused ascii characters in the abc code:
> @#$&?+;`

& is used to do voice splitting in abcm2ps

> BTW, is * considered obsolete abc nowadays?

What should it do (outside a w: line)?


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*

 Chazzanut Online:
 http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

[abcusers] 1.7 standard

[Jack Campin]

> What the abc 'movement' needs is someone who takes
> responsibility over the standard. Personally, I would
> propose Jef Moine and Guido Gonzato: Jef because he's
> the developer of the (TMHO) leading abc package,
> Guido Gonzato because of his vision and his
> dedication.

What package(s) does Guido use?

At present, we have:

* four mature systems representing three different sorts of software
  (ABCMus for playback, abcm2ps for staff notation, BarFly/Muse for
  both) - of these all but abcm2ps are broadly compatible;

* several systems in various stages of development (Skink, PalmOS
  implementations, Bryan Creer's Noteworthy translator, perhaps
  half a dozen more) which implement most of 1.6 and whichever other
  ideas float the developer's boat and they manage to find time to
  work on;

* four moribund systems which are still widely used (ABC2WIN, abcps,
  abcmidi, and abc2mtex).

The kicker is Muse.  At some point somebody else is going to revive
it, and the job shouldn't be made gratuitously difficult by insisting
that it should be another abcm2ps when it was designed with entirely
different and very well-thought-out goals.  It's a major implementation
with years of work behind it and mustn't be wasted.

Insisting that all of abcm2ps's features have to go in the standard
makes it unimplementable for anybody whose goals include generating
actual sound in some form and making every ABC construct correspond
to a sonic entity.  A standards commitee will have to say NO to most
of those new features - da capo, say - until they are defined in such
a way as to make them implementable on other platforms.

-
Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760
 * food intolerance data & recipes,
Mac logic fonts, Scots traditional music files, and my CD-ROM "Embro, Embro".
--> off-list mail to "j-c" rather than "abc" at this site, please <--


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

Re: [abcusers] the abc standard

[Forgeot Eric]

> responsibility over the standard. Personally, I would
> propose Jef Moine and Guido Gonzato: Jef because he's

I think it's a good idea, if they agree of course ;)
I think also of John Chamber.

>Just one comment: having a software developer in charge of
standards is
>a conflict of interests. S/he can drive the standard in the
direction 
>of his/her own software.

Since Jeff has included so usefull features in Abcm2ps, and
developped some "unofficial" (but yet accepted) notations (such as
the multiple voices) because the 1.6 standard hadn't evolved at
all, it wouldn't be a problem if the new standard would include
parts of what he did in Abcm2ps. 
I don't think I would have been interested to retranscribe so many
ancient music tunes if Jeff hadn't extended more possibilities to
the abc format. 


>We recently had a brief discussion of some notation  for 
traditional
>Persian music. Though I don't play that myself, I do have a
number of
>recordings, and I found the  discussion  interesting.

I think for this kind of music, or the "special" less used
features (quartertone, microtone), they should remain included in
some %% command so it wouldn't confuse old applications, or
softwares whose developpers don't wish to include those features
in them.
I know also some applications crash when they recognize something
they don't understand. With %% command, they just ignore this.

>Yeah, and I'd like to add that we also shouldn't have a  musician
 in
>charge  of  the  standard,  since  s/he can drive the standard in
the
>direction of his/her own favorite musical styles.

I propose myself for this, and since Metal is one of my favorite
(folk-metal etc.), I'll add nice and usefull feature in the
standard :

With new fields and commands such as :

Q:4/4=very very fast
R:Broken triple kick drum
K:disharmonical
K:detuned
W:[screamed]:
D:"best of"
%%ultraoverdrive
%%distortion
%%MIDI control 7 9500


I haven't included them yet in my metal conversions :), but more
seriously it's still possible to render in abc some tunes created
by metal musicians :

http://anamnese.online.fr/abc/metal.abc
(some tunes are not finished to transcribe yet)


ps : about what Phil Taylor as added recently, I think he's not
wrong, even if I didn't notice than this list was dominated by the
Abcm2ps corporation :)

>I don't think such a person exists.  It's a job for a committee.

It's what was proposed. 

If you think you could fit also in this committee, I believe you
could do this job well. I read what you wrote about multivoice,
and used it when I begun to learn about it.
But the committee shouldn't involve too many pple, otherwise they
will never agree and things will never take a step further.

About looking for full range notation for such a "little" format,
it'd be difficult to let it be able to notate all. Coming again on
abcm2ps, I find it suits all my need (when I use it with
Abc2midi), it's still very powerfull in its present form. I've
never be able to enter efficiently notes with a mouse, so I like
to type them instead. I use it also to write folk tune when I
don't have any computer at hand.
If I'd feel the need to use a all in one software with many
specific notations and effect I think I'll look toward software
that handle xml for ex. The output format is "impossible" to read
by human, but it's not restricted. A format such as abc, even if
it's wonderfull and I don't wish to use another one, will always
be limited in comparison to MusicXML. 


>In fact in my opinion NO program should break
> backward compatibility!

It's also a reason why I advocate for the use of %% for new
features. 

>and .abc files written to the old 1.6 standard, the question is
what
>the old apps do when they meet one of the new files.  AFAIK there

I think it'd be difficult to avoid notation such as the x for the
invisible rests... I don't think it would be used in folk tune for
ex. so only tunes with "heavy needs" would need this, that mean
they would include also V: and other unsupported features in old
app.


>>It is a very good idea to add an ABC version field to
>the header, to distinguish old ABC from new ABC.

I think it's a good idea too, and I'm willing to do it for abc
following the "Abcplus" extentions, or not in the 1.6 standard (or
at least try to do my best to find them all)


___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] The abc standard

[Bernard Hill]

In message <[EMAIL PROTECTED]>, John Chambers
<[EMAIL PROTECTED]> writes
>I. Oppenheim writes:
>| On Tue, 1 Jul 2003, Bernard Hill wrote:
>|
>| > Is ~ a roll or a turn?
>|
>| According to ABC 1.7.6, it's a roll:
>
>Of course, a lot of people would ask "What's the difference?" ;-) And
>a  lot  of  arrogant  musicians  (like me) would say "Who cares?" and
>interpret it as a suggestion to ornament the note,  deciding  on  the
>spur of the moment what ornament to play.

A roll can mean quite a different thing to (eg) a dulcimer or auto-harp
player and the playback would be totally different.

>
>| The + notation has since long been deprecated.
>
>Which does remind me of a suggestion I've long thought of making: Any
>Baroque  musician  is familiar with the convention that a '+' above a
>note means "Ornament this note somehow".  It's a generic,  unspecific
>ornament symbol. I personally would like it to mean this in abc. This
>really just means that '+' would be added to  the  list  of  ornament
>symbols, and the default display form is merely a '+' above the note.

That's available with "^+" notation. The ".." is for text and the ^ says
"it's not a chord symbol but the text which follows, ie a +

And I feel that if there is music out there using +..+ for chords then
you are confusing the isue.

>It should be definable, of course.  And a clever abc  player  program
>could pick a random ornament from its repertoire.

I take it that's a joke? :-)

>
>Of course, a really clever player program  could  do  this  with  any
>ornament  symbol, preferably looking at the note's length and picking
>an ornament that fits within that length.  Then the program would  be
>approaching the level of an arrogant musician.

:-)


Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

Re: [abcusers] The abc standard

[Bernard Hill]

In message <[EMAIL PROTECTED]>, John Chambers
<[EMAIL PROTECTED]> writes
>Irwin Oppenheim wrote:
>| On Tue, 1 Jul 2003, John Chambers wrote:
>|
>| > This really just means that '+' would be added to the
>| > list of ornament symbols, and the default display
>| > form is merely a '+' above the note.
>|
>| Something like:
>| U: X = "^+" ?
>
>No, more like:
>
>... | fe +d2 | c4 |]
>
>where the d has a '+' drawn above the note head.  Of course, for  the
>benefit  of  people  who  want to make the music a bit more specific,
>they could add
>
>U: + = trill

Shouldn't that be

U:+=!trill!

?

>
>to the headers, and then they'd get the "Tr" ligature above the  note
>head.   That  would  satisfy Romantic-era musicians, who mostly don't
>know this notation.  But Baroque musicians would of course  sneer  at
>that,  and prefer the plain '+' that doesn't presume to tell them how
>to ornament the note.
>
>(Then they'd complain about ABC's lack of all those  overly-intricate
>ornaments that some Baroque composers liked to use.  ;-)
>
>I just thought that we could get '+' added to the  list  of  official
>ornament  symbols  before it gets gobbled up for some other use.  And
>then, if you don't see the point in that notation, you can  use  a  U
>line  to use it for something else.  There are lots of potential uses
>of '+' in musical notation.  Maybe you'd like it for  a  quarter-tone
>sharp sign. (I've seen people use '+' this way. It makes sense, since
>visually '+' is half of a '#'.   But  this  visual  metaphor  doesn't
>extend to quarter-tone flats.)
>


Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

Re: [abcusers] The abc standard

[Bernard Hill]

In message <[EMAIL PROTECTED]>, Henrik
Norbeck <[EMAIL PROTECTED]> writes
>Bernard Hill wrote:
>> [..] is the symbol for a chord, but I've seen +..+ also used
>
>+...+ for chords is obsolete long, long ago.

Great. But does that mean there's no music out there with +..+?
> 
>> Change of time sig (etc) can be done with [M:3/4] in the middle of a
>> line or M:3/4 on a line by itself. But I've seen music with M:3/4
>> without brackets in a mid-line.
>
>That's probably because of the infamous line-breaking daemon. 
>M:3/4 without brackets mid-line has never been supported by any 
>abc application as far as I know.
> 
>> My biggest wail is the end-of-line. The standard says that the end of
>> line is the end of music line (unless terminated with \ character). But
>> many tunes have silly numbers of bars, on a line, like 10,9,1 on 3
>> consecutive lines. Clearly needing relayout but then when to relayout a
>> line, when not?
>
>Also blame the infamous daemon! Much of the abc available on 
>the web has been sent through e-mail at some time. You just 
>have to have a user option for when to relayout line breaks.
>

Funny enough, that's what I've done. I've also given the user the code
to edit (and optionally save) if s/he wants before the Import process.


Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

Re: [abcusers] The abc standard

[David Webber]

From: "Bernard Hill" <[EMAIL PROTECTED]>

> Consider:
> Is ~ a roll or a turn?

It was so vague in the origibnal spec that I was considering
ignoring it :-)

> [..] is the symbol for a chord, but I've seen +..+ also used

[ ]  is what the spec says and so that is what I have implemented.
Is ++ written down anywhere?

> Change of time sig (etc) can be done with [M:3/4] in the middle of
a
> line or M:3/4 on a line by itself. But I've seen music with M:3/4
> without brackets in a mid-line.

The original spec seems a bit loose about whether M:3/4 needs a line
to itself - I am *trying* not to make assumptions about it.

> My biggest wail is the end-of-line. The standard says that the end
of
> line is the end of music line (unless terminated with \
character). But
> many tunes have silly numbers of bars, on a line, like 10,9,1 on 3
> consecutive lines. Clearly needing relayout but then when to
relayout a
> line, when not?

I'm thinking about that one. the easiest thing with MOZART is just
to ignore abc's end of lines and let it reformat - it does that
anyway as bars grow and shrink.  Alternatively I could put a hard
line break where abc lines change - I'll suck it and see.

MOZART is quite accustomed to doing a lot of formatting itself and
by default after MIDI import it reformats absolutely everything as
MIDI contains no format information.  So I'm heading at things
backwards with MOZART by letting it do all its own formatting, and
gradually telling it to respect more of the contents of the abc
file.

Dave
David Webber
Author of MOZART the music processor for Windows -
http://www.mozart.co.uk
Member of the North Cheshire Concert Band
http://www.northcheshire.org.uk

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

Re: [abcusers] The abc standard

[Bernard Hill]

In message <[EMAIL PROTECTED]>, I. Oppenheim
<[EMAIL PROTECTED]> writes
>On Tue, 1 Jul 2003, Bernard Hill wrote:
>
>> Is ~ a roll or a turn?
>
>According to ABC 1.7.6, it's a roll:
>
><<
>$ The standard set of definitions (if you do not
>$ redefine them) is:
>$ U: ~ = !roll!
>$ U: T = !trill!
>$ U: H = !fermata!
>$ U: L = !emphasis!
>$ U: M = !lowermordent!
>$ U: P = !uppermordent!
>$ U: S = !segno!
>$ U: O = !coda!
>$ U: u = !upbow!
>$ U: v = !downbow!
>>>
>
>If the user wants different behaviour, he can change
>the definition.

As long as he knows how. Can I ask how many abc users are used to
editing the language, or do they just use it to print/play tunes on the
net?

>
>> [..] is the symbol for a chord, but I've seen +..+ also used
>
>The + notation has since long been deprecated.
>
>> Change of time sig (etc) can be done with [M:3/4] in
>> the middle of a line or M:3/4 on a line by itself.
>
>correct.
>
>> But I've seen music with M:3/4 without brackets in a
>> mid-line.
>
>incorrect. Should give either a warning or an error
>message.
>
>> My biggest wail is the end-of-line. The standard says
>> that the end of line is the end of music line (unless
>> terminated with \ character). But many tunes have
>> silly numbers of bars, on a line, like 10,9,1 on 3
>> consecutive lines. Clearly needing relayout but then
>> when to relayout a line, when not?
>
>All the standard says is : << Generally one line of abc
>notation will produce one line of music, although if
>the music is too long it will overflow onto the next
>line.>>
>
>So a newline does not force (but only suggests) a line
>break, and it is up to the program to come up with a
>sound layout algorithm.

But I take it that the sentence above means that it WILL break at a line
end and MAY break elsewhere...

The problem as a developer is that we're second-guessing writers of
"bad" abc notation.


Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland

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

[abcusers] Line breaks

[I. Oppenheim]

On Tue, 1 Jul 2003, Bernard Hill wrote:

> >All the standard says is : << Generally one line of abc
> >notation will produce one line of music, although if
> >the music is too long it will overflow onto the next
> >line.>>

> But I take it that the sentence above means that it
> WILL break at a line end and MAY break elsewhere...

Maybe you're correct on that.

> The problem as a developer is that we're
> second-guessing writers of "bad" abc notation.

Anyway, I think it's a better approach to let the
software do the formatting of the music lines unless
the user forces a line break, with for example the "!"
notation found in the BNF standard. In general,
software should not assume that an ABC file was meant
to be print so it would bad to give to much weight to
the exact position of newlines in the file.


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*

 Chazzanut Online:
 http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] Accented characters in lyrics (abc2ps)

[Bert Van Vreckem]

Jack Campin wrote:
I just plop the characters i want in the abc file, like, for example:
 z D   E | G2  G G2  F  | E2  E z  F   G | A2   G (FE)   D |  F2 E
w: v-  o   et  por- que jus-  ti- a  t-  en d'el et  de-* rei-  tu-ta,
I use jcabc2ps to render the file, but any program should be able to 
handle this.
Are we to assume there were some non-ASCII characters in there?  My mail
client didn't show any, which kinda points to the problem with that...
High-bit characters also map onto different things in different systems.
Indeed. Nowadays, there are two major standards for (internationalised) 
text encoding: ISO-8859 and ISO-10646 (Unicode). The former is an 8 bit 
encoding. That means that every character is encoded with 8 bits, so you 
can encode 2^8 = 256 characters. The first 128 are the same as in the 
old ASCII standard, but the others vary. There's a few different 
ISO-8859 encodings for different languages. ISO-8859-1 (a.k.a. Latin-1) 
 is for Western European languages, ISO-8859-4 for baltic languages, 
ISO-8859-5 for Cyrillic, etc. This is a problem: you can't put Hebrew 
text (ISO-8859-8) in the same file as Lithuanian (ISO-8859-4). 
Furthermore, as we saw in the example above, you can't reliably share 
the file with other people.

A Unicode character is (theoretically) 16 bits, giving 2^16=65536 
possible combinations. This is the emerging standard for text encoding, 
as it is universal: every language can be encoded with Unicode and the 
file should look the same on *any* computer.

:> To use accented letter, type the following:
:> \`a  => "a with grave" [...]
:> \~n  => "n with tilde"
It would be far more partable if ABC software used HTML standards
for this and deprecated TeXisms.  TeX is never going to get wider
use; HTML/XML/XHTML is where all the development is going on and
there are far more machines out there with installed software that
uses it.  And it seems it's increasingly going to be built into
the OS with Windows (not in itself any bad thing regardless of the
sleazy politics involved).
Both the TeX and *ML syntax is fine by me, but you're also limited here! 
Which characters will you support? How do you encode Cyrillic lyrics? 
For people that transcribe Russian folksongs, a lyrics line consisting 
only of stuff like &shcha; or \yu (or whatever code you'd define) just 
doesn't cut mustard.

: What's wrong with simply putting the correct accent in the text?
: They're all part of the extended character set, and pretty much a
: standard these days.
What standard?  I got an emailed document from a Word for Windows
user today that had a whole pile of n-tildes in it (hex 96, decimal
150).  They were presumably typed by that pathetic slave of Satan
with the intention that they should be some sort of punctuation or
bullet character, but I've no idea what.
That's *yet* another problem: probably you just don't have the font that 
the sender used in his document... You can save a font inside a Word 
document so anyone should be able to read it correctly, but I don't 
remember how. A printable document should be sent in PDF or PostScript 
format, at least an open standard. MS Office is neither open, nor a 
standard.

Many editors (at least on the Mac) can translate the local character
set to HTML, so there's no need ever to ship non-portable forms to
other people who might have different platforms, however convenient
the type-it-straight-in approach might be for you.
But lyrics in non-latin character sets become totally unreadable.

I think the ultimate, definite, best way is supporting Unicode. Mind 
you, I wouldn't deprecate the TeX codes in the near future and the 
proposed *ML encoding seems interesting too.

cheers,

bert

--
Bert Van Vreckem
Not all chemicals are bad. Without chemicals such as hydrogen and
oxygen, for example, there would be no way to make water, a vital
ingredient in beer. -- Dave Barry
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] The abc standard

[Forgeot Eric]

>Jef Moine (because of abcm2ps)
>John Chambers (because of the tune finder, jcabc2ps, etc)
>Phil Taylor (because of BarFly)
>Henrik Norbeck (because of AbcMus and bnf spec)
>Guido Gonzato (because of abcplus and lots of other stuff)

I agree to this choice

> #include. There might be an
> #include.  #include, for
/.../
>In the version field, one could then define the ABC
>level that is used: 2M for microtonality, 2B for
/.../
>Software that doesn't want to deal with microtonality
>or bagpipes etc. could decide not to implement these
/.../
>In this scheme a software package could decide to
>implement a minimal amount of ABC if that's all what's
>needed, and still be standard complying.

I think it's a very good idea, if it's not too complicated to set
up. I'm afraid also some old softwares may not interpret correctly
the #include command (why not %%include then) but it's still
possible to have a preprocessor such as abcpp to remove them for
such software.


> four moribund systems which are still widely used (ABC2WIN,
abcps,
>  abcmidi, and abc2mtex).

abcmidi ? moribund ? It handles well all of my abc. I like AbcMus,
but I'm "forced" to use abcmidi because it handles better the
%%midi commands (for different octaves in different voices for
ex.)



___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] the abc standard

[John Chambers]

Forgeot Eric mentioned:
|
| I think it'd be difficult to avoid notation such as the x for the
| invisible rests... I don't think it would be used in folk tune for
| ex. so only tunes with "heavy needs" would need this, that mean
| they would include also V: and other unsupported features in old
| app.

Actually, I find the  y  "invisible,  unplayed"  rest  more
useful.  For example, if you want the somewhat conventional
comma-like phrasing/breath mark  above  the  staff,  abc2ps
produces a fine result if you write
  ","y

This positions the symbol properly between two  notes,  and
adds a bit of extra space.

There are a  number  of  abc  thingies  that  can  only  be
produced  above/below  a  "note".  Rests are quite sensibly
counted as notes by most progams, so  you  can  gedt  those
thingies isolated by attaching them to a rest.  A rest that
is otherwise ignored is a very good tool for this.

This is a bit of a kludge ...



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

Re: [abcusers] the abc standard

[Bert Van Vreckem]

Henrik Norbeck wrote:
So, let's get down to the real business now, instead of just saying 
how it should be, or what kind of person .
I suggest the following ABC standards committee with motivations 
why everyone is suggested. Comments and changes welcome, 
and those suggested are also welcome to say no.
>
Jef Moine (because of abcm2ps)
John Chambers (because of the tune finder, jcabc2ps, etc)
Phil Taylor (because of BarFly)
Henrik Norbeck (because of AbcMus and bnf spec)
Guido Gonzato (because of abcplus and lots of other stuff)

I suggest that if the committee cannot decide unanimously on 
parts of the standard, a majority vote is performed if we decide we 
really need that part of the standard.
Is there really any need for just one person who runs it? No. We 
can divide some hands-on tasks among the committee (e.g. 
Henrik writes the bnf spec).
I am against the idea of a committee without a leader. The end 
responsibility should be with one person only. The previous attempt did 
not work out and I don't see any reason why it should now. To put it to 
the extreme: a benevolent dictator will be infinitely more beneficial to 
the abc community than a democratic body of people that will never agree 
on everything (if anything at all)...

The committee in itself is a good idea (and all the people Henrik 
mentioned deserve to be part of it (sorry for not mentioning you in my 
original posting, lads)), but if we want the standard to go forward, 
there should be only one leader... Let´s get over our fear that our 
favourite non-standard feature will not be included in a future 
standard. Leaders of open-source projects are generally also very open 
minded and I´m sure all the ´papabiles´ mentioned above are no exceptions.

bert

--
Bert Van Vreckem
Not all chemicals are bad. Without chemicals such as hydrogen and
oxygen, for example, there would be no way to make water, a vital
ingredient in beer. -- Dave Barry
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] The abc standard

[John Chambers]

Bernard Hill writes:
| >
| >U: + = trill
|
| Shouldn't that be
|
| U:+=!trill!
|
| ?

Well, we've had a bit of a discussion of that.  It  seems  that  some
people  would  agree  with  you, while some others would vociferously
disagree.  There seems to be abc around that use both syntaxes.   I'd
suppose that the answer would be that the bangs are optional.

One question is whether there are examples where it actually makes a difference.
If the U line allows for arbitrary text substitution (as the C #define
does), then there is a difference.  One might like to define something
like:


U: R=!segno!|:

That is, the symbol expands to a string that includes  an  annotation
plus  some other symbol.  If U defines simple string substitutions, I
don't see any reason not to expect such definitions. I know that in C
this sort of thing is quite useful.

OTOH, we could both allow this, and also allow dropping the bangs for
the case of standard musical symbols.

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

Re: [abcusers] The abc standard

[I. Oppenheim]

On Wed, 2 Jul 2003, John Chambers wrote:

> I'd suppose that the answer would be that the bangs
> are optional.

I'm not sure that this will always work. For example:

A!1!B  versus A1B

and even

AaccentB

could be difficult to parse, since a c and e are valid
note names. Many parser systems like yacc or bison
won't like this.

So why not stick to the bangs to keep these things
a little clean? Or did I miss something?


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*

 Chazzanut Online:
 http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] The abc standard

[John Chambers]

| >Jef Moine (because of abcm2ps)
| >John Chambers (because of the tune finder, jcabc2ps, etc)
| >Phil Taylor (because of BarFly)
| >Henrik Norbeck (because of AbcMus and bnf spec)
| >Guido Gonzato (because of abcplus and lots of other stuff)
...
| > four moribund systems which are still widely used (ABC2WIN,
| abcps,
| >  abcmidi, and abc2mtex).
|
| abcmidi ? moribund ? It handles well all of my abc. I like AbcMus,
| but I'm "forced" to use abcmidi because it handles better the
| %%midi commands (for different octaves in different voices for
| ex.)

Yeah; can we find the caretakers for these packages and invite
them to the party?


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

Re: [abcusers] The abc standard

[John Chambers]

I. Oppenheim writes:
| On Wed, 2 Jul 2003, John Chambers wrote:
| > I'd suppose that the answer would be that the bangs
| > are optional.
|
| I'm not sure that this will always work. For example:
|
| A!1!B  versus A1B
|
| and even
|
| AaccentB
|
| could be difficult to parse, since a c and e are valid
| note names. Many parser systems like yacc or bison
| won't like this.
|
| So why not stick to the bangs to keep these things
| a little clean? Or did I miss something?

I don't think you missed anything. I basically agree, but I'd like to
hear arguments for the other side.

Actually, my main reasoning is that of  a  programmer:   If  we  want
everyone  to  implement  this  U:   header, it should be as simple as
possible.  A string substitution is about as simple as it  gets,  and
very easy to implement in just about any language. And it's very easy
for users to learn.  This by itself seems to be enough to argue for

U: t=!trill!

as the only syntax.  Then there's just an expansion pass, followed by
a parse by a routine that expects all those !...! terms.  The builtin
ornaments can generally be handled  easily  by  setting  them  up  as
compiled-in substitutions. If we have a separate %include gimmick, we
can easily provide some packaged definitions for different  kinds  of
music.

Still, I always think I might have missed something, so we should see
if anyone else wants to argue for a different approach.


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

[abcusers] Abc Applications again

[Frank Nordberg]

Just wanted to let you know that the ABC applications database is now 
updated (or will be in a few minutes at least - uploading as I write this).

It's two days later than I originally planned. The reason is that I 
decided I wanted the update as a "Today's Feature" at Musica Viva, and 
July 2nd was the first available opening I had for that. That ought to 
give ABC some more recognition among the ignorami (or however you spell 
it?) and maybe win over some new converts to out true and just case! ;-)

Anyway, thanks to everybody who contributed to this update, and to 
everybody who has posted and/or will post their comments!

Frank

P.S. In case anybody's forgotten already, the URL is: 
http://www.musicaviva.com/abc/abcapps/index.tpl

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

[abcusers] My point of view on the abc standard

[Guido Gonzato]

On Tue, 1 Jul 2003, I. Oppenheim wrote:

> So, Jef and Guido, what do you think? Are you willing
> to discuss your ideas with us?

I'll just give you my point of view. Since the latest draft three years
ago, the so called 'committee' hasn't produced a single line of text;
please correct me if I'm wrong. In the meantime, skilled developers like
Jean-François quietly kept on working. As a result, we now have abcm2ps,
which is arguably one of the best (_the_ best?) music typesetters on
earth. Seymour Shlien has resumed working on the abcMIDI suite, adding
many changes that make it more compatible with abcm2ps. Phyl Tailor
enhanced his wonderful BarFly - too bad it's neither free nor
multiplatform. On my part, I wrote abcpp which allows me to write portable
ABC files; and managed to convince Joerg Anders to add ABC support in
NoteEdit...

We're almost there. I'm finishing a document I named "A proposal of ABC
2.0.0 standard"; it includes the latest 1.7.6 draft (verbatim), and adds
the least common denominator of multivoice support, low level details
(e.g. %%stuff), portability issues, some ABC examples, and so on. Then I
point out that there are details that inherently only make sense in
printed music, others in played music; I'm covering those too.

I'm also working on extending my manual "Typesetting Music wit ABC", that
some of you liked so much - thank you for the nice words! - to change it
so that it's called "Writing Music with ABC". That is, I'm adding a second
part covering playing ABC files in addition to typesetting them.

In my humble opinion, when we have an ABC typesetting and an ABC player
application that are powerful, free, multiplatform, and compatible with
each other, we automatically have a 'de facto' standard. At that point,
other applications will have better try and follow the new standard for
their own good.

I'll say that again, we are almost there! Seymor is working on some
details I reported to him; when he's done, abcm2ps and abc2midi will
support virtually the same ABC (2?) syntax.

To sum up, call me the coordinator if you wish; but bear in mind that
you're free to toss my work and dedication out of the window if you wish,
I'll not get upset. I just believe that with a bit of coordination - I did
nothing more than this - we'll soon have the new standard.

My .02 Ec.

Ciao,
 Guido =8-)

-- 
Guido Gonzato, Ph.D.  - Linux System Manager
Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN.
Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy)
Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri

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

[abcusers] How to get the pound sign

[Guido Gonzato]

On Tue, 1 Jul 2003, John Chambers wrote:

> | ... and what's the \?? code for £ anyway ?
> 
> \163

yes - in decimal. But you must use base 8 (octal): to get the pound sign
you'll have to write \243. Try with abcm2ps:

X: 1
T: These are UK pounds: \243 \243 \243
M: 4/4
L: 1/4
K: C
%
CDEF|GABc|cdef|gabc'|


Ciao,
 Guido =8-)


-- 
Guido Gonzato, Ph.D.  - Linux System Manager
Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN.
Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy)
Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri

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

Re: [abcusers] The abc standard

[Ulf Bro]

> It is a very good idea to add an ABC version field to
> the header, to distinguish old ABC from new ABC.

Jawohl !!!

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