Re: [abcusers] About the choice of '!'

[Guido Gonzato]

On Tue, 22 Jul 2003, Jean-Francois Moine wrote:

> >BTW - Jean-François, how do you tell whether '!' is a line break or the
> >start of a decoration?
> 
> When encountering a '!', I scan forward. If I find any of "|[:]"
> (and soon a blank or tab), or the end of line, it is a line break.
> Else, if I find a '!', it is a decoration. This means that a
> decoration name cannot contain any of these characters (for instance,
> '!da Capo!' or '![rit]!' will not work, while '!crescendo(!' is OK).
> 
> Does this solve all the problems?

with ABC, we all know that 'solving' problems is impossible... you'll
always find a guy who will say, "Hey, my ABC uses XYZ so you can't do
that"... but your arrangement greatly _reduces_ the number of problems! As
usual.

I'll add this solution in abcpp and in the draft.

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] Use of ! (and another source issue)

[Guido Gonzato]

On Tue, 22 Jul 2003, Jean-Francois Moine wrote:

> >to me it seems OK: as long as major developers add this feature (and I
> >imagine it's very easy to implement), I can see no reason not to include `
> >in the standard.
> 
> Yes, very easy: I had to change only 3 characters in the parser...

I was sure you would add it easily... Jef, you're great :-)

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] BarFly 1.4 available

[Phil Taylor]

Jack Campin wrote:

>Can the Classic version run on 68040s - i.e. is it an old-style
>fat binary?  I'd rather not have to manage two separate versions.
>(Most of my stuff is on an external disk which is usually mounted
>on an LC475 but sometimes on a PPC machine).

Yes it can.  The main reason for having a separate 68k-only version
is that it's packed with an old old version of Stuffit, in a format
which can be unpacked using Expander 4 which will run under System 7.0.

See how I care for youse old folks!

Phil Taylor


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

Re: [abcusers] Re: %%ABC 2.0 identifier

[Richard Robinson]

On Tue, Jul 22, 2003 at 07:11:05PM -0400, Steven Bennett wrote:
> 
>  ...   (IMHO,
> there should be NO data in an ABC2 file which exists outside the context of
> the current tune -- I don't know if anyone else agrees with this, but it
> makes the most sense to me...)
>  
> > (2) A surprisingly large proportion of users type their abc directly
> > in a text editor.  There's no way you can make these people include
> > the identifier.  They mostly won't bother, and if their software enforces
> > it they'll prefer to use a program which doesn't.
> 
> Which is why I suggest it as part of a new ABC 2.0 standard.  If *all*
> programs which support ABC 2.0 need that line, then people will use it when
> writing new tunes to that format.  It's not like typing "%%ABC2" at the
> start of your tune is a particularly onerous or time consuming task.

It's be a lot less onerous to type it once at the head of the file and
let the existing rules for "global" headers stand.

If new software insists on things that people don't particularly want to
do, they might just not use it.

> 
> The issue with XML is you end up with something trivial to parse, but nearly
> impossible to write without machine assistance.  The main reason I like ABC
> (and I suspect others do also) is it's relatively easy to type in music in
> that format.

Same here.


> should be as bloody difficult as it currently is.  (Which reminds me -- is
> there ANY other open source parser out there other than the several dozen
> variants of the ones in ABC2PS and ABCM2PS?   I'd like to look at one,
> especially an object oriented one if one exists...)

There's also the abcMIDI one.


-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] Re: %%ABC 2.0 identifier

[Phil Taylor]

Steven Bennett wrote:

>Phil Taylor wrote:
>
>> To return to the original suggestion in the title of this thread, it
>> has been suggested many, many times before.  One of the first postings
>> I ever made to this list (or was it the developer's list?), made
>> exactly the same suggestion - for goodness sake lets write the version
>> of abc used in this file at the start so programs know what they have
>> to deal with.  It's a great idea, but it won't work because:
>>
>> (1) The fundamental unit of abc data is not the file, it's the tune.
>> ... [snip]
>> So the identifier would have to be added to individual tunes to be
>> useful, rather than go in the file header.
>
>I fully agree with you.  My suggestion is exactly that - this belongs in the
>header of each tune, and in fact, might be best defined as the first line of
>a new tune, making it a much more easily identifiable tune break.  (IMHO,
>there should be NO data in an ABC2 file which exists outside the context of
>the current tune -- I don't know if anyone else agrees with this, but it
>makes the most sense to me...)

I have to disagree.  One very useful feature of abc is the possibility
of embedding abc tunes in other text.  This makes it a fine tool for
writing about music.  See Jack Campin's tutorial on modes in Scottish
music for a good example of this.

>> (2) A surprisingly large proportion of users type their abc directly
>> in a text editor.  There's no way you can make these people include
>> the identifier.  They mostly won't bother, and if their software enforces
>> it they'll prefer to use a program which doesn't.
>
>Which is why I suggest it as part of a new ABC 2.0 standard.  If *all*
>programs which support ABC 2.0 need that line, then people will use it when
>writing new tunes to that format.  It's not like typing "%%ABC2" at the
>start of your tune is a particularly onerous or time consuming task.

I dunno.  Some people can't even bother typing in the X: field at present.

>> If you really want to write an abc parser, you will have to get your
>> head round the idea that abc is not a computer language, it's a
>> natural language (albeit a very simple and regular one, with very
>> few dialects).  It makes writing a parser a much more interesting
>> task.  If you want an easy (to the point of being boring) job, write
>> a MusicXML parser.
>
>The issue with XML is you end up with something trivial to parse, but nearly
>impossible to write without machine assistance.  The main reason I like ABC
>(and I suspect others do also) is it's relatively easy to type in music in
>that format.

Very true.  It's also (surprisingly) much easier to debug an abc parser
than an XML parser, just because it's so hard to find your way around
those huge files (an error on line 3 is much easier to locate than one
on line 2872).

>Unfortunately, ABC as it exists now has indeed become a natural language,
>and that limits it's usefulness immensely in the computer world.  And I beg
>to differ about "few" dialects -- as near as I can tell, there are at least
>as many dialects as there are programs to handle ABC, and from comments here
>on this list, I suspect there are even more than that.

I meant few compared with English or French:-)

>I have no problem developing a complex parser -- I've done that plenty of
>times before, but developing one from scratch which has to deal with
>multiple conflicting rules and absolutely no means of identifying which rule
>applies, is absolutely no fun at all.  Writing a parser isn't the goal -
>it's a necessary step in creating a new program, and there's no reason it
>should be as bloody difficult as it currently is.  (Which reminds me -- is
>there ANY other open source parser out there other than the several dozen
>variants of the ones in ABC2PS and ABCM2PS?   I'd like to look at one,
>especially an object oriented one if one exists...)

There's the parser used in abc2midi and yaps, but it's ansi C not C++.

>Maybe I should be proposing that the new standard not be called "ABC 2.0" at
>all, but something entirely different.  It would still be the same goal --
>establishing a truly standard computer-readable dialect of ABC, but by
>changing the name, it loses the baggage that name currently carries...

Yes it used to drive me mad too.  But abc as it stands at present isn't
going to go away, and while a new, strict language is undeniably
attractive to programmers it may well prove to be much less so to
the public at large.

Phil Taylor


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

Re: [abcusers] BarFly 1.4 available

[Jack Campin]

> There are now three versions of BarFly, called Carbon, Classic
> and Old.  All three versions have been updated, and all carry
> version number 1.40.
>
> Use the Carbon version on MacOS X, and on MacOS 8.5 - 9.2.
> Use the Classic version almost anywhere (System 7 on).
> Use the Old version on Macs with 68030 or 68040 processors
> and on PC emulators which emulate this kind of processor.

Can the Classic version run on 68040s - i.e. is it an old-style
fat binary?  I'd rather not have to manage two separate versions.
(Most of my stuff is on an external disk which is usually mounted
on an LC475 but sometimes on a PPC machine).

-
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] New standard(s)

[Jack Campin]

> Funny thing is that in recent years, they  have  abandoned  any  such
> calibrated  units  for  most  measurements.   Units  of time, length,
> voltage, etc.  are now defined in terms such as the wavelength  of  a
> specific  spectral  line in a specific isotope.  So you don't have to
> depend on a physical copy of a physical  object  halfway  around  the
> world; you can determine the units in the privacy of your own lab. In
> most of the world, this is now the situation. [...]
> I can't think of a way to make a funny tie-in to music for this  now.
> Maybe someone else can. Something along the lines of how we no longer
> need to calibrate our instruments to any mundane physical objects  in
> this  world;  we can align our music with the very basic phenomena of
> the cosmos.  But there's gotta be a better  (i.e.,  funnier)  way  to
> express the idea ...

I heard somewhere that there was an ancient Chinese term for a month
in the spring that translated as something like "in-tune flute time".
The reasoning behind it was that at that time of year, the base joint
of the local bamboo had grown to be just the right length to make a
standardly pitched flute out of.  Musical pitch gets to define the
calendar.

-
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] multivoice & linecontinuation

[Jack Campin]

> As said before -  in multivoice scores - human readability 
> won't have to be/should not be/cannot be a major issue. 

Why bother with ABC at all, then?

Look at the "Atalanta Fugiens" scores on my webpage.  The way
I have laid them out, anybody - including a blind person - can
read them vertically and figure out the harmony at every point.
Or this (needs a window with 96 columns, fixed-width font):

X:5
T:Meine Seel' erhebt den Herren
S:Bach/Riemenschneider #358
C:J.S. Bach
M:C
L:1/4
V:1
V:2
V:3 bass
V:4 bass
K:GMin
V:1 d2  f2 |d  d  d  d |e2d2   |c2c2 |HB4  |
V:2 G2  F2 |F ^F  G  A |G F2 G |G2F2 |HF4  |
V:3 B,2 C2 |D  C  B, A,|B, C2B,|B,2   A,2|HD4  |
V:4 G,2 A,2|B, A, G,^F,|G, A, B, G,|E, C, F,2|HB,,4|
%
V:1 d2  f2 |c  c  c  G |B2A2   |HG4  |
V:2 F4 |F  F  E  G |G2   ^F2   |HD4  |
V:3 B,4|A, C  C  C |D3   C |HB,4 |
V:4 B,2 D,2|F, A, G, E,|D, C, D,2  |HG,,4|
%
V:1 d2  f2 |d  d d   d |e2d2   |c2c2 |HB4  |
V:2 G2  A2 |F3  ^F |G  A  B2-  |B  B  B A|HF4  |
V:3 B,2 C2 |D  C D2|D  C  B, F |G2F C|HD4  |
V:4 G,2 F,2|B, C B,  A,|B, C  F, D,|E, C, F,2|HB,,4|
%
V:1 d2 f2   |c  c  c c |c2G  A|B2 A2   | G4-|G4-|G4   
|H G4  |]
V:2 z4  |F  G  A B |c2C2  |D2 D  C |=B, D  G  F |E4-|E2  D  C 
|H D4  |]
V:3 z2 F, G,|A, B, C2- |C  D =E ^F|G2=F  E | D =B, C  D-|D  G, C2-  |C2 =B, 
A,|H=B,4 |]
V:4 B,, C, D, E,|F,3 G,|A, B, C2  |B,, C, D, E,| F,2   E, D,|C, D, E, F,|G,4  
|H G,,4|]

(Note, this is deliberately *not* designed for good staff notation
output - I've put each line of the chorale as a separate system in
the ABC source, the last one would be denser than the first three).

If you can't make your ABC source human-readable you shouldn't
be using it.  If all you want is staff notation, Finale or
Sibelius will do it better.  It's the other uses of ABC that
make it unique, and most of those uses depend on readability.

-
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

[abcusers] linebreaks and paper sizes

[Jack Campin]

>> BarFly makes ignoring linebreaks an option (except for multi-voice
>> music where it isn't practical); what I do sometimes is first let
>> the program have a go at doing the layout, then optimize the result
>> by putting explicit linebreaks in better places myself.  BarFly's
>> spacing algorithm is not very sophisticated (monospace type printed
>> on elastic), but the same approach would be handy for any program.
> As I see music engraving, you should care about linebreak/pagebreak
> just before you start printing.  You never know the paper size 
> beforehand do you?

I do.  It's always A4, either portrait or landscape.

For the tunes on my CD-ROMs, the GIF scores (generated by BarFly)
are intended for practical use by folk instrumentalists who operate
the way I see them working in Scotland: everybody (beginners to pro
ceilidh bands) uses A4 folders with clear plastic pouches.  The music
in them is usually portrait layout, be it printed, xeroxed or hand-
written.  So I design for that use; my users will print the tunes
themselves as needed and arrange them in whatever categories they want.
(Epicycle: I try not to use the full height of A4, so American users
can fit my stuff onto their "letter" size without rescaling; I presume
they use the plastic pouches too).

For the flute CD-ROM, I did every tune in both portrait and landscape;
that stuff is significantly more complex than the "Embro, Embro" or
Aird tunes, and often landscape layout works better.  Harder to use on
a stand, but I was expecting people to use the scores for memorization
rather than in performance.  In many cases (and increasingly as LCD
screens become more prevalent) people will simply learn the tunes off
the computer screen (maybe aided by sound files) and never print them.

There are so many advantages to this format that hopefully I've just
killed the printed-and-bound tune anthology.

But what I really want is singing digital paper.

-
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] About the choice of '!'

[Jack Campin]

>>> The idea of multiple tunes within one file I personally do not like
>>> much (I'd rather zip them when transferring)
>> Interesting. It's always struck me as one of the useful points about
>> ABC, when dealing with several thousand tunes, that you don't have to
>> have them all in separate files.
> When it comes to downloading/distributing: YES
> When it comes to handeling: definately NO

I use three different editors for handling ABC on the Mac (BarFly,
BBEdit and Nisus Writer).  With all of them it's much quicker to
search a few large files than a zillion small ones; Nisus Writer
makes it painfully difficult to search large numbers of files,
though the kinds of pattern matching and replacement it can do are
way more sophisticated than any other editor I know of.  Surely
the same is true on any OS? - there's a much larger hit opening a
small file than reading a comparable-sized chunk of a large one
that's already open.

I think ABCMus uses a similar user interface to BarFly (selecting
tunes from an index on a file, which can be large) so this doesn't
seem to be a problem on Windows either.

-
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] Re: %%ABC 2.0 identifier

[John Chambers]

John Chambers writes:
|  On Tue, Jul 22, 2003 at 07:11:05PM -0400, Steven Bennett wrote:
|  >
|  >  ...   (IMHO,
|  > there should be NO data in an ABC2 file which exists outside the context of
|  > the current tune -- I don't know if anyone else agrees with this, but it
|  > makes the most sense to me...)
|
| While I usually have pure abc files, I've seen a lot of the  uses  of
| abc mixed with text.  You see it all the time on some musical mailing
| lists.  As part of a discussion, someone includes a tune or three  in
| abc form. It's really convenient to be able to take the message, feed
| it unaltered to abc2ps, and see the staff notation.
|
| Of course, it doesn't always work out  that  well.   Long  lines  get
| wrapped, and it looks really stupid on the screen.  So you have to go
| back, edit the message, and  try  again.   And  people  don't  always
| remember to put a blank line after the tune, producing a bit of extra
| "modern" music at the end. But a lot of the time, it works just fine.

I forgot to include the really big annoyance with abc tunes  embedded
in  email  text:  People have this way of putting most of the info in
the English text.  Then, if I want to add it to my collection, I have
to  go  in and edit the text into abc header lines and move them into
the tune.  Since I always want to have interesting info in  the  abc,
this is a lot of extra work.

But it doesn't do any good to complain; people just keep doing it.  I
can  easily write code to generate a missing  X: line, but extracting
the info from English is a LOT more difficult.

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

Re: [abcusers] Re: continuations

[Phil Taylor]

John Chambers wrote:

>Another fringe case is what happens when a  line  ends  with  '\',  a
>space,  and  a  newline.  It's common for many implementations to not
>recognize this as a continuation.  This one is really baffling  to  a
>user,  who usually can't see the space.  The right way to handle this
>is to strip off the trailing spaces (and tabs), and  then  check  for
>the final '\'.  The input routine is now not quite as trivial (though
>it's still pretty trivial).

BarFly does that (at least for spaces - I'm not sure about other
whitespaces).  Another thing that's a problem is % comments following
the backslash.  That's more complicated to deal with, and I'd like
to see it illegal.

Phil Taylor


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

Re: [abcusers] Re: %%ABC 2.0 identifier

[John Chambers]

 On Tue, Jul 22, 2003 at 07:11:05PM -0400, Steven Bennett wrote:
 >
 >  ...   (IMHO,
 > there should be NO data in an ABC2 file which exists outside the context of
 > the current tune -- I don't know if anyone else agrees with this, but it
 > makes the most sense to me...)

While I usually have pure abc files, I've seen a lot of the  uses  of
abc mixed with text.  You see it all the time on some musical mailing
lists.  As part of a discussion, someone includes a tune or three  in
abc form. It's really convenient to be able to take the message, feed
it unaltered to abc2ps, and see the staff notation.

Of course, it doesn't always work out  that  well.   Long  lines  get
wrapped, and it looks really stupid on the screen.  So you have to go
back, edit the message, and  try  again.   And  people  don't  always
remember to put a blank line after the tune, producing a bit of extra
"modern" music at the end. But a lot of the time, it works just fine.



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

Re: [abcusers] Re: continuations

[John Chambers]

Phil Taylor writes:
| John Chambers wrote:
| >(And we'll still have the even more minor problem caused by
| >the  fact that some programmers will replace the '\' with a
| >space, while  others  will  delete  it  plus  the  newline,
| >causing  the  two  lines  to be joined without a separator.
| >This is a problem that still  plagues  several  programming
| >languages.   It's  made  worse  by the fact that there's no
| >logical solution; both ways work equally well.   Quandaries
| >like  this  are  almost impossible for a group of humans to
| >ever solve.  ;-)
|
| Er, why would you want to put a space in place of the backslash?
| Joining the two lines without a separator seems the logical
| thing to do (or at least I can't immediately think of a situation
| where adding a space would make sense).

Well, I tend to agree.  But I think the contrary argument is  that  a
lot  of  people are surprised when the two lines are joined without a
space. They then have to go back and fix it (e.g.  by putting a space
before  the  '\').   I  think  the idea is that this "Oops!" reaction
wastes more time than the alternative.

But note that I called this an  "even  more  minor  problem".   We're
really  on  the fringe here, and it's probably not worth wasting much
time on.  I'd also vote for making a final '\' delete both itself and
the newline, and join the next line without adding anything.  You can
always put a space before the '\'.

Another fringe case is what happens when a  line  ends  with  '\',  a
space,  and  a  newline.  It's common for many implementations to not
recognize this as a continuation.  This one is really baffling  to  a
user,  who usually can't see the space.  The right way to handle this
is to strip off the trailing spaces (and tabs), and  then  check  for
the final '\'.  The input routine is now not quite as trivial (though
it's still pretty trivial).

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

Re: [abcusers] copyright sign

[Jack Campin]

>> This is one thing that can easily be written in ASCII, as "(c)" or
>> "copyright" in some appropriate field; I use the Z: field most of
>> the time because every time I've wanted to make the point I've been
>> the copyright-holder, but it could go in C:, A:, D: or B: as well.
> As long as you realise that (C) is not a copyright sign legally.

That must be wrong or else source code could never be copyrighted.
(Not that copyright needs an explicit sign any more anyway - the
point of the sign is to say who the copyright holder is, not to be
a juju creating the legal status).

-
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] Re: %%ABC 2.0 identifier

[Steven Bennett]

Phil Taylor wrote:

> To return to the original suggestion in the title of this thread, it
> has been suggested many, many times before.  One of the first postings
> I ever made to this list (or was it the developer's list?), made
> exactly the same suggestion - for goodness sake lets write the version
> of abc used in this file at the start so programs know what they have
> to deal with.  It's a great idea, but it won't work because:
> 
> (1) The fundamental unit of abc data is not the file, it's the tune.
> ... [snip]
> So the identifier would have to be added to individual tunes to be
> useful, rather than go in the file header.

I fully agree with you.  My suggestion is exactly that - this belongs in the
header of each tune, and in fact, might be best defined as the first line of
a new tune, making it a much more easily identifiable tune break.  (IMHO,
there should be NO data in an ABC2 file which exists outside the context of
the current tune -- I don't know if anyone else agrees with this, but it
makes the most sense to me...)
 
> (2) A surprisingly large proportion of users type their abc directly
> in a text editor.  There's no way you can make these people include
> the identifier.  They mostly won't bother, and if their software enforces
> it they'll prefer to use a program which doesn't.

Which is why I suggest it as part of a new ABC 2.0 standard.  If *all*
programs which support ABC 2.0 need that line, then people will use it when
writing new tunes to that format.  It's not like typing "%%ABC2" at the
start of your tune is a particularly onerous or time consuming task.
 
> If you really want to write an abc parser, you will have to get your
> head round the idea that abc is not a computer language, it's a
> natural language (albeit a very simple and regular one, with very
> few dialects).  It makes writing a parser a much more interesting
> task.  If you want an easy (to the point of being boring) job, write
> a MusicXML parser.

The issue with XML is you end up with something trivial to parse, but nearly
impossible to write without machine assistance.  The main reason I like ABC
(and I suspect others do also) is it's relatively easy to type in music in
that format.

Unfortunately, ABC as it exists now has indeed become a natural language,
and that limits it's usefulness immensely in the computer world.  And I beg
to differ about "few" dialects -- as near as I can tell, there are at least
as many dialects as there are programs to handle ABC, and from comments here
on this list, I suspect there are even more than that.

I have no problem developing a complex parser -- I've done that plenty of
times before, but developing one from scratch which has to deal with
multiple conflicting rules and absolutely no means of identifying which rule
applies, is absolutely no fun at all.  Writing a parser isn't the goal -
it's a necessary step in creating a new program, and there's no reason it
should be as bloody difficult as it currently is.  (Which reminds me -- is
there ANY other open source parser out there other than the several dozen
variants of the ones in ABC2PS and ABCM2PS?   I'd like to look at one,
especially an object oriented one if one exists...)

Maybe I should be proposing that the new standard not be called "ABC 2.0" at
all, but something entirely different.  It would still be the same goal --
establishing a truly standard computer-readable dialect of ABC, but by
changing the name, it loses the baggage that name currently carries...

-->Steve Bennett

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

Re: [abcusers] Re: continuations

[Laura Conrad]

> "Irwin" == I Oppenheim <[EMAIL PROTECTED]> writes:


Irwin> When you precede a newline by a backspace, the newline
Irwin> gets escaped and no longer functions as whitespace.

This is true.  But that wasn't what I'd done.  I'd written two lines:

a/ b/ c/ d/
e/ f/ g/ a/

I didn't want any eighth notes beamed.  I expected this to accomplish
that.

But abc2ps treated the -c option as if there were a \ at the end of
the line, and therefore beamed the d/ and the e/.  I found this
counterintuitive.  I did write a script to put an invisible (to most
editors) space at the end of every line.  But I still think that was
the wrong design for abc2ps, and that any reasonable person would have
expected that the d/ and the e/ would not be beamed.  And that any
reasonable person would expect the notes to look the same (although
the line breaks would be different) whether they used the -c option or
not.

-- 
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] Re: continuations

[I. Oppenheim]

On Wed, 22 Jul 2003, Laura Conrad wrote:

> I thought that most people would assume that any
> whitespace, including newline, would cause the 8th's
> to not be beamed.

When you precede a newline by a backspace, the newline
gets escaped and no longer functions as whitespace.


 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] Re: continuations

[Laura Conrad]

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

Phil> Er, why would you want to put a space in place of the backslash?
Phil> Joining the two lines without a separator seems the logical
Phil> thing to do (or at least I can't immediately think of a situation
Phil> where adding a space would make sense).

When I started using the -c option on abc2ps, I was quite surprised
when some of my  8th notes were beamed, because only a newline
separated them, whereas most of them were not, because I had
deliberately put spaces between them.  I thought that most people
would assume that any whitespace, including newline, would cause the
8th's to not be beamed.  

-- 
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] Re: continuations

[Phil Taylor]

John Chambers wrote:

>This has been thrashed out for many  programming  languages
>over  the  past several decades.  It turns out there's only
>one rule that will actually be implemented the same by  all
>programmers,  and  it's  also the only rule that users will
>all understand the same way.  This is that the continuation
>('\' in abc as in many programming languages) just means to
>join the current line to the next line.

I agree.

>If we attempt  to  have  the  continuation  mechanism  skip
>lines,  we  make life very difficult for all of us, because
>there is no real hope that all programmers  will  implement
>this skipping the same way.
>
>We should classify the old scheme(s) as  a  minor  mistake,
>and  correct  it  in  the  official standard.  Then it will
>finally be clear how  programs  should  implement  it,  and
>programs  that  skip  lines  to  find the continuation will
>simply be buggy.  But it's an easy bug to fix.
>
>(And we'll still have the even more minor problem caused by
>the  fact that some programmers will replace the '\' with a
>space, while  others  will  delete  it  plus  the  newline,
>causing  the  two  lines  to be joined without a separator.
>This is a problem that still  plagues  several  programming
>languages.   It's  made  worse  by the fact that there's no
>logical solution; both ways work equally well.   Quandaries
>like  this  are  almost impossible for a group of humans to
>ever solve.  ;-)

Er, why would you want to put a space in place of the backslash?
Joining the two lines without a separator seems the logical
thing to do (or at least I can't immediately think of a situation
where adding a space would make sense).

Phil Taylor


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

Re: [abcusers] expected abc audience

[Richard Robinson]

On Tue, Jul 22, 2003 at 03:02:32PM -0400, Laura Conrad wrote:
> > "Richard" == Richard Robinson <[EMAIL PROTECTED]> writes:
> 
> Richard> I notice it prints without title or other text. 
> 
> You must be using lilypond-book?  If you use the standard ly2dvi, it
> prints the Title and Composer.

Ah, thanks, I hadn't known of that. I was doing "lilypond tune.abc".


> Richard> I'm sure this is configurable, I wonder where ... 
> 
> There's a lot of stuff on the mailing lists about how to have
> lilypond-book use the same format as ly2dvi does -- let me know if you
> ever get it working.  I mostly use lilypond-book when I want to use
> different headers, e.g., in a whole book of Dowland songs, I don't
> necessarily want the "C: John Dowland" info on every piece.  

I'll look into all this; but not immediately.

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] Re: continuations

[Richard Robinson]

On Tue, Jul 22, 2003 at 08:47:59PM +, John Chambers wrote:
> I. Oppenheim writes:
> |
> | I think this broken continuation mechanism of the Old
> | Standard is one of the most serious design mistakes in
> | the whole ABC notation system.
> |
> | Should we continue to support it, or should we change
> | the standard to be more sane---giving up backward
> | compatibility? Maybe we should have a vote on this
> | issue?
> 
> We should classify the old scheme(s) as  a  minor  mistake,
> and  correct  it  in  the  official standard.  Then it will
> finally be clear how  programs  should  implement  it,  and
> programs  that  skip  lines  to  find the continuation will
> simply be buggy.  But it's an easy bug to fix.

I'd vote for that.

> (And we'll still have the even more minor problem caused by
> the  fact that some programmers will replace the '\' with a
> space, while  others  will  delete  it  plus  the  newline,
> causing  the  two  lines  to be joined without a separator.
> This is a problem that still  plagues  several  programming
> languages.   It's  made  worse  by the fact that there's no
> logical solution; both ways work equally well.   Quandaries
> like  this  are  almost impossible for a group of humans to
> ever solve.  ;-)

I suggest that the second works slightly better than the first,
since it allows the possibility of writing a long group of beamed
notes over more than one line, in the remote and unlikely event that
anybody'd want to do that. 

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

[abcusers] RE : Abacus

[Forgeot Eric]

>"crash less" but still some?

yes, while I tried it and was writing this "review", I wrote "it
doesn't crash for nothing", but I got a crash at this very
moment...
I tried later and it generally crashes after I copy and paste in
the box (after removing the notes, but I guess the previous
headers [since it's not full edition] can do some interference).
I've just made it crash now, I did this, and all was fine until I
hit "F7" for full edition. I get "Error 9, indice outside the
range" (translated from french)
Before that I played a bit with the clef option, I don't know if
it's linked. You can try too, you'll see. 

>Well, AbcMus doesn't display the score on the screen at the same
>time 
>so it's got more room 

as you prefer. It's just for ex. if you have in the header a C:
field, you can't see it at all, unless you go to full edition. In
the case you have the full abc, even if you can't display it in
the whole window, at least you can scroll to adjust it. I find it
more rational than lacking some fields in the pre-made header
viewer. 
I don't say it for me, Abacus is nice but so far I'm used to
abcm2ps + abc2midi... but I'll recommend it to other pple.


___
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

[abcusers] Re: continuations

[John Chambers]

I. Oppenheim writes:
|
| I think this broken continuation mechanism of the Old
| Standard is one of the most serious design mistakes in
| the whole ABC notation system.
|
| Should we continue to support it, or should we change
| the standard to be more sane---giving up backward
| compatibility? Maybe we should have a vote on this
| issue?

Actually, there is little backward  compatibility  to  give
up,  because  current  abc  tools  have  a  great  deal  of
incompatibility in how they implement continuations.

As has been discussed before, the basic problem is with the
idea  that  a  continuation of a line means to join it with
the next line "of the same type".  This turns out to  be  a
very  fuzzy  phrase, and different programmers interpret it
in very different ways.  As a result, abc from other people
sometimes  won't work until you change the continuations to
be whatever your abc tool expects.

This has been thrashed out for many  programming  languages
over  the  past several decades.  It turns out there's only
one rule that will actually be implemented the same by  all
programmers,  and  it's  also the only rule that users will
all understand the same way.  This is that the continuation
('\' in abc as in many programming languages) just means to
join the current line to the next line.

If we attempt  to  have  the  continuation  mechanism  skip
lines,  we  make life very difficult for all of us, because
there is no real hope that all programmers  will  implement
this skipping the same way.

We should classify the old scheme(s) as  a  minor  mistake,
and  correct  it  in  the  official standard.  Then it will
finally be clear how  programs  should  implement  it,  and
programs  that  skip  lines  to  find the continuation will
simply be buggy.  But it's an easy bug to fix.

(And we'll still have the even more minor problem caused by
the  fact that some programmers will replace the '\' with a
space, while  others  will  delete  it  plus  the  newline,
causing  the  two  lines  to be joined without a separator.
This is a problem that still  plagues  several  programming
languages.   It's  made  worse  by the fact that there's no
logical solution; both ways work equally well.   Quandaries
like  this  are  almost impossible for a group of humans to
ever solve.  ;-)

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

Re: [abcusers] About the choice of '!'

[Jean-Francois Moine]

On Mon, 21 Jul 2003 13:08:29 +0200 (CEST), Guido Gonzato <[EMAIL PROTECTED]> 
wrote:
[snip]
>BTW - Jean-François, how do you tell whether '!' is a line break or the
>start of a decoration?

When encountering a '!', I scan forward. If I find any of "|[:]"
(and soon a blank or tab), or the end of line, it is a line break.
Else, if I find a '!', it is a decoration. This means that a
decoration name cannot contain any of these characters (for instance,
'!da Capo!' or '![rit]!' will not work, while '!crescendo(!' is OK).

Does this solve all the problems?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
|   http://moinejf.free.fr/
Pépé Jef|   mailto:[EMAIL PROTECTED]
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] Sub-ideal beaming in abcm2ps-3.6.0

[Jean-Francois Moine]

On Tue, 15 Jul 2003 21:43:07 +0100, Calum Galleitch 
<[EMAIL PROTECTED]> wrote:
>I've encountered an interesting behaviour trying to transcribe the Black Bear.  
[snip]
>This produces (with abcm2ps-3.6.0) the following result (sorry about the 
[snip]
>Is there a fix?

It should be fixed in 3.6.4. I know there are still problems with
things like:

L:1/8
Ahttp://moinejf.free.fr/
Pépé Jef|   mailto:[EMAIL PROTECTED]
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] Use of ! (and another source issue)

[Jean-Francois Moine]

On Mon, 21 Jul 2003 08:28:40 +0200 (CEST), Guido Gonzato <[EMAIL PROTECTED]> 
wrote:
>On Sat, 19 Jul 2003, Jack Campin wrote:
>
>> Now, there is one ASCII character that is nearly invisible and hasn't
>> been used for anything else in ABC yet.  So I propose that ` should
>> be completely ignored by both player and formatter programs, with its
[snip]
>to me it seems OK: as long as major developers add this feature (and I
>imagine it's very easy to implement), I can see no reason not to include `
>in the standard.

Yes, very easy: I had to change only 3 characters in the parser...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
|   http://moinejf.free.fr/
Pépé Jef|   mailto:[EMAIL PROTECTED]
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] expected abc audience

[I. Oppenheim]

On Tue, 22 Jul 2003, Laura Conrad wrote:

> Irwin> Line ... shnei.abc: 21: Huh?  Don't understand
> Irwin> G|G2G2A4|(FEF) D (A2G) G|c2c2(B2c2)|(f2e2)e2d G|
> Irwin> shnei.abc: 24: Huh?  Don't understand
> Irwin> G2G G A4|(FE) F D (A2G) d|d2g g (fedc)|(B2A2)A2G3/2 G/2|
> Irwin> shnei.abc: 26: Huh?  Don't understand
> Irwin> g2 d d (_e2c2)|(_ec) B c (dBG) G|g2d2(_e3c)|(dcBc) d2d2|

> So what needs to change in your abc is the
>
>  w:She-nei zei-tim nich-__ra-tim_\
>  w:be-gan na-'ul_ yats-_hi-ru. Le-
>
> construct.

That's fine if I know that; then I can adjust
the file.

However, I do not think that the error messages given
above were caused by that  \  char...

> if I were going to continue a w: line, I would have
> guessed that you *don't* repeat the w: on the
> continuation.

Unfortunately, the old standard prescribed that.

I think this broken continuation mechanism of the Old
Standard is one of the most serious design mistakes in
the whole ABC notation system.

Should we continue to support it, or should we change
the standard to be more sane---giving up backward
compatibility? Maybe we should have a vote on this
issue?

> I suspect someone's arm could be twisted to expand the abc2ly section
> in the documentation, but surely the man page would be the wrong place
> for details about abc syntax?

It's the first place I would look for it---IMHO, the
[bugs] section of the manpage should list all the
problematic ABC constructs.

In any event, the error messages should make clear what
exactly is not understood in the ABC notation.


 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] expected abc audience

[Laura Conrad]

> "Irwin" == I Oppenheim <[EMAIL PROTECTED]> writes:


Irwin> When I tried one my tunes, I got this output:

Irwin> <<
Irwin> abc2ly from LilyPond 1.6.10
Irwin> Parsing `shnei.abc'...
Irwin> Line ... shnei.abc: 21: Huh?  Don't understand
Irwin> G|G2G2A4|(FEF) D (A2G) G|c2c2(B2c2)|(f2e2)e2d G|


Irwin> shnei.abc: 24: Huh?  Don't understand
Irwin> G2G G A4|(FE) F D (A2G) d|d2g g (fedc)|(B2A2)A2G3/2 G/2|


Irwin> shnei.abc: 26: Huh?  Don't understand
Irwin> g2 d d (_e2c2)|(_ec) B c (dBG) G|g2d2(_e3c)|(dcBc) d2d2|

Irwin> lilypond output to: `shnei.ly'...
>>> 

Irwin> I must say that I do not find the comment "Huh? Don't
Irwin> understand" very helpful.

No, lots of people say that.  

Running your file through the 1.7.27 abc2ly doesn't give any error
messages, but then lilypond complains:

/home/lconrad/music/drinking/book/test.ly:9:42: error: syntax error, unexpected E_CHAR:
She- nei zei- tim nich-  _  _ ra- tim _  \

So what needs to change in your abc is the 

 w:She-nei zei-tim nich-__ra-tim_\
 w:be-gan na-'ul_ yats-_hi-ru. Le-

construct.  The bug is really that it puts the \ into the lily file --
it should just use it to escape the newline.  But I'm not sure what
the putative abc standard would say about this construction -- if I
were going to continue a w: line, I would have guessed that you
*don't* repeat the w: on the continuation.  

Irwin> The manpage didn't give any information on which ABC
Irwin> constructs are implemented an which not, so I'm clueless.

I suspect someone's arm could be twisted to expand the abc2ly section
in the documentation, but surely the man page would be the wrong place
for details about abc syntax?

-- 
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] expected abc audience

[I. Oppenheim]

Laura,

this one also didn't work:

<<
abc2ly from LilyPond 1.6.10
Parsing `740.abc'...
Line ... 740.abc: 7: Huh?  Don't understand
[
 1"Dm"F2DF E2"A7"A2:|[2"Dm"F2"A7"E2"Dm"D2"C7"C2

740.abc: 10: Huh?  Don't understand
[
 1"F"F2A G F2zF|F C C F F _E E D|"Dm"D2_D2"C7"C2z2:|

740.abc: 11: Huh?  Don't understand
[
 2F2A G F2zA|"A7"A G G F F E E D|"Dm"D4-D A =B ^c|

lilypond output to: `740.ly'...
>>

<<
X:1
T:7:40
M:4/4
L:1/8
K:Dm
|:"Dm"D2A,DA,DA,D|F2DFDFDF|A2FA"Gm"G2DG|
[1"Dm"F2DF E2"A7"A2:|[2"Dm"F2"A7"E2"Dm"D2"C7"C2
|:"F"zA B c B A G F|zA B c B A G F|zA B c "D7"d c B A|
"Gm"G2B A G2z2|"C7"zG A B c B A G|
[1"F"F2A G F2zF|F C C F F _E E D|"Dm"D2_D2"C7"C2z2:|
[2F2A G F2zA|"A7"A G G F F E E D|"Dm"D4-D A =B ^c|
d3A c B A G|F E D3D E F|"Gm"G2B2A G "A7"F G|
"Dm"A4-A A =B ^c|d3A c B A G|F E D3D E F|
"Gm"G2B2A G "A7"F E|"Dm"D4z4|]
>>

What is not understood?


 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] expected abc audience

[I. Oppenheim]

Laura,

When I tried one my tunes, I got this output:

<<
abc2ly from LilyPond 1.6.10
Parsing `shnei.abc'...
Line ... shnei.abc: 21: Huh?  Don't understand
G|G2G2A4|(FEF) D (A2G) G|c2c2(B2c2)|(f2e2)e2d G|


shnei.abc: 24: Huh?  Don't understand
G2G G A4|(FE) F D (A2G) d|d2g g (fedc)|(B2A2)A2G3/2 G/2|


shnei.abc: 26: Huh?  Don't understand
g2 d d (_e2c2)|(_ec) B c (dBG) G|g2d2(_e3c)|(dcBc) d2d2|


lilypond output to: `shnei.ly'...
>>

I must say that I do not find the comment "Huh? Don't
understand" very helpful. The manpage didn't give any
information on which ABC constructs are implemented an
which not, so I'm clueless.

Below is the source code of the tune:
<<
%%postscript /dlw {0.5 setlinewidth} bdef
%%composerfont Helvetica 14
%%footerfont Helvetica 12
%%gchordfont Helvetica 12
%%headerfont Helvetica 12
%%infofont Helvetica-Oblique 14
%%partsfont Helvetica 15
%%subtitlefont Helvetica 16
%%tempofont Helvetica-Bold 15
%%textfont  Helvetica 16
%%titlefont Helvetica 18
%%vocalfont Helvetica 14
%%wordsfont Helvetica 16

X:1
T:Shenei Zeitim
C:Traditionally Amsterdam
M:4/4
L:1/8
K:C
G|G2G2A4|(FEF) D (A2G) G|c2c2(B2c2)|(f2e2)e2d G|
w:She-nei zei-tim nich-__ra-tim_\
w:be-gan na-'ul_ yats-_hi-ru. Le-
G2G G A4|(FE) F D (A2G) d|d2g g (fedc)|(B2A2)A2G3/2 G/2|
w:rosh ke-ha-tim ve-_'ef-ra-tim_ she-tei a-ta-rot___ yach-_ti-ru. Ve-
g2 d d (_e2c2)|(_ec) B c (dBG) G|g2d2(_e3c)|(dcBc) d2d2|
w:al me-no-rah_ ha-_te-ho-rah__ ke-mo nei-rot_ yaz-___hi-ru.
c4(BAG) G|(cde) c (dBG) G|A3/2 A/2 G (3G/2 G/2 G/2 (Aagf)|e2d2c4|]
w:Hen, hen__ ba-ma-__cha-neh__ el mul pe-nei ha-me-no-rah___ ya-'i-ru.
>>

What went wrong?


 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] expected abc audience

[Laura Conrad]

> "Richard" == Richard Robinson <[EMAIL PROTECTED]> writes:

Richard> I notice it prints without title or other text. 

You must be using lilypond-book?  If you use the standard ly2dvi, it
prints the Title and Composer.

Richard> I'm sure this is configurable, I wonder where ... 

There's a lot of stuff on the mailing lists about how to have
lilypond-book use the same format as ly2dvi does -- let me know if you
ever get it working.  I mostly use lilypond-book when I want to use
different headers, e.g., in a whole book of Dowland songs, I don't
necessarily want the "C: John Dowland" info on every piece.  

-- 
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] expected abc audience

[Richard Robinson]

On Tue, Jul 22, 2003 at 08:45:47PM +0200, I. Oppenheim wrote:
> > to /etc/apt/sources.list, and then "apt-get update && apt-get upgrade"
> > will take you to lilypond 1.6.10. I've just done this.
> 
> Same for me. thanks!

! that's a fast connection you've got there :)

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] expected abc audience

[Richard Robinson]

On Tue, Jul 22, 2003 at 07:42:48PM +0100, Richard Robinson wrote:
> 
> to /etc/apt/sources.list, and then "apt-get update && apt-get upgrade"
> will take you to lilypond 1.6.10. I've just done this.

Whereupon, yes, that missing-repeat thing is indeed fixed.

I notice it prints without title or other text. I'm sure this is
configurable, I wonder where ... Aargh ! I mustn't be fiddling with
this now, I've got to overhaul my clarinet and revise some tunes,
I've got gigs coming up. *wail*

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] expected abc audience

[I. Oppenheim]

> to /etc/apt/sources.list, and then "apt-get update && apt-get upgrade"
> will take you to lilypond 1.6.10. I've just done this.

Same for me. thanks!


 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] expected abc audience

[Richard Robinson]

On Tue, Jul 22, 2003 at 08:17:22PM +0200, I. Oppenheim wrote:
> On Tue, 22 Jul 2003, Laura Conrad wrote:
> 
> > Richard> So it's a circularity problem - outofdate abc2ly doesn't
> > Richard> do what I'm wanting so I hadn't clocked it as "important"
> 
> When I recently did a "apt-get install lilypond", I
> assumed it would download the latest stable version, as
> it does for all other packages I use. Now I checked,
> and it turned out to be version 1.4.12 from 2001!
> 
> How come?

Debian "stable" packages _do_ tend to be somewhat less than "cutting
edge".

I've just been investigating Laura's apt sources suggestion - it very
nearly works, but s/stable/woody/ - ie, add a line

deb ftp://ftp.lilypond.org/pub/LilyPond/binaries/debian woody .

to /etc/apt/sources.list, and then "apt-get update && apt-get upgrade"
will take you to lilypond 1.6.10. I've just done this.


-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] expected abc audience

[I. Oppenheim]

On Tue, 22 Jul 2003, Laura Conrad wrote:

> Richard> So it's a circularity problem - outofdate abc2ly doesn't
> Richard> do what I'm wanting so I hadn't clocked it as "important"

When I recently did a "apt-get install lilypond", I
assumed it would download the latest stable version, as
it does for all other packages I use. Now I checked,
and it turned out to be version 1.4.12 from 2001!

How come?

Maybe you could report that there seems to be a problem
with the Debian support for Lilypond?


 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] expected abc audience

[Laura Conrad]

> "Richard" == Richard Robinson <[EMAIL PROTECTED]> writes:

>> Can you send me that file?  I thought I had that fixed

Richard> You probably have - it's just the same old much-argued missing
Richard> start-repeat at the beginning of the opening bar. Some ABC apps
Richard> complain, as well, but recover.

OK, if there's nothing special, the test I just did not only didn't
crash, but did actually put in the \repeat {...}, rather than just the
\bar ".|".  But I got a crash when I put a second one in, i.e. 

stuff :| more stuff :|

I'll put that on the list to fix.  Or at least to give an error message.

Richard> The way I do it is to let Debian manage everything except
Richard> the things where I want to be up to the edge (mainly
Richard> abc-related stuff), which I install myself in /usr/local
Richard> ; I don't really want to get involved with debian
Richard> unstable, I like a solid system.

You might be able to  get 6.9 or so by adding:

deb ftp://ftp.lilypond.org/pub/LilyPond/binaries/debian stable .

to /etc/apt/sources.list.  I also had

deb ftp://ftp.lilypond.org/pub/LilyPond/binaries/debian unstable .

but I don't think that had any effect until I started messing with
unstable by setting pin priorities.

Richard> So it's a circularity problem - outofdate abc2ly doesn't
Richard> do what I'm wanting so I hadn't clocked it as "important"
Richard> so I haven't kept up to date ... I may have been wrong
Richard> about that, lilypond-book might just better a better
Richard> wheel than the ones I've cooked up for myself.

I like it a lot.  It lets you pretty much use music like any other
latex kind of thing (i.e., much easier than a graphic entity).

-- 
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] expected abc audience

[Richard Robinson]

On Tue, Jul 22, 2003 at 12:30:10PM -0400, Laura Conrad wrote:
> > "Richard" == Richard Robinson
> > <[EMAIL PROTECTED]> writes:
> 
> Richard> No, it wasn't that, just the problem of variant
> Richard> dialects. ...
> 
> I'm really out of touch with abcm2ps development ...
> 
> Richard> To be fair, I've just tried it on a big version of the
> Richard> Black Joak, and it didn't report any problems there
> Richard> (though lilypond subsequently blew up on a missing
> Richard> start-repeat ...)
> 
> Can you send me that file?  I thought I had that fixed

You probably have - it's just the same old much-argued missing
start-repeat at the beginning of the opening bar. Some ABC apps
complain, as well, but recover.

I know it would be "better practice" to put it in, but there's so
much ABC that doesn't. Including mine; because it's obvious and saves
typing ...

> Richard> [ It may be relevant to mention that I'm running Debian
> Richard> Linux (stable), and therefore probably quite a long way
> Richard> behind "current" versions. ]
> 
> If it's 1.4, you should upgrade.  You can get 1.6 from
> ftp://ftp.lilypond.org/pub/LilyPond/binaries/debian.  Unfortunately,
> upgrading to 1.7, which is soon to become the next 1.8 stable version,
> will require getting some stuff from unstable.  But I had 1.6 on a
> pure stable system.


Yes. 1.4.12. So I should probably update before I make any further
comment (well, I should have done _before_, really).

The way I do it is to let Debian manage everything except the things
where I want to be up to the edge (mainly abc-related stuff), which
I install myself in /usr/local ; I don't really want to get involved
with debian unstable, I like a solid system.

So it's a circularity problem - outofdate abc2ly doesn't do what I'm
wanting so I hadn't clocked it as "important" so I haven't kept up to
date ... I may have been wrong about that, lilypond-book might just
better a better wheel than the ones I've cooked up for myself.

I'll have a look at this, and comment further when I have a more up to
date idea ... it may be a while, though.

> Richard> My thought was just that, this is possibly an important
> Richard> abc-reading program, but I don't think we've heard from
> Richard> its developers at all, on this list ? And maybe there are
> Richard> other such.
> 
> I'm probably the most active maintainer, although I haven't done
> anything to 1.7.  And I do mention it from time to time, but don't
> seem to get much interest back.  I don't know why, since it solves a
> lot of the problems people discuss here.

I'm sorry, I hadn't realised you were involved with its development.


> Since someone finally asked, I have daydreams, which may turn into
> actual coding in the next couple of months, of enabling both
> abctab2ps-style tablature and figured bass in abc2ly.  You do *not*
> want to type the lilypond input for either one, but the lilypond
> output is really nice.  See
> http://www.laymusic.org/music/veracini/book/sonatas.pdf for examples
> of the figured bass.

Yes, it does look nice.

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] multivoice & linecontinuation

[Laura Conrad]

> "Irwin" == I Oppenheim <[EMAIL PROTECTED]> writes:

Irwin> << % variant A
Irwin> G2G2A4 | (FEF) D (A2G) G|\
Irwin>  M:4/4
Irwin>  K:C
Irwin>  c2c2(B2c2) |
>>> 

I think this is actually an example of a recommended syntax in some
pretty widespread documentation. (Probably something that comes with
abcMIDI or abc2ps.)  So you can deprecate it, but you aren't going to
be able to not handle it, if you want to deal with what's out there.


-- 
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] New standard(s)

[Richard Robinson]

On Tue, Jul 22, 2003 at 05:47:33PM +0100, Phil Taylor wrote:
> I. Oppenheim wrote:
> 
> >Here in continental Europe, we have Euros, kilometers,
> >liters, celsius, and 1/128th notes, and we do not
> >understand anything more exotic than that...
> 
> Goodness, and they used to accuse us Brits of being
> insular...
> 
> Anyway it's litres, as I'm sure your francophone neighbours
> would agree.
> 
> Actually it's quite interesting that this group has always
> used fractions to discuss note lengths, despite the fact
> that at least half of the regular contributors are British.
> Presumably that's because Chris Walshaw used this in
> his original formulation of the abc standard.

Not to mention M: itself - Metre. No, that should be
Meter, should it ? <*wail*>

> There's also been a ding dong battle on this subject over
> on uk.music.folk.  A new newsgroup has been proposed,
> uk.music.notation, and the argument is over whether
> quarter notes and the like will be permitted.  Personally,
> I couldn't give a monkey's.

And people are saying they wonder if there's enough to
discuss ... 

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] New standard(s)

[Bernard Hill]

In message <[EMAIL PROTECTED]>, I. Oppenheim
<[EMAIL PROTECTED]> writes
>On Tue, 22 Jul 2003, Bernard Hill wrote:
>
>> >not to speak of hemisemidemiquavers
>> It's actually hemidemisemiquavers.
>> But my Australian customers explicly told me they use hdsqs.
>> And 1/128th notes are semihemidemisemiquavers
>
>You must be kidding! Ludicrous!

Why? I admit that there is logic to the US terms, but I have to think
carefully "how many flags has a 1/32nd note?" whereas I know a
demisemiquaver has 3.
>
>> Most musicians can translate though
>
>I must admit I cannot, 

then you have never read a British or Australian book on music I take
it.

>nor can I make much sense of
>miles, fl.oz, Fahrenheit, gallons, and all those other
>outlandish measurements you guys have mantioned.

>
>> However personally I prefer the US terms in that area.
>
>It's not something specifically American; the
>fraction designations for note lengths are used and
>understood throughout the world, save for the United
>Kingdom, it seems.

No, as I say it's also Australasia. In fact if you add up the countries
or inhabitants it's probably more use the British terms. I know they do
in many places in Europe, and I certainly have Dutch customers who use
them when writing to me.

And I didn't say we don't understand them. We are broad-minded enough to
read US books and dictionaries and program notes etc.

>
>Here in continental Europe, we have Euros, kilometers,
>liters, celsius, and 1/128th notes, and we do not
>understand anything more exotic than that...

Of course you do. You know about dollars and pounds for exchange rates.
The French even have "livres" = pounds (weight). And I have read French
technical articles on chemical engineering which refer to pouce = inch.




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] New standard(s)

[Phil Taylor]

I. Oppenheim wrote:

>Here in continental Europe, we have Euros, kilometers,
>liters, celsius, and 1/128th notes, and we do not
>understand anything more exotic than that...

Goodness, and they used to accuse us Brits of being
insular...

Anyway it's litres, as I'm sure your francophone neighbours
would agree.

Actually it's quite interesting that this group has always
used fractions to discuss note lengths, despite the fact
that at least half of the regular contributors are British.
Presumably that's because Chris Walshaw used this in
his original formulation of the abc standard.

There's also been a ding dong battle on this subject over
on uk.music.folk.  A new newsgroup has been proposed,
uk.music.notation, and the argument is over whether
quarter notes and the like will be permitted.  Personally,
I couldn't give a monkey's.

Phil Taylor


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

Re: [abcusers] multivoice & linecontinuation

[I. Oppenheim]

On Tue, 22 Jul 2003, Phil Taylor wrote:

> Yes, I'm inclined to agree.  The only exception
> should be where there is some limitation on line
> length (e.g. the tune is going to be emailed), then
> continuation should only be used to continue on the
> following line.

I would prefer it STRONGLY that the end-of-line
backspace would always mean: continue on the next
physical line of music.

However it seems that there is legacy code around
that expects these lines:

<< % variant A
G2G2A4 | (FEF) D (A2G) G|\
 M:4/4
 K:C
 c2c2(B2c2) |
>>

to be interpreted as equivalent to:

<< % variant B
G2G2A4 | (FEF) D (A2G) G| [M:4/4] [K:C] c2c2(B2c2) |
>>


So I would like to know from you all, if any of you
would have serious problems if from now on, backward
compatibility with variant A would be discontinued in
favour of a simpler continuation mechanism.

> > % variant 2
> >[V1]:abc|abc|abc|abc|
> >[V2]:Abc|Abc|Abc|Abc|
> >[V1]:def|def|def:|
> >[V2]:Def|Def|Def:|

> I'd prefer them in the order 2,3,1.

I also prefer variant 2. Anyone who strongly disagrees?

I must note, however, that it should be [V:1] and not
[V1]: !


 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] expected abc audience

[Laura Conrad]

> "Richard" == Richard Robinson
> <[EMAIL PROTECTED]> writes:

Richard> No, it wasn't that, just the problem of variant
Richard> dialects. The last time I tried it (a couple of days ago,
Richard> after the mention in uc.o.l reminded me of it) I hit a
Richard> tune I'd just typed up which specifically wanted an
Richard> acciaccatura, abcm2ps's {/gracenote}. Which abc2ly didn't
Richard> like ...

I'm really out of touch with abcm2ps development (because it doesn't
deal at all well with most of the music *I* do).  But that doesn't
sound like it would be difficult to implement, if you let me know
about such things.  Also, you could check whether making the lilypond
print acciaccatura instead of standard gracenote can be done with a
%%LY statement.

Richard> To be fair, I've just tried it on a big version of the
Richard> Black Joak, and it didn't report any problems there
Richard> (though lilypond subsequently blew up on a missing
Richard> start-repeat ...)

Can you send me that file?  I thought I had that fixed.  But you're
better off pairing repeats, because then lily knows that you have a
repeat structure.  If you don't pair them, she just tries to put in the
barlines she thinks you want, but you don't have the options like
unfolding the repeats or doing more alternative endings that you would
if lily knew your repeat structure.

Richard> [ It may be relevant to mention that I'm running Debian
Richard> Linux (stable), and therefore probably quite a long way
Richard> behind "current" versions. ]

If it's 1.4, you should upgrade.  You can get 1.6 from
ftp://ftp.lilypond.org/pub/LilyPond/binaries/debian.  Unfortunately,
upgrading to 1.7, which is soon to become the next 1.8 stable version,
will require getting some stuff from unstable.  But I had 1.6 on a
pure stable system.

Richard> My thought was just that, this is possibly an important
Richard> abc-reading program, but I don't think we've heard from
Richard> its developers at all, on this list ? And maybe there are
Richard> other such.

I'm probably the most active maintainer, although I haven't done
anything to 1.7.  And I do mention it from time to time, but don't
seem to get much interest back.  I don't know why, since it solves a
lot of the problems people discuss here.

Richard> Oh, I can do that stuff ... but if you use lilypond like
Richard> that, haven't you cut yourslef off from ABC ?

It's true that it's a nuisance when you have to correct both an ABC
file and a lilypond file for the same error.  But my website generally
has all of ABC, lilypond, MIDI, and pdf, and I get mail from users of
all of those formats.  

Richard> I don't think I'd want to use lilypond as primary storage
Richard> for tunes, it's too wordy.

I save both.  My database that describes what I put on the web has a
field for whether the lilypond is a straight conversion from the ABC
or has extra information in it.  I have a %%LY statement that allows
me to put some of the lilypond information into the ABC file, but
anything that fiddles with the actual notes (for instance, cautionary
accidentals) has to be edited in the lilypond file.

Richard> But if an abc2ly could read, say, a
Richard> new-improved-standard-ABC, then conversion-on-the-fly
Richard> might make lilypond-book a better alternative to my own
Richard> ABC->ps-via-LaTeX scripts.

I don't feel particularly sanguine about reaching consensus for a
new-improved-standard (based on having been following this list for
almost 10 years), but anything that doesn't break backward
compatibility that you really want to use, I'll try to implement.

Since someone finally asked, I have daydreams, which may turn into
actual coding in the next couple of months, of enabling both
abctab2ps-style tablature and figured bass in abc2ly.  You do *not*
want to type the lilypond input for either one, but the lilypond
output is really nice.  See
http://www.laymusic.org/music/veracini/book/sonatas.pdf for examples
of the figured bass.

-- 
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] multivoice & linecontinuation

[Phil Taylor]

Arent Storm wrote:

>Where it comes to to line continuation in multivoice and/or
>in-line lyrics things can get (unneccessarily) complicated.
>IMO line continuation should be allowed only for single voice.
>For instance, the nicely text-layed-out multivoice canzonetta.abc
>from  the 2.0 standard would become unreadable with
>line continuation used.

Yes, I'm inclined to agree.  The only exception should be
where there is some limitation on line length (e.g. the tune
is going to be emailed), then continuation should only be
used to continue on the following line.

>Also, when using abc to store complex scores, I think that
>human readablity is of very small importance, if at all; it
>will be uncomprehensable anyway.

Not all multivoice scores are impossible to read.  Jack Campin
has some beautifully-constructed abcs of tunes in two or three
voices.

>The 3 different approaches of writing down multivoice I dislike.
>I would very much prefer one approach the:  voice by voice
>
>V1:
>abc|abc|abc|abc
>def|def|def:|
>V2:
>Abc|Abc|Abc|Abc
>Def|Def|Def:|
>
>over
>
>[V1]:abc|abc|abc|abc|
>[V2]:Abc|Abc|Abc|Abc|
>[V1]:def|def|def:|
>[V2]:Def|Def|Def:|
>
>and (least)
>
>V1:
>abc|abc|abc|abc|
>V2:
>Abc|Abc|Abc|Abc|
>V1:
>def|def|def:|
>V2:
>Def|Def|Def:|

I'd prefer them in the order 2,3,1.

>The first is what MusiCAD is exporting, while importing all three.
>As said before -  in multivoice scores - human readability
>won't have to be/should not be/cannot be a major issue.

BarFly won't be able to display the output from MusiCAD, then.  Why
not give your users the option of all three?  If MusiCAD prints
music it must know where the line ends should come, so options
2 and 3 should be possible.

Phil Taylor


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

Re: [abcusers] New standard(s)

[I. Oppenheim]

On Tue, 22 Jul 2003, Bernard Hill wrote:

> >not to speak of hemisemidemiquavers
> It's actually hemidemisemiquavers.
> But my Australian customers explicly told me they use hdsqs.
> And 1/128th notes are semihemidemisemiquavers

You must be kidding! Ludicrous!

> Most musicians can translate though

I must admit I cannot, nor can I make much sense of
miles, fl.oz, Fahrenheit, gallons, and all those other
outlandish measurements you guys have mantioned.

> However personally I prefer the US terms in that area.

It's not something specifically American; the
fraction designations for note lengths are used and
understood throughout the world, save for the United
Kingdom, it seems.

Here in continental Europe, we have Euros, kilometers,
liters, celsius, and 1/128th notes, and we do not
understand anything more exotic than that...


 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] New standard(s)

[Bernard Hill]

In message <[EMAIL PROTECTED]>, John Chambers
<[EMAIL PROTECTED]> writes
>Bernard Hill writes:
>| In message <[EMAIL PROTECTED]>, John Chambers <[EMAIL PROTECTED]> 
>writes
>| > But if you measure it in,  say,  attoparsecs,
>| > this  is  the  definition of a parsec (and of the atto- prefix)."
>|
>| Love it! 1 attoparsec is approx 3.1cm or 1.2" ... as everyone knows 
>
>One of  my  favorite  "weird  unit"  stories  was  from  an
>American astronomer who also liked to cook. He said that he
>liked to write out recipes using the cubic attoparsec as  a
>unit  of  volume.  It turns out that 1 aPc^3 is about 0.998
>fluid ounce, close enough that in  a  recipe  it  makes  no
>difference.  It takes no longer to write than "fl.oz.". And
>nobody outside the US has any idea what a fluid  ounce  is,
>while  parsec  is  a  standard unit that you'll find in any
>physical reference book.  So this makes his recipes  usable
>by anyone, not just Americans.

20 fl oz= 1 pint, so 160 fl.oz = 1 (imperial) gallon :-)
>
>OTOH, I've heard musicians of the British persuasion  refer
>to  minims and crotchets and semidemiquavers.  Not one in a
>thousand American musicians could tell you what those terms
>actually mean.

Most musicians can translate though. However Music Publisher has a
"choose your language" option built in :-)


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] New standard(s)

[Bernard Hill]

In message <[EMAIL PROTECTED]>, Arent Storm
<[EMAIL PROTECTED]> writes
>
>>
>> OTOH, I've heard musicians of the British persuasion  refer
>> to  minims and crotchets and semidemiquavers.  Not one in a
>> thousand American musicians could tell you what those terms
>> actually mean.
>as well as allmost anyone elsewhere.
>not to speak of hemisemidemiquavers

It's actually hemidemisemiquavers.

But my Australian customers explicly told me they use hdsqs.

And 1/128th notes are semihemidemisemiquavers 

However personally I prefer the US terms in that area.

But not in "measure" for "bar". In the UK, measure has a broader term in
dancing, and it seems reasonable that barlines should divide the music
into bars, not measures :-)



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] About the choice of '!'

[Richard Robinson]

On Mon, Jul 21, 2003 at 01:08:29PM +0200, Guido Gonzato wrote:
> On Mon, 21 Jul 2003, Bernard Hill wrote:
> 
> > >Interestingly enough, I can't find any mention of the use of "*" for 
> > >right justified line breaking in Guido's ABC 2.0 draft.  This draft 
> > >spec tentatively calls for the use of "!" for this purpose.
> > 
> > Probably because it wasn't in 1.x...
> 
> whenever I considered adding a new feature in the draft, I turned my
> attention to stuff already implemented by important applications. Being
> '!' in abc2win, I supposed this was the way to go. It's also been added in
> abcm2ps, too, and I suppose more applications will follow suit.

So it is. At last, a chance to play with this ...

> BTW - Jean-Fran?ois, how do you tell whether '!' is a line break or the
> start of a decoration?

Odd precedences here ?

X:1
T:Test
M:3/4
K:A
AB cd ef | fe dc BA | !trill! ! AB cd ef | fe dc BA |]

is okay, but

X:1
T:Test
M:3/4
K:A
AB cd ef | fe dc BA | ! !trill! AB cd ef | fe dc BA |]

complains "Decoration not terminated" and loses the last 2 bars.
This seems rather counter-intuitive ?

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] expected abc audience

[Richard Robinson]

On Tue, Jul 22, 2003 at 10:07:39AM -0400, Laura Conrad wrote:
> > "Richard" == Richard Robinson <[EMAIL PROTECTED]> writes:
> 
> Richard> Which reminded me of abc2ly. I looked at that once and
> Richard> found it wouldn't deal with large amounts of my abc
> 
> Why not?  If it's the one tune per run limitation, abcselect will deal
> with that for you.

No, it wasn't that, just the problem of variant dialects. The last time
I tried it (a couple of days ago, after the mention in uc.o.l reminded me
of it) I hit a tune I'd just typed up which specifically wanted an
acciaccatura, abcm2ps's {/gracenote}. Which abc2ly didn't like ...
To be fair, I've just tried it on a big version of the Black Joak,
and it didn't report any problems there (though lilypond subsequently
blew up on a missing start-repeat ...) [ It may be relevant to mention
that I'm running Debian Linux (stable), and therefore probably quite
a long way behind "current" versions. ]

My thought was just that, this is possibly an important abc-reading
program, but I don't think we've heard from its developers at all,
on this list ? And maybe there are other such.


> Richard> ... which leads me to realise we've never really
> Richard> mentioned it. But it's abc-reading software, whatever the
> Richard> output (I think Laura uses it, I'm not sure how many
> Richard> others do).
> 
> I don't think very many.  I had a correspondence with one user last
> Spring.  I wouldn't recommend it to anyone who didn't also write unix
> scripts pretty fluently. E.g. for running abcselect on a file with
> multiple tunes, writing a latex file to include the output for all of
> them, and running lilypond on the ones that have changed.  But if you
> go to lilypond, you've suddenly removed an awful lot of the ABC
> limitations people here complain about.

Oh, I can do that stuff ... but if you use lilypond like that, haven't
you cut yourslef off from ABC ? I don't think I'd want to use lilypond
as primary storage for tunes, it's too wordy. But if an abc2ly could read,
say, a new-improved-standard-ABC, then conversion-on-the-fly might make
lilypond-book a better alternative to my own ABC->ps-via-LaTeX scripts.


-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

[abcusers] meta comments 2.0

[Arent Storm]

I would suggest that all meta-comments should be
prefixed with an appropriate string indicating the target. Like
%%FMT-composerfont Times-Bold 32
so that any abc-accepting can easily filter relevant 
settings for its context.

Every abc exporting/writing program should write some
fingerprint in every tune (not file) like:
%%APP-ProgramName or whatever, safely to be ignored
but probably useful for some other reason afterwards.

I support the idea of marking the intended abc-version
as a meta comment.
%%VER-abc20

Where score layout is indeed a layout topic, 
I prefer the %%staves style: 
  %%FMT-staves [1|2|3]
a lot over 
  V1:  options 
  V2:  options
  V3:  options

Arent


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

[abcusers] multivoice & linecontinuation

[Arent Storm]

Where it comes to to line continuation in multivoice and/or 
in-line lyrics things can get (unneccessarily) complicated.
IMO line continuation should be allowed only for single voice.
For instance, the nicely text-layed-out multivoice canzonetta.abc 
from  the 2.0 standard would become unreadable with 
line continuation used.
Also, when using abc to store complex scores, I think that
human readablity is of very small importance, if at all; it
will be uncomprehensable anyway. 

The 3 different approaches of writing down multivoice I dislike. 
I would very much prefer one approach the:  voice by voice

V1:
abc|abc|abc|abc
def|def|def:|
V2:
Abc|Abc|Abc|Abc
Def|Def|Def:|

over 

[V1]:abc|abc|abc|abc|
[V2]:Abc|Abc|Abc|Abc|
[V1]:def|def|def:|
[V2]:Def|Def|Def:|

and (least)

V1:
abc|abc|abc|abc|
V2:
Abc|Abc|Abc|Abc|
V1:
def|def|def:|
V2:
Def|Def|Def:|

The first is what MusiCAD is exporting, while importing all three.
As said before -  in multivoice scores - human readability 
won't have to be/should not be/cannot be a major issue. 

Arent


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

Re: [abcusers] New standard(s)

[Arent Storm]

- Original Message -
From: "John Chambers" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 3:59 PM
Subject: Re: [abcusers] New standard(s)


> Bernard Hill writes:
> | In message <[EMAIL PROTECTED]>, John Chambers <[EMAIL PROTECTED]>
writes
> | > But if you measure it in,  say,  attoparsecs,
> | > this  is  the  definition of a parsec (and of the atto- prefix)."
> |
> | Love it! 1 attoparsec is approx 3.1cm or 1.2" ... as everyone knows 
>
> One of  my  favorite  "weird  unit"  stories  was  from  an
> American astronomer who also liked to cook. He said that he
> liked to write out recipes using the cubic attoparsec as  a
> unit  of  volume.  It turns out that 1 aPc^3 is about 0.998
> fluid ounce, close enough that in  a  recipe  it  makes  no
> difference.  It takes no longer to write than "fl.oz.". And
> nobody outside the US has any idea what a fluid  ounce  is,
> while  parsec  is  a  standard unit that you'll find in any
> physical reference book.  So this makes his recipes  usable
> by anyone, not just Americans.
>
> OTOH, I've heard musicians of the British persuasion  refer
> to  minims and crotchets and semidemiquavers.  Not one in a
> thousand American musicians could tell you what those terms
> actually mean.
as well as allmost anyone elsewhere.
not to speak of hemisemidemiquavers

Arent

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

Re: [abcusers] expected abc audience

[Arent Storm]

From: "Richard Robinson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 3:54 PM
Subject: Re: [abcusers] expected abc audience

> I'm not sure if the distinction between abc-only software and
> converters-to-other-formats is meaningful - after all, midi, ps, png,
> whatever, are other file formats, too. 
I wouldn't regard .ps .png enz as musical relevant 
music strorage formats...
midi is a special case but not targetted towards engraving so
it is in most cases a very lossfull option. Importing midi will 
often lead to misinterpretations too. 
abc-to-other-music-storage and vice versa 
can be pretty much lossless.

> Surely the main point is that
> all software needs to parse ABC ?
abc-exporting-only software has not ;-)

Arent

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

Re: [abcusers] expected abc audience

[Laura Conrad]

> "Richard" == Richard Robinson <[EMAIL PROTECTED]> writes:

Richard> Which reminded me of abc2ly. I looked at that once and
Richard> found it wouldn't deal with large amounts of my abc

Why not?  If it's the one tune per run limitation, abcselect will deal
with that for you.

Richard> ... which leads me to realise we've never really
Richard> mentioned it. But it's abc-reading software, whatever the
Richard> output (I think Laura uses it, I'm not sure how many
Richard> others do).

I don't think very many.  I had a correspondence with one user last
Spring.  I wouldn't recommend it to anyone who didn't also write unix
scripts pretty fluently. E.g. for running abcselect on a file with
multiple tunes, writing a latex file to include the output for all of
them, and running lilypond on the ones that have changed.  But if you
go to lilypond, you've suddenly removed an awful lot of the ABC
limitations people here complain about.


Richard> I'm not sure if the distinction between abc-only software
Richard> and converters-toother-formats is meaningful - after all,
Richard> midi, ps, png, whatever, are other file formats,
Richard> too. Surely the main point is that all software needs to
Richard> parse ABC ?

I assumed that he didn't mention abc2ly and several other things
because they only go one way (unless you want to go through MIDI or
something disgusting like that).  

-- 
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] About the choice of '!'

[Richard Robinson]

On Tue, Jul 22, 2003 at 02:49:09PM +0100, Jon Freeman wrote:
> From: "Richard Robinson" <[EMAIL PROTECTED]>
> 
> > > But do they 'look' at the abc by means of software or directly.
> > > I have collected 1++ of them myself over the years
> > > (small and large collections/files) and find myself looking at
> > > the abc-source only if the software is behaving unexpectedly,
> > > so I would place the collectors group in (2).
> > > The idea of multiple tunes within one file I personally do not like
> > > much (I'd rather zip them when transferring)
> >
> > Interesting. It's always struck me as one of the useful points about
> > ABC, when dealing with several thousand tunes, that you don't have to
> > have them all in separate files.
> 
> Most of our stuff is in a database and I find it much easier to have the abc
> as a separte field, along with other filds like full lyrics, notes on the
> song, references to inexes like roud, laws, etc, than to have all the abc in
> one (or more) text files.

I think about doing that, about once a year on average. It starts out
looking like an obvious good idea, and each time I end up not able
to think of any great advantge it would give me, for my purposes.

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] expected abc audience

[Richard Robinson]

On Tue, Jul 22, 2003 at 11:29:17AM +0100, Jack Campin wrote:
> > When trying to fit abcusers in a few groups having
> >  [1] abc-sightreaders (without much need for software)
> >  [2] abc-collectors 
> >  [3] abc-software-only-users (1st language)
> >  [4] abc-as- interchange-file-format-users (2nd language)
> >
> > Two questions arise
> > - is this a meaningful division?
> > - if so, how large do we expect the groups to be?
> >
> > My answer to the first question is -of course- yes ;-)
> > The second is the hard one my first (wild)guess would be:
> >  1: <200  (1%)
> >  2: <500  (3%)
> >  3: >1000, <1 (30%)
> >  4: >1  (66%) the remainder
> > Any thoughts?
> 
> I don't know what the second category means.

It seems to have come out of an idea that some people make use of the
"information" fields ... stricly speaking, I suppose it'd be anyone who
doesn't delete an ABC file once they've printed/midi'ed/whatever'ed it ?
Or, how many tunes does it take to make a "collection" ?

> The third seems a wild overestimate - surely the only program
> that does interchange to any other general-purpose score format
> in a meaningful way is Bryan's Noteworthy convertor?

There was a posting recently on uk.comp.os.linux, from someone who
wants to make a book of mixed music & text. It looks as though the
"reccomended" approach is lilypond-book, which seems to behave as
Chris' abc2mtex did - write LaTeX with blocks of music (in lilypond,
rather than abc) which get picked out and converted.

Which reminded me of abc2ly. I looked at that once and found it wouldn't
deal with large amounts of my abc ... which leads me to realise we've
never really mentioned it. But it's abc-reading software, whatever the
output (I think Laura uses it, I'm not sure how many others do).

I'm not sure if the distinction between abc-only software and
converters-toother-formats is meaningful - after all, midi, ps, png,
whatever, are other file formats, too. Surely the main point is that
all software needs to parse ABC ?


-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] New standard(s)

[John Chambers]

Bernard Hill writes:
| In message <[EMAIL PROTECTED]>, John Chambers <[EMAIL PROTECTED]> writes
| > But if you measure it in,  say,  attoparsecs,
| > this  is  the  definition of a parsec (and of the atto- prefix)."
|
| Love it! 1 attoparsec is approx 3.1cm or 1.2" ... as everyone knows 

One of  my  favorite  "weird  unit"  stories  was  from  an
American astronomer who also liked to cook. He said that he
liked to write out recipes using the cubic attoparsec as  a
unit  of  volume.  It turns out that 1 aPc^3 is about 0.998
fluid ounce, close enough that in  a  recipe  it  makes  no
difference.  It takes no longer to write than "fl.oz.". And
nobody outside the US has any idea what a fluid  ounce  is,
while  parsec  is  a  standard unit that you'll find in any
physical reference book.  So this makes his recipes  usable
by anyone, not just Americans.

OTOH, I've heard musicians of the British persuasion  refer
to  minims and crotchets and semidemiquavers.  Not one in a
thousand American musicians could tell you what those terms
actually mean.

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

Re: [abcusers] About the choice of '!'

[Jon Freeman]

From: "Richard Robinson" <[EMAIL PROTECTED]>

> > But do they 'look' at the abc by means of software or directly.
> > I have collected 1++ of them myself over the years
> > (small and large collections/files) and find myself looking at
> > the abc-source only if the software is behaving unexpectedly,
> > so I would place the collectors group in (2).
> > The idea of multiple tunes within one file I personally do not like
> > much (I'd rather zip them when transferring)
>
> Interesting. It's always struck me as one of the useful points about
> ABC, when dealing with several thousand tunes, that you don't have to
> have them all in separate files.

Most of our stuff is in a database and I find it much easier to have the abc
as a separte field, along with other filds like full lyrics, notes on the
song, references to inexes like roud, laws, etc, than to have all the abc in
one (or more) text files.

On the other hand, I quite like the ability to have mulitple abc's in one
text file.  I think Jack Campin's modes is a great example of how it can
work well, even with other non abc text. I tried that one when I had a brief
play with Barfly.

We also use the multiple abcs in a text file on what we have for the Bronson
bits Phil Taylor gave us and possibly in the future would use other abc that
doesn't really fit (e.g. I don't think our song database would require 20
varients of a song) in the song database. Even I found it quite easy to
write a little php script to index the tunes in a text file...

Jon

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

Re: [abcusers] About the choice of '!'

[Arent Storm]

From: "Richard Robinson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 3:34 PM
Subject: Re: [abcusers] About the choice of '!'
> > > Please don't think me rude, but I think you've missed a very large
> > > category of users completely.
> > > These are people who record large collections of tunes
> > > (admittedly, each tune is likely to be a 'simple folk melody'
> > > with or without lyrics),
> > > often in the hundreds or  thousands of tunes, related by genre or origin.
> > > They will use abc instead of or in addition to tunebooks.  These people
> > > collect tunes and transcribe them, exchange them via email,
> > > publish them as a resource on the internet or as a collection
> > > on CD-ROM and also want to print them as
> > > dots or play them when required.  They need software to proofread or
> > > proofhear what they've entered, to index, to search, to compare tunes,
etc.
> > > Sophisticated typesetting is not likely to be a first-order requirement,
> > > certainly not at the expense of readability.
> >
> > But do they 'look' at the abc by means of software or directly.
> > I have collected 1++ of them myself over the years
> > (small and large collections/files) and find myself looking at
> > the abc-source only if the software is behaving unexpectedly,
> > so I would place the collectors group in (2).
> > The idea of multiple tunes within one file I personally do not like
> > much (I'd rather zip them when transferring)
>
> Interesting. It's always struck me as one of the useful points about
> ABC, when dealing with several thousand tunes, that you don't have to
> have them all in separate files.

When it comes to downloading/distributing: YES
When it comes to handeling: definately NO

Arent


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

[abcusers] Re: Abacus

[Bryancreer]

Eric Forgeot  wrote -

>There are good improvements in this new version, and it seems also
>it crash less, unlike the previous version. The midi rendering is
>good also. I think you already know for lyrics and multivoice :)
>(it lacks cruelly) but will there be a midi export as well?

"crash less" but still some?  One correspondent claims he crashed it six times in twenty minutes but I'm still waiting for the evidence.

>You made a "full abc view" (without display), it could have been
>maybe better to have a "full abc view + display". I guess some
>pple prefer to have full abc as default edition (AbcMus can do
>this well, switching from a mode to an other)

Well, AbcMus doesn't display the score on the screen at the same time so it's got more room and in the version I've got, it doesn't do Full ABC, just hides the header details and displays the tune in a bigger window.  Maybe it's moved on since then.  I can't see a desperate need for this.  I'll see what the customers say.

>Your package is still quite heavy to download. I noticed my
>MSwindows had already several or your big files used in the system
>folder (for VB basic I guess), so maybe you could propose a the
>normal package, and a light one for people who know they have
>already those special files ?

I'll have a look into this.  It's mainly a matter of phrasing the explanation so as not to confuse the technologically innocent.

>You could include a file with some abc samples

Good idea.

Thanks for the feedback.

Bryan

 

Re: [abcusers]New standard(s)

[John Chambers]

Bryan Creer writes:
| John Chambers wrote:
|
| >we can align our music with the very basic phenomena of the cosmos.
|
| Talking of which, didn't you guys have a little trouble aligning one of your
| probes with Mars because of a mix up between metric and Imperial?

Sure did.  And it led to a rash  of  people  repeating  the
observation that the great thing about standards is that we
have so many to choose from.


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

Re: [abcusers] About the choice of '!'

[Richard Robinson]

On Tue, Jul 22, 2003 at 11:43:56AM +0200, Arent Storm wrote:
>
> > Please don't think me rude, but I think you've missed a very large
> > category of users completely.
> > These are people who record large collections of tunes
> > (admittedly, each tune is likely to be a 'simple folk melody'
> > with or without lyrics),
> > often in the hundreds or  thousands of tunes, related by genre or origin.
> > They will use abc instead of or in addition to tunebooks.  These people
> > collect tunes and transcribe them, exchange them via email,
> > publish them as a resource on the internet or as a collection
> > on CD-ROM and also want to print them as
> > dots or play them when required.  They need software to proofread or
> > proofhear what they've entered, to index, to search, to compare tunes, etc.
> > Sophisticated typesetting is not likely to be a first-order requirement,
> > certainly not at the expense of readability.
>
> But do they 'look' at the abc by means of software or directly.
> I have collected 1++ of them myself over the years
> (small and large collections/files) and find myself looking at
> the abc-source only if the software is behaving unexpectedly,
> so I would place the collectors group in (2).
> The idea of multiple tunes within one file I personally do not like
> much (I'd rather zip them when transferring)

Interesting. It's always struck me as one of the useful points about
ABC, when dealing with several thousand tunes, that you don't have to
have them all in separate files.

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] BarFly 1.4 available

[Arent Storm]

From: "Phil Taylor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 3:19 PM
Subject: [abcusers] BarFly 1.4 available


> I have just uploaded a new version of BarFly.
 
> You can now optionally have the program ignore line ends in
> the abc source, placing staff breaks only where marked by
> an exclamation mark (emulates ABC2Win).
sounds fine

> You can use the ` character as a spacer in the text without
> breaking beams or generating errors.

FWIW: I don't like the feature (hope it doesn't get used)
if it does I gues I'll have to implement it too (sigh) 

Arent

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

Re: [abcusers] expected abc audience

[Jon Freeman]

From: "Jack Campin" <[EMAIL PROTECTED]>
> The third seems a wild overestimate - surely the only program
> that does interchange to any other general-purpose score format
> in a meaningful way is Bryan's Noteworthy convertor?

I think you could at least add Harmony (and possibly Melody) Assistant to
that list. I know for certain that it what Dave McGlade (dgmc) our main
contributer of songs for folkinfo uses. I'm aslo aware that they did fix a
couple of incompatibilities we found between thier abc output and what we we
using at folkinfo to use abcm2ps.

Jon

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

Re: [abcusers] New standard(s)

[Richard Robinson]

On Tue, Jul 22, 2003 at 08:48:11AM +, Tom Novelli wrote:
> 
> Makes for some confusion though, like when I asked for a 1/2 peso of ham
> in a Costa Rican grocery store.. "kilos! kilos!" :)  I guess you'd really
> get some funny looks in a country with a worthless currency called the
> Peso :)

Here in the UK, when I buy a pund of cheese, I sometimes get asked if I
mean weight or moneys-worth. It only seems to happen with cheese, oddly
enough.

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: (Getting OT)[abcusers] New standard(s)

[Bernard Hill]

In message <[EMAIL PROTECTED]>, John Chambers
<[EMAIL PROTECTED]> writes
>
>Not just the tenors.  I have a low bass voice, and choral  music  can
>get painful after too long a rehearsal, because it's all in the upper
>half of my range.  In college, I was in a Russian  choir  for  a  few
>years,  and I was one of the two low basses.  It was really fun to be
>able to use the bottom half of my  range,  and  actually  be  relaxed
>while singing.

Me too. Bottom C is always reliable and Bb sometimes. Lovely to sing
relaxed down there.

However I have been taking singing lessons recently and am pushing
upwards. In ensemble I have a top G and in solo work an F.

(Haydn St Nicholas mass has a low Eb and then 2 bars later a top G for
the undivided basses (!))


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] New standard(s)

[Richard Robinson]

On Tue, Jul 22, 2003 at 09:32:27AM +0100, Bernard Hill wrote:
> In message <[EMAIL PROTECTED]>, Richard Robinson
> <[EMAIL PROTECTED]> writes
> >the UK inch had previously been been equal to 2.54 cm,
> 
> 2.539998

Aha. Negative muttering.

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

[abcusers] BarFly 1.4 available

[Phil Taylor]

I have just uploaded a new version of BarFly.

This is the first full release of the Carbon version for OS X,
and I'm now recommending that users of Classic systems 8.5 - 9.2
should also use this version (you will need CarbonLib 1.3 or
later among your active system extensions).

There are now three versions of BarFly, called Carbon, Classic
and Old.  All three versions have been updated, and all carry
version number 1.40.

Use the Carbon version on MacOS X, and on MacOS 8.5 - 9.2.
Use the Classic version almost anywhere (System 7 on).
Use the Old version on Macs with 68030 or 68040 processors
and on PC emulators which emulate this kind of processor.

New in this version:

You can now optionally have the program ignore line ends in
the abc source, placing staff breaks only where marked by
an exclamation mark (emulates ABC2Win).

You can use the ` character as a spacer in the text without
breaking beams or generating errors.

You can use the barline | and backslash-hyphen in w: fields

Plus lotsa bug fixes.

Get it from:

http://www.barfly.dial.pipex.com/download.html

Phil Taylor


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

Re: (Getting OT)[abcusers] New standard(s)

[John Chambers]

Frank Nordberg writes:
| John Chambers wrote:
|
| > Yeah, and there has been a  slow  inflation  of  "standard"
| > pitch  over  the  several  centuries  that we've had such a
| > concept.
| ...
| > One of the explanations that  I've  heard  is  that  string
| > players tend to be leaders in this race.
|
| They do, and singers suffer the most. As standards of living increase,
| the singers gets more well-fed and their voices drop in pitch. At the
| same time, the notes they are supposed to sing go the other way.
| (Everybody who has tried to sing the tenor in a choir perfoming a Bach
| cantate probably winces from bad memories at this point. ;-)

Not just the tenors.  I have a low bass voice, and choral  music  can
get painful after too long a rehearsal, because it's all in the upper
half of my range.  In college, I was in a Russian  choir  for  a  few
years,  and I was one of the two low basses.  It was really fun to be
able to use the bottom half of my  range,  and  actually  be  relaxed
while singing.

But I've generally stuck to instrumental music.  That way  I  can  be
relaxed in any octave.

OTOH, a fun experience a few years back was being in the choir for  a
community  (actually,  the  local  UU church) performance of Bach's B
minor mass.  A lot of the fun was  watching  the  singers  start  off
overwhelmed  and  confused  by what is a complex, opaque work of art,
and slowly coming to really love it.  It really brought out  the  old
observation that Bach was writing for musicians, not audiences.  This
is some music that takes a lot of real work to master. But everyone I
know  who has been in it considers it one of the high points of their
musical experience.

(And his vocal parts were all on the high side. It should be re-scored
as the G minor mass.)


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

[abcusers] Re: expected abc audience

[Bryancreer]

Jack Campin wrote -

>the only program
>that does interchange to any other general-purpose score format
>in a meaningful way is Bryan's Noteworthy convertor?  He probably
>has figures for how many people use that but I doubt if it's as
>much as 5% of the ABC community.

In my dreams.  Rather less than 1% if Arent's figures are to be believed although circumstantial evidence suggests that there may be quite a few unregistered users.

Bryan Creer

Re: [abcusers] expected abc audience

[Arent Storm]

> >When trying to fit abcusers in a few groups having
> >[1] abc-sightreaders (without much need for software)
> >[2] abc-collectors 
> >[3] abc-software-only-users (1st language)
> >[4] abc-as- interchange-file-format-users (2nd language)
> >
> >Two questions arise
> >- is this a meaningful division?
> >- if so, how large do we expect the groups to be?
> >
> >My answer to the first question is -of course- yes ;-)
> >The second is the hard one my first (wild)guess would be:
> > 1: <200  (1%)
> > 2: <500  (3%)
> > 3: >1000, <1 (30%)
> > 4: >1  (66%) the remainder
> >Any thoughts?
> >
> >Arent
> 
> [5] software developers
> I don't expect to *use* abc format in anger as it's not where I am
> musically, but I expect to understand it and serve others as I write abc
> interfaces to my software.
>
> Bernard Hill

I would say [5] is within [4] and I'm regarding myself also in
that position. I started writing MusiCAD as a DOS program back
in 1989, with more or less the same criteria as abc, though not
as compact as abc, and focus to balkan music instead of
bagpipe & co. 

Arent

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

Re: [abcusers] expected abc audience

[Tom Keays]

Arent Storm wrote:
>When trying to fit abcusers in a few groups having
>[1] abc-sightreaders (without much need for software)
>[2] abc-collectors
>[3] abc-software-only-users (1st language)
>[4] abc-as- interchange-file-format-users (2nd language)

It is also reasonable to assume that many (most?) of the abc users actually
fall in several of these camps.  I myself fit into all of them and I would
be hard pressed to characterize myself as doing one over any other.  I use
the plaintext abc as an aid memoire (using my Palm) to jumpstart me on
tunes.  I maintain a small collection of morris dance tunes.  I use BarFly
and PalmAbc for transcribing, displaying and playing tunes (especially the
former for when I want to check the accuracy of my transcriptions).  I
frequently send or receive tunes to and from individuals and listservs.

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

Re: [abcusers] About the choice of '!'

[Arent Storm]

From: "Jack Campin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 12:46 PM
Subject: Re: [abcusers] About the choice of '!'
> > Having read the discussion about bang & co for quite a while
> > I'd like to add my two (euro)cents.
> > I have more or less implemented a full abc import/export of
> > ABC in MusiCAD based on 1.6 and beyond, trying to accommodate
> > as much extensions as possible (words/multivoice/etc).
> >
> > When implementing linebreaks the CR/LF, I took the approach of
> > ignoring CR/LF at all. MusiCAD determines clustering, barlines,
> > linebreaks pagebreaks and so on, so the information abc provides
> > in this respect was simply ignored without much consequenses.
> 
> Which means anybody using ABC for Highland pipe music will dump the
> demo of your program in the trash/wastebasket/recycle-bin after they
> try the first tune.  All phrases go on one line.  No exceptions,
> soldier.
I think/hope that that'll be too pessimistic.
Just by setting (otpional) 4 bar/line I, think that most of the
tunes will be just fine.  
 
> Ditto a lot of people typesetting songs and hymns - look at "Hymns
> Ancient and Modern", for example.  You hardly ever find a text line
> running over two staff lines.
And that's where ! would fit in perfectly.
No need to clutter up with \ just to get a CR/LF linebreak.

> BarFly makes ignoring linebreaks an option (except for multi-voice
> music where it isn't practical); what I do sometimes is first let
> the program have a go at doing the layout, then optimize the result
> by putting explicit linebreaks in better places myself.  BarFly's
> spacing algorithm is not very sophisticated (monospace type printed
> on elastic), but the same approach would be handy for any program.
As I see music engraving, you should care about linebreak/pagebreak
just before you start printing. You never know the paper size 
beforehand do you?
So I implemented heaps of layout features just to enable me
to get as much notes on paper as I want. And yes, there will
be conflicting issues like readability and need to get as much
on a single sheet as possible.
 
Arent

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

Re: [abcusers] New standard(s)

[Tom Novelli]

On Mon, 21 Jul 2003, Bruce Olson wrote:

> I don't think that is quite right. My recollection is that
> 39.37 inches was one meter until some time in the 1970s.
>
> I was one of many scientists at the US National Bureau of
> Standards who was appalled, to say the least, when the US
> government decided to abandon their highly publicized campaign to
> convert to metric. Much had already been done, at no small
> expense, and had to be abandoned for an expensive reconversion
> back to 'English' units [e.g., all the new gasoline/petrol pumps that
> delivered in liters had to be abandoned, and old (US) gallon pumps
> reinstalled].
>
> Bruce Olson

This was in the 70s? Never heard of it.

I learned both systems in school... it's not a problem.  Metric is
actually pretty convenient for mechanical things, but the English base-12
and base-16 systems have their advantages... they're also a little
redundant, which helps when you're trying to read 150-year old maps or
10th-generation faxes.

Makes for some confusion though, like when I asked for a 1/2 peso of ham
in a Costa Rican grocery store.. "kilos! kilos!" :)  I guess you'd really
get some funny looks in a country with a worthless currency called the
Peso :)
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] expected abc audience

[Jon Freeman]

From: "Arent Storm" <[EMAIL PROTECTED]>

> When trying to fit abcusers in a few groups having
> [1] abc-sightreaders (without much need for software)
> [2] abc-collectors
> [3] abc-software-only-users (1st language)
> [4] abc-as- interchange-file-format-users (2nd language)
>
> Two questions arise
> - is this a meaningful division?
> - if so, how large do we expect the groups to be?

I guess I would fit into [4]. I do use abc as the storage format for our
small (but hopefully one day will grow) collection of folk songs but that is
at least partly as I believe abc is a very useful format for that. I do of
course recognise that abc in itself is useful and there are people in your
[1] and [3] categories but lso recognise that there are also people who
visit our site who will want to just click for a MIDI and for graphics.

When I was to produce an abc, I am a [4] type user. This is mostly
because I can't make musical sense of any notation format. The only way I
manage to enter a tune from a book is to copy the actual dots onto a score -
trying to convert note names and note lenghts into abc would be very error
prone and time consuming for me. I can then use abc if I wish to play back
and make adjustments to the abc. If I'm trying to write a tune out of my
head, I almost always use Cakewalk as I hear the notes as I move them on the
score and only have to play about a little to get the timing right.

It's annoying blindness I have and I have known the basic theory of music
from primary school... I think what I'm trying to say is I suspect that
there are plenty of others around who becuase of difficulties like mine (and
also difficulties in using software that is not point and click) who would
use abc more for interchange if there was more software around to cater for
this. In that sense, perhaps one could speculate over future usage in this
way rather than current usage???

Jon

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

Re: [abcusers] expected abc audience

[Phil Taylor]

Arent Storm wrote:

>When trying to fit abcusers in a few groups having
>[1] abc-sightreaders (without much need for software)
>[2] abc-collectors
>[3] abc-software-only-users (1st language)
>[4] abc-as- interchange-file-format-users (2nd language)
>
>Two questions arise
>- is this a meaningful division?
>- if so, how large do we expect the groups to be?
>
>My answer to the first question is -of course- yes ;-)
>The second is the hard one my first (wild)guess would be:
> 1: <200  (1%)
> 2: <500  (3%)
> 3: >1000, <1 (30%)
> 4: >1  (66%) the remainder
>Any thoughts?

It's a reasonable guess.  However, we should bear in mind that
the numbers don't indicate the importance of the groups.  Most
of the valuable, creative work is done by members of the first
two categories, so it would be a mistake to assume that we
don't have to cater for them.

Also there is likely to be considerable overlap between the
categories.  I know of only one sightreader who never uses
software, but many people use abc software to process
hand-written abc.  Likewise many people use conventional
music notation software [4] and also publish abc collections[2].

Perhaps the real distinction should be between those who look
at (and sometimes edit) the abc source and those who simply
use a program to convert it to standard notation or play it.

Phil Taylor


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

Re: [abcusers] expected abc audience

[Bernard Hill]

In message <[EMAIL PROTECTED]>, Arent Storm
<[EMAIL PROTECTED]> writes
>When trying to fit abcusers in a few groups having
>[1] abc-sightreaders (without much need for software)
>[2] abc-collectors 
>[3] abc-software-only-users (1st language)
>[4] abc-as- interchange-file-format-users (2nd language)
>
>Two questions arise
>- is this a meaningful division?
>- if so, how large do we expect the groups to be?
>
>My answer to the first question is -of course- yes ;-)
>The second is the hard one my first (wild)guess would be:
> 1: <200  (1%)
> 2: <500  (3%)
> 3: >1000, <1 (30%)
> 4: >1  (66%) the remainder
>Any thoughts?
>
>Arent

[5] software developers


I don't expect to *use* abc format in anger as it's not where I am
musically, but I expect to understand it and serve others as I write abc
interfaces to my software.


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] About the choice of '!'

[Jack Campin]

> Having read the discussion about bang & co for quite a while
> I'd like to add my two (euro)cents.
> I have more or less implemented a full abc import/export of
> ABC in MusiCAD based on 1.6 and beyond, trying to accommodate
> as much extensions as possible (words/multivoice/etc).
>
> When implementing linebreaks the CR/LF, I took the approach of
> ignoring CR/LF at all. MusiCAD determines clustering, barlines,
> linebreaks pagebreaks and so on, so the information abc provides
> in this respect was simply ignored without much consequenses.

Which means anybody using ABC for Highland pipe music will dump the
demo of your program in the trash/wastebasket/recycle-bin after they
try the first tune.  All phrases go on one line.  No exceptions,
soldier.

Ditto a lot of people typesetting songs and hymns - look at "Hymns
Ancient and Modern", for example.  You hardly ever find a text line
running over two staff lines.

BarFly makes ignoring linebreaks an option (except for multi-voice
music where it isn't practical); what I do sometimes is first let
the program have a go at doing the layout, then optimize the result
by putting explicit linebreaks in better places myself.  BarFly's
spacing algorithm is not very sophisticated (monospace type printed
on elastic), but the same approach would be handy for any program.

-
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] expected abc audience

[Jack Campin]

> When trying to fit abcusers in a few groups having
>  [1] abc-sightreaders (without much need for software)
>  [2] abc-collectors 
>  [3] abc-software-only-users (1st language)
>  [4] abc-as- interchange-file-format-users (2nd language)
>
> Two questions arise
> - is this a meaningful division?
> - if so, how large do we expect the groups to be?
>
> My answer to the first question is -of course- yes ;-)
> The second is the hard one my first (wild)guess would be:
>  1: <200  (1%)
>  2: <500  (3%)
>  3: >1000, <1 (30%)
>  4: >1  (66%) the remainder
> Any thoughts?

I don't know what the second category means.

The third seems a wild overestimate - surely the only program
that does interchange to any other general-purpose score format
in a meaningful way is Bryan's Noteworthy convertor?  He probably
has figures for how many people use that but I doubt if it's as
much as 5% of the ABC community.  Or do you mean people who convert
to ABC from other formats? - I don't think that really happens any
more, everything from the NMD or BGP formats that is ever likely
to be converted already has been, and there never were more than
three or four people doing either.


-
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

[abcusers] Abcpp

[Forgeot Eric]

it seems I forgot to send this post... I apologize to post it
again if I already did so

>Any programmers here that feel the call to create a nice little 
>conversion program/script for the benefit of the world at large?
/.../
>Note that with such a program, there is no need to cleanup old
ABC 
>files --
>any time you want to use an old ABC file with your new program,
you 
>simply
>run it through the converter. 

Abcpp can do that. (http://abcplus.sourceforge.net/#abcpp)

I'm using Abcpp now for some tunes now, it's great. Not related to
what was said about the abc2.0, I just wanted to know if escape
sequences were supported, for ex. the possibility to write new
line feed, for ex. some application use \n for new line (we won't
talk about '!'...), or \t for tabulation etc. It could be usefull
in some case, unless ppl prefer to edit the source with a text
processor.


___
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] ABC sects

[Forgeot Eric]

>I don't like %%midi transpose, because
>transposition is nothing to do with midi,

I forget to talk about that, an advantage of BarFly is, if I
understood well, it can transpose either the notation, or the
sound, or both. The %%midi transpose is limited because it make
transpose both (of course it was designed 1st to fit abc2midi's
needs). For guitar notation for ex., the notation is written one
8ve higher than the real pitch. I think with abcm2ps for my guitar
partitions I wrote K:C treble for keeping that correct (I can't
really remember how I made it display correcly). 
Maybe it could be possible to have in addition a %%transpose with
several way of transposition : midi only, midi + display, display
only.


___
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

[abcusers] Abacus

[Forgeot Eric]

There are good improvements in this new version, and it seems also
it crash less, unlike the previous version. The midi rendering is
good also. I think you already know for lyrics and multivoice :)
(it lacks cruelly) but will there be a midi export as well ?

A few suggestions :

You made a "full abc view" (without display), it could have been
maybe better to have a "full abc view + display". I guess some
pple prefer to have full abc as default edition (AbcMus can do
this well, switching from a mode to an other)

Your package is still quite heavy to download. I noticed my
MSwindows had already several or your big files used in the system
folder (for VB basic I guess), so maybe you could propose a the
normal package, and a light one for people who know they have
already those special files ?

You could include a file with some abc samples



___
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] About the choice of '!'

[Arent Storm]

> Please don't think me rude, but I think you've missed a very large
> category of users completely.
> These are people who record large collections of tunes
> (admittedly, each tune is likely to be a 'simple folk melody'
> with or without lyrics),
> often in the hundreds or  thousands of tunes, related by genre or origin.
> They will use abc instead of or in addition to tunebooks.  These people
> collect tunes and transcribe them, exchange them via email,
> publish them as a resource on the internet or as a collection
> on CD-ROM and also want to print them as
> dots or play them when required.  They need software to proofread or
> proofhear what they've entered, to index, to search, to compare tunes, etc.
> Sophisticated typesetting is not likely to be a first-order requirement,
> certainly not at the expense of readability.
But do they 'look' at the abc by means of software or directly.
I have collected 1++ of them myself over the years
(small and large collections/files) and find myself looking at
the abc-source only if the software is behaving unexpectedly,
so I would place the collectors group in (2).
The idea of multiple tunes within one file I personally do not like
much (I'd rather zip them when transferring)

> Arent Storm wrote:
>
>>Having read the discussion about bang & co for quite a while
>>I' d like to add my two (euro)cents.
>>I have more or less implemented a full abc import/export of
>>ABC in MusiCAD based on 1.6 and beyond, trying to accommodate
>>as much extensions as possible (words/multivoice/etc).
>>
>>When implementing linebreaks the CR/LF, I took the approach of
>>ignoring CR/LF at all. MusiCAD determines clustering, barlines, linebreaks
>>pagebreaks and so on, so the information abc provides in this respect
>>was simply ignored without much consequenses.
>>I guess the same will hold for other notation software using abc as second
>>language.
>
> agreed
>
>>As far I can see there are two main visions within the abc-community
>>
>>1)
>>People using ABC for sight reading, in fact not in need of any software
>>whatsoever.
>>
> replace 'sight reading' by 'exchange, archival and reference format' and
> rethink your statement
If so, it would be quite easy to do the suggested format change(s)
within the collectors collections, and use that as a starting point.

>>When you are using abc this way (where it has its roots) the need for ! as
>>forced line-break is obviously very low. I guess that a lot of other header
>>info will not be used either. Music thus written has to be as concise and
>>clear formatted as possible; linebreak equals CR/LF is a perfect solution
>>for that job.
>>
> other header info is remarkably important
>
>>All bells&whistles like multiple staves, fancy !trill! symbols
>>in-line words and so on will also disturb the ease of human reading
>>that was the power of abc.
>>A line continuation is more or less nessecary because the
>>paper (screen) that they're writing on is also limited.
>>For group1 the upcoming standard will be more or less ignorable...
>>as long as ABC2.0 compliant software will read/play/display
>>their abc's albeit with linebreaks at different places
>>
>>2)
>>People who use abc mainly as a language to engrave music
>>(the majority?) might look at it differently.
>
> Not the majority if you weight the users by the amount of published
> material,  I suspect.

Won't that be a little bit tricky viewpoint...?
One user with 1 pubished tunes would outweigh 9000 users
publishing 1 tune, so the needs of 1 would outweigh the need of the
other 9000 users (or am I missing something)

Arent

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

[abcusers] expected abc audience

[Arent Storm]

When trying to fit abcusers in a few groups having
[1] abc-sightreaders (without much need for software)
[2] abc-collectors 
[3] abc-software-only-users (1st language)
[4] abc-as- interchange-file-format-users (2nd language)

Two questions arise
- is this a meaningful division?
- if so, how large do we expect the groups to be?

My answer to the first question is -of course- yes ;-)
The second is the hard one my first (wild)guess would be:
 1: <200  (1%)
 2: <500  (3%)
 3: >1000, <1 (30%)
 4: >1  (66%) the remainder
Any thoughts?

Arent








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

Re: [abcusers] New standard(s)

[Bernard Hill]

In message <[EMAIL PROTECTED]>, John Chambers
<[EMAIL PROTECTED]> writes
> But if you measure it in,  say,  attoparsecs,
>this  is  the  definition of a parsec (and of the atto- prefix)." 

Love it! 1 attoparsec is approx 3.1cm or 1.2" ... as everyone knows 



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] New standard(s)

[Bernard Hill]

In message <[EMAIL PROTECTED]>, Phil Taylor
<[EMAIL PROTECTED]> writes
>John Chambers wrote:
>>Phil Taylor writes:
>>| John Chambers wrote:
>>| >An interesting example:  Sears is still one of the biggest seller  of
>>| >tools  in  the US, and they still sells tools labelled "Standard" and
>>| >"Metric".  You folks in the rest  of  the  world  may  find  yourself
>>| >bewildered by this, but yes, they actually get away with it.
>>|
>>| Well, they can't exactly call the system of measurement based on the
>>| inch, pound and gallon "Imperial" can they?  Or maybe they can...
>>
>>Well, they could, and you do still see this in the US.  But "English"
>>is  the  more  common  term  used  by people who understand that such
>>measures are no longer the standard anywhere.
>
>Not even in England - well you can still buy milk and beer in pints,
>and the road signs are still in miles,  but I think those are the only
>exceptions.  Kids are only taught S.I. units in school now.  When I
>was in primary school there were zillions of obscure units of
>measurement to be remembered - 22 yards = 1 chain, 10 chains = 1 furlong
>and 5 feet = 1 rod, pole or perch.  I never figured out what rods/poles
>/perches were used to measure, but I still remember what they are.
>It was pre-decimal currency too, so 12 pence to the shilling and
>20 shillings to the pound.  1/3 of a pound was 6/8d (no, it's not
>a fraction, it's an exact number of pennies).  Now it's an irrational
>number. 

No, it's one third, 1/3, which is a "rational" number, being a ratio.
Irrational numbers are those which can't be written as an exact ratio.

> At least by the time you got taught about base systems you'd
>already been doing mental arithmetic in multiple bases for years, so
>it was no big deal.  I wonder if that makes me better at hex arithmetic
>than my kids are?

And we were also taught decimetres, dekametres, hectametres, centigrams,
decigrams etc etc alongside centimetres.




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] New standard(s)

[Bernard Hill]

In message <[EMAIL PROTECTED]>, Richard Robinson
<[EMAIL PROTECTED]> writes
>the UK inch had previously been been equal to 2.54 cm,

2.539998


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] Re: New standard(s)

[Bryancreer]

John Chambers wrote:

>we can align our music with the very basic phenomena of the cosmos. 

Talking of which, didn't you guys have a little trouble aligning one of your probes with Mars because of a mix up between metric and Imperial?

Bryan Creer