Re: [abcusers] Re: Bryan Creer (?)

[John Chambers]

Toby Rider wrote:
|
| > Apart from that, I've spent the last year studying for an MSc in
| > Computing in Archaeology which has kept me fairly busy.  For an idea
| > of what I've been up to have a look at -
| > http://www.bryancreer.com/Castle.html
|
| You're an academic Bryan? And to think that I respected you up until
| this point! :-)

Hmmm ...  I see conflicting evidence here.  If he's an  academic,  he
should be completely at home with no-holds-barred discussions. Things
like misattribution of quotes, quoting out of  context,  and  blatant
misrepresentation  of  others' ideas are the order of the day in most
of academia, and especially in fields such as archaeology.

So why would Bryan be bothered when relative  amateurs  as  musicians
and software geeks do the same sort of thing? You'd think he wouldn't
even notice such things, familiar as he must be with  them  from  his
academic life.

After getting some Math and  Comp  Sci  degrees,  I  hung  around  in
academia  for  a  decade working on a couple of interesting projects.
Then I decided to join the Real World. It took several years to learn
how  to  deal with the easily-bruised egos in that you find there.  I
still tend to think of business folks as utter wimps compared to  the
folks in academia. I've come to appreciate this as one of the reasons
that we have such crappy commercial software. It was all developed in
an  environment  where  even  the most carefully-phrased criticism or
warning causes panic and a desire to  quiet  the  complainer,  rather
than arguing back.  They'd never survive a week in academia.  ;-)

Then there's the way that musicians normally treat each other ...

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

Re: [abcusers] Bryan Creer (?)

[John Chambers]

Phil Taylor writes:
| On 30 Nov 2004, at 06:52, Don Whitener wrote:
| > I have been out of touch lately, so I offer my sincere apologies
| > should I blunder onto any toes.  So far as I can tell, Bryan Creer has
| > not posted to this group since early August 2003... Has he dropped out
| > for a while?
|
| He does rather tend to drop out for long periods of time, then return
| to start a mighty argument.
| You may find him at [EMAIL PROTECTED]

Maybe we should invite him  back.   I've  always  sorta  enjoyed  the
discussions that he started.  And it's been quiet around here lately,
too quiet ...

;-)

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

Re: [abcusers] [ABCp] Decoration J

[John Chambers]

Remo D. asks:
| I still have to fix parts and continuations with the latest suggestion
| but there's something else that I can do very quickly: can anyone tell
| me what the decoration "J" is?

In abc2ps, it produces the short diagonal line to the lower left
of a note head that means a slide up to the note.

It could be useful to have a way to get the other slide symbols.


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

Re: [abcusers] trillian.mit.edu down?

[John Chambers]

Yeah; there have been some problems on trillian.  It's not  fully  up
yet, and lots of things are broken. Actually, I've temporarily turned
off most of the CGI scripts there, and put a notice at the  top  that
points to my home machine.

I have seen lists of Things That Go Wrong that include the rule  that
"failover"  to  a backup machine will invariably find that the backup
has failed, too.

I've also been wondering whether I should be looking for a mirror for
my  stuff  that's on another continent.  (My home machine is about 11
miles from trillian, so a single  well-aimed  asteroid  could  easily
take out both of them.  ;-)

One of the weirdnesses here is that ssh is in  its  funny  mode  that
loses  the  connection a lot, sometimes after only a few minutes.  So
connecting and reading email is sometimes slow, and replying  can  be
even slower.

Meanwhile, at home we have a new  ISP  (speakeasy.net)  that  doesn't
block any ports.  The old one (rcn.com) blocked ports 25 and 80, so I
couldn't do email or a standard web server at home. I may have both a
"live"  and  a  "test"  web  server at home soon.  Of course, another
problem has popped up: For the first time  ever,  the  latest  apache
doesn't  just  compile  and  run.  And, of course, the error it gives
(Error 139) isn't documented anywhere that I can find.

Toby Rider wrote:
| He had a mirror on one of my servers, but of course the drive on that
| machine where is home directory was located died, and I've not had the
| time to replace the drive yet. :-(

I noticed that there are a number of users with $HOME on that  drive.
How many people are anxiously wondering when it'll be fixed?  ;-)

| John McChesney-Young wrote:
|
| > Henrik Norbeck wrote:
| >
| >> I can't seem to reach JC's tune finder (or anything else for that
| >> part) at trillian.mit.edu. Any idean when it will be up again?
| >
| >
| > Although I can't answer your question and have been wondering about poor
| > Trillian myself, I can provide the URL for the mirror on John Chambers'
| > home development machine:
| >
| > http://jc.tzo.net:1742/~jc/music/abc/findtune.html
| >
| > Best,
| >
| > John
|
| To subscribe/unsubscribe, point your browser to: 
http://www.tullochgorm.com/lists.html
|
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] Question about copyright checking

[John Chambers]

Geoffrey Loker writes:
| Can anyone here tell me how to go about checking to see if a song or a
| tune is under copyright protection?

You have a lot of work ahead ... ;-)

Quite a lot of people have looked into this, and  concluded  that  in
general it's not doable. If you know who owns the copyright, it's not
too difficult, but of course that assumes you know the answer  before
you  go  looking for it.  If you have a tune of unknown ownership, it
seems that the best you can do is to go to a repository such  as  the
US  Library  of  Congress and do a manual search through all of their
musical publications.  This is a full-time job that will last several
years on the average.

One of the funnier examples of the difficulty: I've had a  few  email
exchanges  with  people at a couple of publishers, which I started by
asking how I would check to see if a  particular  tune  was  one  for
which they owned the copyright. Their answer (written with a straight
face as far as I can tell)  was  that  I  should  buy  all  of  their
publications  and  search them for the tune.  I'd specifically ask if
this was really their suggestion, and they said  that  yes,  it  was.
I've only tried this with a few publishers, but I suspect that all of
them view it this way.

As far as can be determined, the only fast way to determine who  owns
a tune is to publish, record or perform it, and see if anyone files a
lawsuit.  But even this has a problem: If nobody sues you, you  still
don't  know whether the tune has a copyright.  Maybe the owner didn't
notice what you did.  Or maybe they're waiting to see if you make any
money from the tune before suing you.

Anyone know a faster way?

(You can also ask on a list like this one, FWIW. ;-)

I've also been involved in another sort of discussion of how we might
set  up  a  searchable  online archive of ABC versions of copyrighted
songs, and use it as a sort of "sting" to entice lawsuits.  The  idea
would  be  to  get the courts to decide that the current situation is
illegal, since it requires that  musicians  know  something  that  is
being  intentionally hidden from them by copyright owners.  But doing
this would require some pretty  deep  pockets  to  handle  the  legal
battle, so the discussions don't get anywhere.

| I am in the midst of compiling a collection of old-ish songs (using
| ABC to enter the tunes for printing, storage, etc. [there - I've made
| the post relevant to the list]), and I need to know how to check on
| the copyright status for songs *and* for tunes (since a number of the
| songs are parodies of other songs, or share tunes).  I am primarily
| interested in how to check the copyright status of songs in Canada,
| although knowing how to do it in the United States and the United
| Kingdom would be interesting and potentially helpful too.

You really have a lot of work ahead ... ;-)

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

Re: [abcusers] ABCp output data structure

[John Chambers]

[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <200409111044.49
[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>

Paul Rosen writes:
| UNICODE Advantage: Any character in any language can be displayed.
| UNICODE Disadvantage: Everyone using the structure needs to be UNICODE
| aware. Are there systems and computer languages that can't handle it?

There is one semi-exception: The UTF-8 encoding has the property that
7-bit  ASCII  is  unchanged.   So  a  dumb  program  that thinks it's
producing 7-bit ASCII is also producing valid UTF-8 text, and doesn't
actually need any enhancement.  If a file is 7-bit ASCII, you can add
a "Content-Type: text/plain; charset=UTF-8"  (or  the  equivalent  in
whatever markup you're using), and it'll be correct.

| That's why I was wondering if there should be some type of switch passed to
| the parser about whether to output UNICODE.

Good idea.  And it would be useful if the first line of an  ABC  file
(or  tune)  gave  both the version of ABC used and the character set.
Assuming UTF-8 by default might be a good idea.  Allowing the  syntax
"charset=XYZ" would be a good idea.

An ongoing problem, of course, is that when programmers  try  reading
up  on  unicode,  most of the things they read cause them to throw up
their hands and decide to wait a few  more  years  until  it  becomes
something  that a merely-human programmer can actually understand and
maybe even use sanely.

I don't think this was the intent of the unicode crowd, and  I  don't
think  that  unicode  is actually all that complicated.  But a lot of
people can take a simple idea and describe it  in  a  way  that  it's
wonderfully complex and incomprehensible.

(My favorite musical example is to  inject  the  phrase  "transposing
instrument"  into a discussion, and watch gleefully as the discussion
breaks down into a hopeless muddle of people talking past each  other
in terms that nobody can quite understand.  ;-)

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

Re: [abcusers] Indexing tunes

[John Chambers]

| I tried the instructions below (still looking for an index of
| incipits--how are you doing Phil ;) ? ).  abc2mtex does indeed give a
| listing of Title plus the first bit of the tune in ABC.  BUT, it takes
| things out of the ABC syntax, so the music can not be readily turned
| into notation.  Perhaps there is an index format that would keep the
| syntax, but I couldn't muddle it out of the index.tex file .. at least
| at first reading.

FWIW, I wrote a simple perl script to generate  incipits  a
few years ago.  I tweak it now and then, depending on how I
want it to behave by default. Anyway, if you have perl (and
most  unixoid  systems  have it these days, including linux
and OSX), you could grab my script:

http://trillian.mit.edu/~jc/music/abc/sh/abcincip

It's a standard unix "filter", taking a list of file names,
or  reading  from  stdin  if there are no file names on the
command line. It does want an extra first arg, which is the
title  to  use  in the output.  If you make any significant
improvements, let me know.

I'd expect that a few other people have done something like
this, too.  Maybe we should make a collection of them. It's
not what you'd call a huge job, but it's useful.

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

Re: [abcusers] ABCp proof of concept

[John Chambers]

| well if my 2p are worth at least 2p to you, do it in ansi C if you want
| anyone to use it. The advantages of portability and general
| comprehensability outweigh some fun features that nonstandard extensions
| may have. I like SNOBOL but I would avoid inflicting it on other people.

I'd prefer ansi C, mostly because it's the "least common denominator"
language that can be most easily included in the other C dialects and
the extensible languages like tcl, perl and python.

Snobol's a fun language. It's too bad that it's so unknown outside of
academia.   I  did a few projects with it back in the 70's, and since
then, it's always been a real pain trying  to  use  what  passes  for
pattern  matching  in  other  languages.  Even perl is so awkward and
primitive in comparison.  I mean, you can't even  write  a  recursive
pattern.   But I suppose we'd never be able to get away with anything
as useful as snobol for our implementation language here.  ;-)

I've tried to pick up icon a couple of times, but  I  was  never  too
successful in getting it to run.  Maybe I should look again.

(I was also corrupted mentally by learning prolog.  Now it seems that
in  every  other  project, there's some multi-month task where I keep
thinking "This would be 10 minutes' work if  I  could  just  get  the
damned language to resolve a few expressions.  ;-)


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

Re: [abcusers] spam

[John Chambers]

John Walsh writes:
|   Am I the only one getting lots of spam (apparently) coming thru the
| abcusers list?  I haven't heard any other complaints yet, but the score this
| morning when I opened my email was two genuine emails, one spam directly sent to
| me, and four with headers mentioning abcusers, like this:
|
| >From [EMAIL PROTECTED] Sun Aug 29 11:12:22 2004
| Received: from argyll.wisemagic.com ([207.136.137.70])
| by viol.math.ubc.ca (8.12.10/8.12.10) with ESMTP id i7TICKvE016641
| for <[EMAIL PROTECTED]>; Sun, 29 Aug 2004 11:12:21 -0700 (PDT)
| Received: by argyll.wisemagic.com (Postfix)
| id C4BD4683; Sun, 29 Aug 2004 10:35:44 -0700 (PDT)
| Delivered-To: [EMAIL PROTECTED]
| Received: from 1632010.com (unknown [219.137.78.67])
| by argyll.wisemagic.com (Postfix) with SMTP id 9091D627
| for <[EMAIL PROTECTED]>; Sun, 29 Aug 2004 10:35:40
| -0700 (PDT
| )
| From: =?gb2312?q?_=C1=D6_=BA=A3__ <[EMAIL PROTECTED]>,
| [EMAIL PROTECTED]
| To: [EMAIL PROTECTED]
| Reply-To: [EMAIL PROTECTED]
| Subject: =?gb2312?q?=B9=E3=D6=DD=CA=D0=C8=D9=CC=A9=C3=B3=D2=D7=B9=AB=CB=BE?=
| Date: Mon, 30 Aug 2004 02:11:56 +0800
| MIME-Version: 1.0
| Content-Type: multipart/mixed; boundary="f5496535-61e0-4d36-8958-791751c82382"
| Message-Id: <[EMAIL PROTECTED]>
| Content-Length: 1281

There's evidence that this message didn't come from the list.  One of
the bits of evidence is that messages to the list have the line:

Reply-To: [EMAIL PROTECTED]

The above message has a Reply-To line giving another  address,  which
is  probably  a machine that will deal with your reply (and list your
address as a known-good address ;-).

This message  probably  came  from  someone  who  has  both  you  and
abcusers-list  in their address book.  Their machine is infected with
one of the Outlook viruses or such that is turning their machine into
a  spam  relay.  Most of them cover the tracks, so you can't trace it
back to the original spam sender.


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

Re: [abcusers] K:none

[John Chambers]

Steven Bennett wrote:

| I believe I decided that T: was a valid title field as well -- some pieces
| simply don't have a title.

Yes; I have a number of examples where I don't want a title.   Mostly
they're musical fragments, or things like a blank manuscript page.

OTOH, one thing my Tune Finder has run across is ABC files that  lack
a  title  because  they  are incorporated in some fashion inside HTML
files, and the title is in the HTML.  This  is  frustrating,  because
it's nearly impossible for software to discover the title.  These are
mostly songs, it turns out, and they aren't in my index.

One example is  the  collection  at  natura.di.uminho.pt,  where  the
latest run of my search bot says all the titles just disappeared. I'd
known this was a problem with that site, which has hundreds  of  trad
Portuguese  songs  in ABC.  My index showed 72 tunes in 43 files, but
only 32 had titles.  This time, the file and tune counts  dropped  by
one,  but  the title count dropped to zero.  I checked, and the tunes
are still there, but the T lines are all just "T:".  If you  look  at
the  site,  you'll see the tunes as GIF images and ABC, but the title
is in a different font because it's in the HTML only. I've considered
writing  special  code  to  deal with several sites like this, but it
wouldn't be easy.

I don't care if my blank manuscript  pages  aren't  indexed,  because
there's no music there. Of course, if someone is specifically looking
for ABC files that give blank manuscript pages, they  won't  find  it
from my Tune Finder.  But so far I don't consider that a problem.

| Maybe we should add a few comments in the ABC 2.0 spec that discusses what
| the behavior of a blank field line should be.  That way we don't get a
| zillion different behaviors.

Yes, this is useful. I do a fair amount of programming in perl, which
is  often  very sketchy because most of the language has defaults and
can be omitted for the most common case.  This works pretty well  for
perl.   Part  of  the  reason  is  that the defaults have been fairly
thoroughly discussed in the comp.lang.perl newsgroup,  and  the  user
population generally agrees on what the default should be. Whether we
could get this sort of agreement from musicians isn't as  clear.   In
conventional  staff  notation, a lot of things are often omitted, but
what is omitted differs for different musical styles.  I can think of
a  number  of examples where the best default for omitted notation is
different in different styles.

| > This does remind me that I've got a few funny questions about  why  I
| > sometimes  do  things  like  putting "K:G" at the start of a tune and
| > then "K:Em" or "K:Ador" before a later phrase.
| > to be very convincing.
|
| Until recently, I would have found such fields confusing as well.  But
| having recently absorbed a lot of chord theory, it becomes almost necessary
| to have such fields where the key actually does change, because the chord
| progressions for "K:G" and "K:Em" are different, even though the key
| notation looks the same on the staff.
|
| That's also why I now prefer to display the key as a text string above the
| staff in addition to the on-the-staff notation.

Yeah, and you see that sometimes in classical music,  though  usually
they  let  you  figure  out the key change yourself.  It's especially
useful in computerized notation, because it lets  the  computer  help
you  by  doing searches for keys, suggesting chords as a few abc apps
do, and so on.  Of course, its usefulness is limited,  as  you  don't
want to bother notating key changes that are only for a few measures.

An interesting case where I don't indicate key changes much is in  my
klezmer collection. You might think that it would be useful, in light
of all the different scales and frequent key changes.   But  frequent
key  changes  is  the  reason  it's  not useful.  Klezmer music often
changes rapidly among a number  of  closely-related  keys,  and  once
you're familiar with this, the changes are pretty obvious.  But a key
change every 2 or 3 measures rapidly gets obnoxious.  So I just  pick
most common (or initial or final) key, and use that.

Irish/Scottish music is different.   Some  tunes  do  have  transient
changes  to  another  key.   But more common is to have the different
sections of a tune in different keys.  I prefer to notate this,  even
if it's the same signature.  That way, if I'm looking for an Em tune,
I also get the tunes in G/Em (or maybe D/Edor).  Sometimes  I  decide
that one of those tunes will work in the set I'm putting together.

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

Re: [abcusers] K:none

[John Chambers]

Steven Bennett writes:
| "K:none" is already defined in the ABC 2.0 draft spec, although there's a
| slight ambiguity in that spec, since "none" is also shorthand for
| "clef=none".  When I implemented that section of my parser, I resolved that
| in favor of the key, and required the full "clef=none" if you want no clef.

Sounds reasonable.  K:none should mean that  you  don't  want  a  key
signature;  clef=none should mean that that you don't want a clef.  I
use both in a few abc files I  have  that  generate  pages  of  blank
manuscript paper. I also made sure that "T:" alone works for a title,
since I don't want those on such pages, either.  And all of these are
useful for producing musical fragments, as examples in a document.

| "K:" by itself is not documented in ANY version of the ABC spec as a valid
| sequence, and cannot be assumed to work in any program.  In my own parser,
| again, that would cause an error on the field, which would cause the field
| to be ignored (in an attempt to recover), which would then cause all kinds
| of havoc.  Stick with "K:none" instead.

What I think I've seen is a few comments to the effect that C is  the
default  key.   Since  most  abc software requires a K line, the only
thing this could be talking about is a  bare  "K:"  without  any  key
information.   Of course, I'd prefer to say that "K:" means "K:none",
not "K:C" (or K:Am" or  "K:Ddor",  for  the  benefit  of  anyone  who
understands the difference.  ;-).

I do have a few abc template files that contain a list  of  the  most
common  headers,  with nothing after the colons.  This saves me a few
keystrokes at times.  But it's easy to forget to fill them  in.   I'd
prefer  software  that  accepts  this,  perhaps  with  a  warning, to
software that chokes on it.

This does remind me that I've got a few funny questions about  why  I
sometimes  do  things  like  putting "K:G" at the start of a tune and
then "K:Em" or "K:Ador" before a later phrase.  They usually say that
the  second  K line doesn't change anything.  It does, of course, but
how do you  explain  that  simply  to  someone  who  doesn't  already
understand  it?   I'll usually say something like "Well, the key does
change, and I thought it would  be  useful  to  document  this,  even
though  it  doesn't effect the printed output." But this doesn't seem
to be very convincing.

Maybe this just labels me as overly pedantic?

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

Re: [abcusers] K:none

[John Chambers]

Atte asked:
| Some tunes are not in any specific key, but it seems abc doesn't have
| any way to notate this. If I use K:C the song is shown correctly, but
| this opviously is corrupted when transposing it.
|
| Is there a solution withinn the current abc definition that I overlooked
| or should we consider extending the K: to allow K:none?

Some abc programs have supported this for several years already. I've
used  it  occasionally,  though not very often.  It's most useful for
notating  fragments  of  music,  for  example  in  documentation  and
tutorial docs.

Implementing it is usually trivial, as it maps internally to the same
thing  as  K:C.  The only real advantage of K:none is that it doesn't
match when you search for K:C (or K:Am or K:Ddor).  Of  course,  just
"K:"  alone  also works for this.  Most software should support that,
too, by mapping it to the same thing as K:C internally.

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

Re: [abcusers] On parsers again - Outlook & PHP

[John Chambers]

Christian M. Cepel writes:
| John Chambers wrote:
|
| >Since ABC is widely used to send tunes via email, ABC ends  up  being
| >embedded inside messages in lots of other formats. It's fairly common
| >for this to garble the ABC,  as  the  encoding  software  is  usually
| >debugged  only  with  ordinary  (English)  text.
...
| Ran into this nonsense mailing a gal a php proggie I had written for her
| to convert medline source references into CSV txt file...
|
| She (unfortunately everyone on campus who doesn't know any better) is
| using exchange.  Finally had to send her a zip.
|
| <?php
|
| and so on and so forth.

Yeah; in this list we notice how email software damages ABC, but it's
a well-known problem in most programming languages. Back before 1990,
when most email software was written by programmers for  programmers,
it  was  less common (though it did happen).  But then the commercial
folks jumped onto this new Internet thing, and they decided to  scrap
all that techie stuff and write "user-friendly" software. The results
were generally programmer-hostile.

It effects everyone who tries to use email to send anything  that  is
formatted differently from English. In ABC, a string like A2B4c2 will
be treated as six tokens by most "intelligent"  email  software,  and
newlines may be inserted anywhere. When one is inserted before one of
the numbers, the result usually doesn't work  correctly,  since  most
ABC  software doesn't know what to do with a number at the start of a
line/staff.

But this has been at least a minor headache for programmers since  we
first  had  email  back  in the 70's.  Despite attempts to make email
standards that prevent such damage, the problem is probably worse now
than ever.

What's funny is all the software that wraps lines at 80 or 72  chars.
This is referred to in the literature as the symptom of a "punch card
mind".  How many computer users nowadays have ever  seen  or  used  a
punch  card?   I  have  a  couple  in a box as souvenirs.  That 72 is
especially bizarre.  How many people these days could even  tell  you
where that strange number comes from?  But lots of software does it.

I guess you could call it a tradition ...


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

Re: [abcusers] On parsers again

[John Chambers]

Christian M. Cepel writes:
| I would prefer that it have optional modes... Strict, not-so-strict,
| loose/forgiving, recover ABC from any textfile, etc... something.

The really fun case is recovering ABC from HTML files. ;-)

My Tune Finder tries to do this, with varying degrees of success. The
problem  can  perhaps be illustrated by the following fragment, which
some people think should be a good way to do it:



...
   | ag |
...


The contents of a ... section are, of course,  also  HTML,
and  HTML  tags are honored.  So this measure of music contains a 
tag with  an  "a"  attribute  which  is  ignored  (because  it's  not
defined). In a browser windows, the b and a notes don't appear in the
output, giving the measuure | ag |, and  the  rest  of  the  tune  is
rendered in a bold font.  This is the most common sort of HTML tag to
appear in ABC tunes, but  others  also  occur,  sometimes  with  very
strange effect.

Of course, you will occasionally see the above measure encoded as HTML
entities:

   | ag |

This is correct HTML,  but  causes  the  opposite  problem  that  ABC
software  that's  not HTML-aware will not undo the encoding, and will
attempt to interpret it all as ABC.  Depending on whether or not  the
'&'  ABC  operator is implemented, this will produce various kinds of
incorrect output.  In the best case, it will produce a  few  warnings
and the measure | ab ag |, which at least has the right notes.

Then there are the sites that send *.abc files as text/html, although
they  are  actually text/plain.  There are a number of these, and the
people who have the misfortune to put their abc files on line on such
sites usually get quite frustrated trying to get the site's admins to
correct the bad type.  (And setting the type to text/vnd.abc is often
far beyond the admins' capabilities. ;-)

Since ABC is widely used to send tunes via email, ABC ends  up  being
embedded inside messages in lots of other formats. It's fairly common
for this to garble the ABC,  as  the  encoding  software  is  usually
debugged  only  with  ordinary  (English)  text.   Decoding is fairly
haphazard, and it will be  common  for  your  software  to  encounter
partly-decoded email messages that contain partly-decoded tunes.

The sensible thing might be to just throw up your hands and refuse to
deal  with  it.   But you have a lot of companies working on a lot of
email software doing their best to make life difficult for you.


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