Re: [abcusers] developers/users

[Phil Taylor]

Bryan Creer wrote:
>Phil Taylor says -
>
>>The system of using ^ and _ to
>>denote annotations over or under the staff was proposed by Wil Macaulay
>>about two years ago and incorporated in the next version of BarFly
>>(which also allows < and > to place the annotation to the left or right
>>of the note head when you want to annotate a particular note in a chord).
>>Most programs have followed suit.
>
>This is still a bodge of the guitar chord system and too little too late.  It
>isn't safe to assume that any text within double quotes that doesn't start
>with one of those symbols is a chord.

The problem here lies not with the proposed mechanism, but with the fact
that the original (v1.5 abc) guitar chord format permitted abuse, and we
can't go back in time and change it retrospectively.

>>The only responsibility I acknowledge
>>towards the users is to make sure that it won't do them any harm
>>(carry viruses, corrupt their operating system etc).
>
>Well giving them software that produces "abc" that is inconsistent with any
>other abc isn't exactly doing them favours is it?

If it allows them to make transcriptions that can't be done any other
way then it's useful.  If you want to make use of my transcription of the
Goldberg Variations then you will need a program that supports transposing
macros and user defined symbols.  These things are in the proposed 1.76
standard, except that they have been confused and conflated to the
point where nobody really understands what has been proposed, so nobody
else has implemented them in a program.  If you want to know how these
things should work, read:

http://rbu01.ed-rbu.mrc.ac.uk/barflystuff/bfextensions.html

(That page is not yet up to date with the current version, but you'll
get the idea.)

Phil Taylor


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

Re: [abcusers] developers/users

[Wil Macaulay]

Bryan, I think you've hit on the nub of the (pick one) disagreement/
argument/difference in world view  between yourself and many of
the people on this list
[EMAIL PROTECTED] wrote:

> Phil Taylor says -
>
> >The system of using ^ and _ to
> >denote annotations over or under the staff was proposed by Wil Macaulay
> >about two years ago and incorporated in the next version of BarFly
> >(which also allows < and > to place the annotation to the left or right
> >of the note head when you want to annotate a particular note in a chord).
> >Most programs have followed suit.
>
> This is still a bodge of the guitar chord system and too little too late.  It
> isn't safe to assume that any text within double quotes that doesn't start
> with one of those symbols is a chord.

Correct.  But any text within double quotes that _does_ start with one
of those symbols can be safely used as an annotation, so IT IS NOW POSSIBLE
to write an abc file that can be safely played by abc2midi (or BarFly, or Muse) and
properly
displayed by abc2ps (or BarFly or Muse).  Sure, it is also possible to write one that
plays weirdly...

>
>
> >The only responsibility I acknowledge
> >towards the users is to make sure that it won't do them any harm
> >(carry viruses, corrupt their operating system etc).
>
> Well giving them software that produces "abc" that is inconsistent with any
> other abc isn't exactly doing them favours is it?
>

Here's where I really believe that you just "don't get it" - software DOESN'T
produce abc, people do.  People will twist it to serve their own needs, if
they don't have a good way to do it in the standard, and if those needs
are seen as useful to multiple people they will get addressed, eventually.
But you can still type random strings into a file and _something_ will
happen, just like you can still divide by zero in a c++ module.

Sorry for shouting...

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

--
Wil Macaulay email:   [EMAIL PROTECTED]
voice:  +1-(905)-886-7818  xt2253FAX: +1-(905)-886-7824
Syndesis Ltd. 28 Fulton Way Richmond Hill, Ont Canada L4B 1J5
"... pay no attention to the man behind the curtain ..."


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

Re: [abcusers] validation & the ABC corpus

[Bryancreer]

John Chambers says - 

>Except that these are value judgements, and one person't "better" is often
>another person's "worse".

Well, my "better" is more consistent, more reliable and more usable if that 
is someone else's "worse" that's their problem.

>I think it is valued, especially in the sense that ABC has a  lot  of
>users because it works as a means of exchanging music.  Extending ABC
>to new types of music has been slow mostly because of  worries  about
>conformance with the standard and interoperability with other tools.

But it seems to be acknowledged that there is a lot of non-standard rubbish 
out there and I don't just mean the big things like missing X: or T: commands 
but things like ties used as slurs and the weird things people do with 
barlines and repeat endings.  I recently came across :|]| at the end of a 
tune. And as for "I think it is valued", there seems to be a certain amount 
of "I'll do what I like and no one can stop me" attitude around.

You must have seen the recent exchange on the tradtunes list -

On Wed, Jan 24, 2001 at 10:33:07AM +, Anahata wrote:
> Been there, done that.  There seems to be a different set of conventions
> for abc2ps and abc2win, which are probably the most commonly used
> packages.  Has anyone worked out a way of keeping tunes compatible with
> both?

to which Dave Holland replied -

>I do it by keeping to the bare minimum syntax laid down in the ABC spec 1.6.

In other words the general user isn't going to use all these wizzy but 
inconsistent innovations if they know that a lot of their potential audience 
isn't going to be able to use them.  Uncoordinated innovation is actually 
restricting the usability of abc to the bare minimum.

>What Jose needs is software that accepts T: lines
>but omits them from the (PS or GIF) output.

I was coming round to that point of view.  His problem is nothing to do with 
abc standards but is a software problem.  It's a pity his stuff isn't 
accessible.

Bryan

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

Re: [abcusers] developers/users

[Phil Taylor]

Richard Robinson wrote:
>On Wed, 24 Jan 2001, Jack Campin wrote:
>
>> > The only other course open to someone determined not to pay
>> > for software but still wanting special funstions is to do
>> > what the rest of us do -  get out gcc / emacs / TeX and get started!
>>
>> I'd like to, but (a) the abc2mtex port for the Mac doesn't work and is
>> unsupported and (b) nobody's done an MPW port of any PS or TeX converter
>> that I could use as a starting point (MPW is the only free C compiler
>> for the Mac).  I know zilch about GUI programming, have no interest in
>> learning it, and am not about to waste a year of my life reinventing
>> wheels.  If I can get one of my old Suns working, I'll be in a better
>> position to do some ABC implementation, as I'll be able to disregard
>> the GUI stuff.
>
>What's with this story about the New Mac OS being some kind of Unixy
>variant ? Will that give Mac people access to all the GNU stuff ?
>

Yes, it's BSD Unix underneath.  You can run gcc and compile all the same
stuff on it.  There are also at least two variants of linux which will
run on Macs. but the advantage of OSX is that you can run classic Mac
programs at the same time.

None of this helps Jack though, as none of it will work on
his antique 68K Macs.  MPW will run OK though, and if he can find a copy,
the old Apple Unix A/UX will also work.

Phil Taylor


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

Re: [abcusers] V: again

[John Walsh]

Phil Taylor wrote:

>John Walsh wrote:
>>[...]
>>M:3/8 L:1/8
>>F3|FFF|F3|FFF|F3|FFF|F3|FFF|F3|FFF|F3|FFF:|
>
>Surely the third voice is half as long again as the other two?
>If it were written like this it would be OK:
> [...]
>V:3
>M:3/8
>L:1/8
>F3|FFF|F3|FFF|F3|FFF|F3|FFF:|

No--there was a mistake in the part, but it wasn't that. (I just
forgot a double bar line.) The original piece had twelve bars of 3/8 time
in parallel with 6 of 2/4 and four of 3/4, with no tempo markings.  (This
is copied directly from the MusixTeX docs, by the way.)  Presumably the
musicians playing it would figure out the relative tempos by seeing which
notes lined up in the three staves. This was why I was thinking that some
sort of a tab stop before the double bar-lines (there should have been a
double bar ending the sixth measure in the third voice) would tell the
program to align the double bars, and give it a fighting chance to get the
proper notes aligned elsewhere. I have no idea what to tell a player
program to get it to play back as intended, tho.

(Sorry, James, I misunderstood your proposal: I was thinking about
tab stops at the time and thought you wanted to force voices to align at a
certain point, rather than to recognize the fact that they were aligned.)

I think it's a pretty safe prediction that whatever the V:  
standard turns out to be, it'll be abused much as (and for the same good
reasons) the guitar chord mechanism is now:  i.e. to write something that
abc wasn't explicitly designed to do, but *can be made to do*. (That's
called "hacking," isn't it?  Maybe it'd be a good idea to design in little
hackability in the first place instead of worrying about how much abc
hacking's been done.)

I've been going thru the MusixTeX docs, looking for examples of
multi-staff music in order to see what has to be done to give abc2mtex
multi-staff capability, and I ran into couple of examples which had
isolated chords with notes of different lengths:  e.g. three quarter notes
and one dotted quarter note.  If abc requires all notes in a chord to have
the same duration (the 1.7.6 standard doesn't say that explicitly, but it
seems to be assumed) then you could hack the extra note with an additional
voice. If that's the only place in the piece that happens, you have to put
in a lot of invisible rests!  (Or could you use V:sync right after that
note?)  Even tho the extra note comes from an internal voice in the music,
this still strikes me as a slight abuse of the voice mechanism.  And an
inelegant one, at that.  Or...is this perhaps one of the things J-F
Moine's floating voice was designed for?

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

Re: [abcusers] Developers responsibilities

[Bryancreer]

Steve Mansfield said -

>My apologies, I omitted a .htm after extensions. You seem to have
>managed to locate the page eventually despite my error though.

Thanks Steve.  Found it now.  A lot of good stuff there.

>And how precisely is that 'not a widely held view'? 

I share that view but a lot of others don't.  I agree that "Features decribed 
there should NOT be used in any abc file".  Unfortunately they ARE being used 
in a piecemeal and inconsistent fashion.

I agree with just about everything you said from there on except that I'm not 
convinced that 1.7.6 is ready for acceptance yet.  I could do with an 
explanation of how player programmes would interpret user defined symbols 
(What do you do with u:M = !Upper Moldavian praltriller! or u:G = !Go back to 
where you came from! ?) and I'm still not convinced that the 
annotation/guitar chord problem is sorted.  Remember that once you put a 
standard up it's very difficult to get it down again.

Bryan


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

Re: [abcusers] V:

[Laurie Griffiths]

Here's my views:

1)  Should it be a number and nothing else eg. V:1  V:2 ...
Not necessarily

2) Should it be nameable instead eg. V:soprano,  V:alto ...
Yes - this subsumes numbers

3)  Should it have parameters eg. V:1 nam=vocal clef=bass or should these 
appear in local commands applicable to one voice only.
V:1 nam=vocal 
would do just as well as 
V: vocal
but I'd rather one or the other be legal, not both.
clef=bass should not be legal - we already have that in K:

4)  Should music be allowed on the same line 
eg. V:1 f4 gf/2g/2|a2 f2 d2|b3 c'd'b|a2 f2 d2|

Not with this syntax.  You do
[V:1] f4 gf/2g/2|a2 f2 d2|b3 c'd'b|a2 f2 d2|

As we already have a syntax for in-line commands, let's use it.
Otherewise we are just making the language more complex for
the sake of saving two characters occasionally.  A bad idea.

Laurie

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

Re: [abcusers] developers/users

[Bryancreer]

Phil Taylor says -

>The system of using ^ and _ to
>denote annotations over or under the staff was proposed by Wil Macaulay
>about two years ago and incorporated in the next version of BarFly
>(which also allows < and > to place the annotation to the left or right
>of the note head when you want to annotate a particular note in a chord).
>Most programs have followed suit.

This is still a bodge of the guitar chord system and too little too late.  It 
isn't safe to assume that any text within double quotes that doesn't start 
with one of those symbols is a chord.

>The only responsibility I acknowledge
>towards the users is to make sure that it won't do them any harm
>(carry viruses, corrupt their operating system etc).

Well giving them software that produces "abc" that is inconsistent with any 
other abc isn't exactly doing them favours is it?

Bryan

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

Re: [abcusers] Developers responsibilities

[John Henckel]

At 07:46 AM 1/21/2001 -0500, Bryan wrote:
>Discuss the draft standard?  Haven't seen a mention of it.  Instead,
>different bits of it have been implemented in different ways in a piecemeal
>fashion.  The classic example is the V: command which is described in the
>1.7.6 draft standard of May last year as "currently being discussed on the
>abcusers list".  This seems to have been developed in two incompatible ways.
>Attempts to discuss it seem to peter out or get sidetracked.

Bryan, these are my sentiments exactly.  It is very frustrating to see a 
good thing like ABC get drawn and quartered because no one seems interested 
in updating the standard.

In my opinion, the fault lies mostly with Chris Walshaw.  Where is that guy 
anyway??  I haven't seen any comment from Chris since last August.  I would 
gladly update the ABC draft myself.  However, I do not have write access to 
http://www.gre.ac.uk/~c.walshaw/abc/abc-draft.txt.

How about it Chris?  Are you the "chairman" of this standard or not?  If 
so, please do something, or else appoint someone who will.  In particular, 
you should either put the V: into the draft as proposed by Jean-Francois 
Moine or else tell us why you don't like it.  Also, I would like to know 
when you plan to close the draft.  IMO most people here are more interested 
in music than they are in defining a standard, so lets get it behind us.


John Henckel  alt. mailto:[EMAIL PROTECTED]
Zumbro Falls, Minnesota, USA   (507) 753-2216

http://geocities.com/jdhenckel/

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

Re: [abcusers] ABC for notation printing

[John Henckel]

At 07:46 AM 1/21/2001 -0500, you wrote:
>The truth is that there are quite a few people who seem to regard abc as an
>input format for sophisticated notation printing.  abc2ps is a minefield that
>I am not going to enter.  Adaptations to suit this need seem to me to put the
>essential simplicity of abc at risk.

Yep you can definitely put me into this category.  I think that the best 
thing about ABC is notation printing.  The more sophisticated, the 
better.  However, I think that it is not difficult to also keep the 
simplicity of ABC.

When I typeset a tune, I want to be able to control the stem direction, the 
note head shape, the staff width, the lyrics font, etc.  None of this is 
"musical" information, it is "style" information.  All the style data 
should be kept in a separate file, such as the FMT file that the abcm2ps 
program uses.

If anyone wants to put style information into an ABC file, tell 'em, "nope, 
that's style information, put it into the FMT".  Well ok, maybe it's ok to 
put style in the ABC file if you put %% in front of it.



John Henckel  alt. mailto:[EMAIL PROTECTED]
Zumbro Falls, Minnesota, USA   (507) 753-2216

http://geocities.com/jdhenckel/

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

Re: [abcusers] validation & the ABC corpus

[Laura Conrad]

> "John" == John Chambers <[EMAIL PROTECTED]> writes:

John> So what it would take to get his tunes' titles into my index files is
John> probably  a  version of abc2ps that has an "ignore T:  lines" option.
John> Then he could put the T:  lines into his abc files and still get  the
John> same  GIF  files without titles for embedding in HTML or Word docs or
John> whatever.

I would have used that option if abc2ps had offered it when I was
putting together the Morley "Canzonets for two voyces".  What I did
instead was write scripts that deletedt he T: lines before making the
.eps that was included in my TeX file (which had the titles in the
table of contents).


-- 
Laura (mailto:[EMAIL PROTECTED])
http://www.laymusic.org : Putting live music back in the living room.



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

Re: [abcusers] developers/users

[Gianni Cunich]

Hi, RJP

You have been able to sum up a confuse and misleading debate in a few words,
and make some sensible considerations, but you are wrong on one pont.

> > Developers are *not* the only people who get a say in what ABC ought
> > to be, or what it should be used for.

  You wrote:

> O yes they are!  all the Linux  software for abc is FREE,
> so I think nobody has the right to ask the `developers' to do ANYTHING.
> - without paying them that is!
>
> If someone makes a deal with me to do a programming job, then I do it
> the way they want it for pay - but not otherwise.
>
> If I program for myself - then I do EXACTLY what I want - and i would
> be surprised of most developers do not do just the same.

What in fact we are arguing about is the right of the developers on this
list - which, please remeber it, are in fact a minority of the developers of
the ac related softewares available to the community of the users - to be
the only ones entitled to decide about the future develpments of the
notation. The use of the guitar chords syntax to put text on the score is a
topic example of how a need expressed by the users has been incorporated in
the draft in a way which fits some of the available packages, but won't work
with a number of sharewares that 'speak abc'.

I agree with you that:

> There are quite a lot of composition packages around already - some
> of them shareware.   Would it not be better to keep abc simple
> and concentrate on providing means of importing / exporting abc
> to some of these packages? - by providing parsing routines for
> selected shareware authors for ex.

In fact there is a number of excellent and often unexpensive notation
programs which already import/export the notation. Unfortunately, to work
with them we need an upadated standard to stuck to - not sure you have
noticed it, but the current standard is still one line of music, in the Key
of G, with four octaves of extension! If I had to complain with the
developers of the abc speaking package I have registered about the poor
support they are offering for the abc notation, the obvious replay would be
that to make it work correctly they will wait until the current one will be
updated.

This is why, in fact, I suggested we could discuss the opportunity to take
the draft as it is now - i.e. without any agreement about the V: lines - as
the new standard, and eventually update it again when the riotous developers
on this list will have found some agreement about that. Any further delay is
working against the widespread and the promotion of the abc notation, and
this is in fact the developers' (on this list) responsability.

> That way,  abc  can still be used to `sketch' the music & express
> the salient points, whilst adding the `bells and whistles' using
> something else that CAN ALREADY do it...
>
> This could of course, result in loss of detail when abc is re-exported,
> which one would have to accept, since any conceivable abc notation
> will still  probably be insufficient for a lot of the advanced music
> typograpy..
>
> The `simplistic'  users can continue to use abc for free, and those
> who actually want all the extra programming effort can pay -
> seems fair to me!

This is what I had in mind when I suggested that we should keep separate the
notation and what concers its future developments from the packages we use
to manipulate it  (to print scores, generate Midis, an so on...). Not a
popular idea (to contrary belief?).

> The only other course open to someone determined not to pay
> for software but still wanting special funstions is to do
> what the rest of us do -  get out gcc / emacs / TeX and
> get started!

Maybe an abc2mtx converter would help! How much would you charge for a
working one? Windows version...of course!

BYE!

Gianni


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

Re: [abcusers] Developers responsibilities

[Steve Mansfield]

[EMAIL PROTECTED] wrote :
>From Steve Mansfield - 
>
>>Try http://www.lesession.demon.co.uk/abc/abc_extensions#annot as a
>>starting place - and if I've documented them in there, they must be in one
>>of the abc standards documents on Chris W's site (I would suspect, but
>>haven't checked, in the 1.7.6 proposal, as that's where most of
>>abc_extensions.htm is based on).
>
>Thanks Steve but I haven't been able to find that link on your site.  

My apologies, I omitted a .htm after extensions. You seem to have
managed to locate the page eventually despite my error though.

>While 
>looking for it  I did find -
>
>>If you are reading this tutorial wishing only to understand how abc is 
>written now, >you can safely ignore these links to proposed extensions. 
>Features described in >these linked sections are NOT an agreed part of the 
>abc notation standard, but are >proposed extensions to that standard that may 
>in the future be adopted as a part of >the standard. Features decribed there 
>should NOT be used in any abc file which is >intended for distribution, as 
>the feature may not be understood by other users or 
>>supported by their particular choice of abc software. 
>
>Not a widely held view, I'm afraid.
>

And how precisely is that 'not a widely held view'? 

The extensions covered in 1.7.6 have not yet been agreed as a part of the
specification, but as proposed extensions which may in turn be
assimilated into the specification by general agreement in this forum. 

You may not *like* that fact, but that is the position and the status of the
1.7.6 specification, and in the mean time the advice I offer in the section
you quote can be rephrased and summarised as 

A) the extensions described in that page are not part of the agreed
'production' specification. They may be in the future but are not yet.

B) Following on from that, any piece of software or human being using a
file containing those extensions might not understand them or parse them
correctly.

Or am I way off beam here, and did I miss the announcement that 1.7.6
was now the official abc standard? 

Gianni suggested we adopted that (1.7.6) as it stands and then worked
from there, which is a strong suggestion - and in that case the extensions
described in abc_extensions would be amalgamated into the main body of
my tutorial, no doubt soon to be replaced by other proposed extensions
(like a coherent and agreed V: syntax for example).

In the mean time they remain proposals, proposed extensions, and (unless
corrected general opinion here, which would contradict the peer review
process I invited for the tutorial before general publication) that is the
status they will continue to have indicated until the abc corpus agrees
otherwise.


Steve Mansfield
[EMAIL PROTECTED]
http://www.lesession.demon.co.uk - abc music notation tutorial and other goodies
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] validation & the ABC corpus

[John Chambers]

Bryan writes:
|
| 1)  If you introduce this innovation for Jos=E9 it should be included in =
| the=20
| standard and hence wouldn't be invalid so wouldn't fall foul of validatio=
| n=20
| routines.

Yes.  It may not have to be a major part of the standard.   The  idea
would be to encourage developers to 1) allow any part of a tune to be
missing, and 2) include options to suppress any part of the music.

| 2) Just because you can't make everything perfect that's no reason not to=
|  try=20
| and make it better.

Except that these are value judgements, and one person't "better" is often
another person's "worse".

| 3) I don't want to force anybody to do anything they don't want to, I wou=
| ld=20
| just like to see a culture where quality and conformity to a standard are=
| =20
| valued.

I think it is valued, especially in the sense that ABC has a  lot  of
users because it works as a means of exchanging music.  Extending ABC
to new types of music has been slow mostly because of  worries  about
conformance with the standard and interoperability with other tools.

| 4)  Jos=E9 may not care but it's a pity that an interesting set of tunes =
| are=20
| inaccessible to the rest of the world.  Couldn't you persuade him to set =
| up=20
| an abc collection we can all see?

I've tried, and he's nice enough, but it's not all that high  on  his
list  of  priorities.   What  he  has  works  for  his small group of
musicians, who are likely all in touch with each other anyway.

| 5) abc2nwc can handle missing T: commands.  Pleasant tune.

So can abc2ps, and I'd guess that many other programs can handle  it,
too.   My  Tune  Finder  can't  simply because it's looking for title
matches, and without a title, it's not easy to get a match.

Also, observe that what isn't needed here is  software  that  handles
missing T:  lines.  What Jose needs is software that accepts T: lines
but omits them from the (PS or GIF) output.  This is a subtlety  that
is  easy  to miss, since it wouldn't be obvious to most musicians why
you would want to, say, copy a piece of music  but  leave  the  title
off.   But  Jose's  web  site  is  an  example  where  this is a very
reasonable thing to do.   He  has  said  that  he  also  takes  these
titleless  images  and  feeds them into word processing software.  He
also doesn't want the titles in these images, because he is adding  a
title  at the WP level.  This makes sense, since a title inside a GIF
image is pretty much worthless, while the WP doc's title can be  used
for searching and indexing.

So what it would take to get his tunes' titles into my index files is
probably  a  version of abc2ps that has an "ignore T:  lines" option.
Then he could put the T:  lines into his abc files and still get  the
same  GIF  files without titles for embedding in HTML or Word docs or
whatever.

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

Re: [abcusers] V:

[John Chambers]

| V:1 abcd abcd |
| V:2 ABCD ABCD |

Well, abc2ps rejects this, but it handles:

[V:1] abcd abcd |
[V:2] ABCD ABCD |

On user-friendliness grounds, I'd think that both  should  be  legal.
But  this implies something else:  Users would then have to "declare"
voices in the header if they want to include any info about them. The
reason that abc2ps doesn't accept the first syntax is that it accepts
a voice definition (including  possibly  changes)  inside  the  music
portion.   So  it is trying to parse the abcd as an option to the V:1
line, and gets confused.

A reasonable compromise might be to allow only V:# at the start of  a
line  of  music,  but  also  allow  [V:...]  inline  anywhere for the
occasions when you want to change the voice's specs.  This  would  be
consistent  with  some  other  parts  of  ABC's  grammar, and not too
difficult to explain to users.

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

Re: [abcusers] V: again

[John Chambers]

James Allwright writes:
| > Hmm.  Sort of like a tab stop?
| No, not like a tab stop at all.
|
| > Tell me, can you use that to
| > synchronize at other than a bar line?
|
...
| Since nobody yet seems to have even understood my description, I get
| the feeling that the concept is probably a bit too esoteric and confusing
| for the abc community.

Hmmm ...  I'd have to admit that I didn't understand it, either.  But
if  the  idea  is to be able to say "All the parts should be together
right here" then it does seem useful.

There's a similar concept in the way that abc2ps  implements  the  w:
lines. Normally each syllable lines up with a note, with * and _ used
to gobble extra notes.  But you can skip over all the remaining notes
in  a  measure  by using the | barline char in the w:  line.  So if a
staff starts with N bars of instrumentals, you can put N bar lines at
the start of a w:  line and avoid the need to do any note counting.

I'd think that something like this could be very useful with  voices,
since  it's  not  at  all  unusual  for a voice to be silent for long
stretches.  Rather than counting all those silent bars, it  might  be
better if we could just omit that voice for the section. And then, at
the start of a new section, use V:SYNC to say that all voices  should
be here now.  Implementing this should be simple:  Just keep track of
the highest bar count in any voice, and set all voices to that bar.

(But polyrhythmic music with unequal meters might complicate this.)
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

RE: [abcusers] developers/users

[Richard L Walker]

Definitely not the case with Windows, although the DOS software (for the
most part) appears to be free.  ...and one can always ask the developers for
anything.  Whether or not they think it worthwhile to implement is up to
them.

"Richard L Walker"<[EMAIL PROTECTED]>
Pensacola, FL 32504-7726 USA

-Original Message-
> O yes they are!  all the Linux software for abc is FREE, so I think
> nobody has the right to ask the 'developers' to do ANYTHING. - without
> paying them that is!

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

Re: [abcusers] developers/users

[Laurie Griffiths]

 >There are quite a lot of composition packages around already 
>- some of them shareware.   Would it not be better to keep 
> abc simple and concentrate on providing means of importing 
> / exporting abc to some of these packages?

This is exactly what happened in the case of Muse.
I added ABC to it because the drummer in our band had been
using an ABC package - abc2ps I think.
Laurie

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

[abcusers] Stressed note code

[Bruce Olson]

It will probably take a while to get all of the bugs out, but
I've programed in TRUE BASIC an ABC player that will play in 12
tone equal temperament or 21 note just intonation. It doesn't
fully implement ABC standards: 1- no double sharps or flats
because in just intonation that requires 14 more notes (not hard,
but not worth the effort), 2- no bagpipe notation (because I
don't know it), 3 - No Parts:X yet. [and no V:]

It's not a great ABC player, but that wasn't its primary purpose. 
It stressed-note codes a tune from it's ABC and calculates a
unique mode number for the tune. (See file CODEMTHD.TXT on my
website for coding method and mode#). 

It's got an optional J:specification where one can put the number
of sharps or flats on the key signature as n# or n^, or mb or m_,
or 0 for none. The default keynote is then automatically taken as the
final note of the tune, and the scoring mode determined from these. 
This is usually correct, and is the way I think ABC should have been 
set up in the first place, but it won't work if the key is changed 
in the tune and not reset to the original key by the end. This gives a
possible, but not good, scoring mode for most circular modes, but it's
a disaster for a circular major ending on the 7th because that comes 
out locrian. One can add the required keynote in J: and then it will 
figure out the scoring mode from what's in the J: specification alone.
Note that with any J:spec you bypass the K:spec. It's processed and 
displayed for comparison, but no part of it is used. You don't have 
to know the keynote to play a tune, or write out the music for it, 
but you do have to have it to stressed-note code the tune. 

I know of no unique way to code circular tunes, so in cases where 
the last note doesn't match the keynote in K:spec (or J:spec) the 
tune is designated circular (or K:spec or J:spec is wrong), and
the position of the last note relative to the specified keynote
is given. 

The current version is ABZWEB4.EXE on my website. There are 8 
stressed notes in my code and depending on meter and time signature 
there are 1 to 4 stressed notes in a measure. One can't stressed-note 
code across a key or timing change in the tune at present (and
probably forever). Mode designations, and the mode name if it has
one (in English), are in the file MODTABL.TXT and there are 180
mode designations in it that I found from hand coding about 6500
old British Isles popular and traditional tunes, and these range
from 3 note to 11 note scales, but that doesn't mean I've found
everything, and you may sometime get a blank where mode designation 
is displayed.

PS: I'm not a developer. I'm interested in coding tunes for
purposes of identification.

Bruce Olson

Old English, Irish and, Scots: popular songs, tunes, broadside
ballads at my website (no advs-spam, etc)- www.erols.com/olsonw
or click below  http://www.erols.com/olsonw"> Click 
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] developers/users

[Richard Robinson]

On Wed, 24 Jan 2001, Jack Campin wrote:

> > The only other course open to someone determined not to pay
> > for software but still wanting special funstions is to do
> > what the rest of us do -  get out gcc / emacs / TeX and get started!
> 
> I'd like to, but (a) the abc2mtex port for the Mac doesn't work and is
> unsupported and (b) nobody's done an MPW port of any PS or TeX converter
> that I could use as a starting point (MPW is the only free C compiler
> for the Mac).  I know zilch about GUI programming, have no interest in
> learning it, and am not about to waste a year of my life reinventing
> wheels.  If I can get one of my old Suns working, I'll be in a better
> position to do some ABC implementation, as I'll be able to disregard
> the GUI stuff.

What's with this story about the New Mac OS being some kind of Unixy
variant ? Will that give Mac people access to all the GNU stuff ? 

-- 
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] developers/users

[Jack Campin]

>> Developers are *not* the only people who get a say in what ABC ought
>> to be, or what it should be used for.
> O yes they are!  all the Linux  software for abc is FREE, so I think
> nobody has the right to ask the `developers' to do ANYTHING. - without
> paying them that is! 

The point is that since ABC is just text, a user like me can put whatever
the hell they like in it, and whether any computer implementation can
make sense of it is a secondary issue.  Luckily for me, BarFly doesn't
get too badly flummoxed by the notations I need to use.

ABC doesn't even need to be constrained by typeability.  I have hundreds
of pages of ABC written in pencil.  For most of it, I notated the slurs
by drawing them above the text lines in the same way as in staff notation:
much more readable, and easy to convert when I got round to typing it in.
I don't give a damn whether anyone implements a computer analogue of that.

I also have a bunch of cue cards written in two colours of ink giving
the first bar or two of tunes in sets I play.  Needless to say these do
not have regular header fields, they'd be a waste of space.  It's non-
standard and non-computer-processable ABC but it's still ABC (i.e. any
human who knew the notation could read it) and it's useful.


> That way, abc  can still be used to `sketch' the music & express
> the salient points, whilst adding the `bells and whistles' using
> something else that CAN ALREADY do it...
> This could of course, result in loss of detail when abc is re-exported,
> which one would have to accept, since any conceivable abc notation
> will still  probably be insufficient for a lot of the advanced music 
> typograpy..

This is arse-backwards for what I'm doing.  I need to be able to notate
every single musically relevant detail from my sources - mistakes and
all.  Some of this information might be lost in editing/typesetting.
My ABC source is richer in musical information than a typographic file
would be.


> The only other course open to someone determined not to pay
> for software but still wanting special funstions is to do
> what the rest of us do -  get out gcc / emacs / TeX and get started!

I'd like to, but (a) the abc2mtex port for the Mac doesn't work and is
unsupported and (b) nobody's done an MPW port of any PS or TeX converter
that I could use as a starting point (MPW is the only free C compiler
for the Mac).  I know zilch about GUI programming, have no interest in
learning it, and am not about to waste a year of my life reinventing
wheels.  If I can get one of my old Suns working, I'll be in a better
position to do some ABC implementation, as I'll be able to disregard
the GUI stuff.

===  ===


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

Re: [abcusers] developers/users

[Phil Taylor]

Jack Campin wrote:

>Question prompted by the above: is there any ABC implementation out
>there with the ability to automatically place guitar chords or text
>annotations clear of notes on leger lines?
>

Yes, BarFly does!  Try this:

X:1
T:test
M:C
K:C
"A"A2 "A"a2 "A"a'2 "A"a''2 | "A"A2 "A"A,2 "A"A,,2 "A"A,,,2 |

Actually in this case the a'2 and it's chord collide with the title,
and a''2 goes right off the top of the page.  Since BarFly gives you
a choice of whether you place guitar chords over or under the staff
this also works in the other direction too.  There are almost certainly
other symbols which get drawn above and below the staff which will
collide with guitar chords and annotations, but notes on leger lines
are not among them.

Phil Taylor


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

Re: [abcusers] developers/users

[Phil Taylor]

Somebody wrote:
> Laura:
> >> The reason the guitar chord notation got co-opted for text annotations
> >> is that many, many users needed a text annotation of some kind.
>
> Bryan:
> > No.  This is a reason for developing a text annotation system, not a
> > reason for co-opting the guitar chord notation.  Couldn't they have
> > developed something new instead of messing up something that already
> > existed?

That's exactly what we did, Bryan.  The system of using ^ and _ to
denote annotations over or under the staff was proposed by Wil Macaulay
about two years ago and incorporated in the next version of BarFly
(which also allows < and > to place the annotation to the left or right
of the note head when you want to annotate a particular note in a chord).
Most programs have followed suit.

>
>> Developers are *not* the only people who get a say in what ABC ought
>> to be, or what it should be used for.
>
>O yes they are!  all the Linux  software for abc is FREE,
>so I think nobody has the right to ask the `developers' to do ANYTHING.
>- without paying them that is!
>
>If someone makes a deal with me to do a programming job, then I do it
>the way they want it for pay - but not otherwise.
>
>If I program for myself - then I do EXACTLY what I want - and i would
>be surprised of most developers do not do just the same.

Dead right.  I wrote BarFly for myself because I was tired of struggling
with abc2mtex.  I put it up on the web for other users free use on a
take it or leave it basis.  The only responsibility I acknowledge
towards the users is to make sure that it won't do them any harm
(carry viruses, corrupt their operating system etc).  I do read and
reply to their letters, and have implemented many of their suggestions.
But I don't have to.

Phil Taylor


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

Re: [abcusers] V:

[Bryancreer]

Laurie Griffiths asks -

>Can someone tell me how to access the ABC Users list archive.
>(Do we have one?)  

Well, I've heard it mentioned but I don't know how to get at it.

The V: command has moved on since the issue you mention which I agree is 
manageable.

The question now is on the format of the V: command itself.  Some of the 
quesions are -

1)  Should it be a number and nothing else eg. V:1  V:2 ...

2) Should it be nameable instead eg. V:soprano,  V:alto ...

3)  Should it have parameters eg. V:1 nam=vocal clef=bass or should these 
appear in local commands applicable to one voice only.

4)  Should music be allowed on the same line 
eg. V:1 f4 gf/2g/2|a2 f2 d2|b3 c'd'b|a2 f2 d2|

There are definite compatibility problems between 3) and 4).  Someone argued 
that V:1 clef=bass could be legitimate music.

That is the discussion that fizzled out.

Another point which a couple of people have made is that voice and staff are 
not the same thing.  A voice may cross over between staves.  Two voices can 
be represented on the same staff.  These have been largely ignored but there 
are implications for the parameters.  For instance I would say that clef is a 
property of staff not of voice.  On the other hand, key is probably a 
property of both.

Bryan

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

Re:[abcusers] developers/users

[Bryancreer]

Jack Campin says -

>For one group of projects
>I needed something - anything - that would let me put 1700ish ornament
>signs into the ABC score and let me print them in staff notation after
>a fashion.

Well you could have asked Phil Taylor for extensions to BarFly to cover what 
you needed and produce a better result than the bodge you've got.

>This particular user doesn't give a damn about conflicts with the guitar
>chord syntax because I never need to write guitar chordings (and usually
>remove them from other people's ABC before using it myself).

Same here.  It would be nice to have a bit of software that could process a 
whole collection that way but since a computer can't tell what's between the 
quotes you might end up throwing away useful information.

>The Internet tune exchange aspect of ABC is also irrelevant to this
>stuff since I've never shared the bulk of it in source form with anybody
>else and am not likely to any time soon.

No problem for you then, but other people are sharing tunes with with this 
sort of thing in them.

>Developers are *not* the only people who get a say in what ABC ought
>to be, or what it should be used for.

There seem to be some developers who disagree with that.

Bryan

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

Re: [abcusers] developers/users

[Personal & non-commercial]

On Wednesday 24 January 2001 01:00, you wrote:
> Laura:
> >> The reason the guitar chord notation got co-opted for text annotations
> >> is that many, many users needed a text annotation of some kind.
>
> Bryan:
> > No.  This is a reason for developing a text annotation system, not a
> > reason for co-opting the guitar chord notation.  Couldn't they have
> > developed something new instead of messing up something that already
> > existed?

Dead right!  The best thing about abc is being able to write out single
line melodies with `a violence Tulloch' type chord accompaniment
-- as a demo for the band.

If it can't do that,  is no use to me (for a start).

> This particular user doesn't give a damn about conflicts with the guitar
> chord syntax because I never need to write guitar chordings (and usually
> remove them from other people's ABC before using it myself).

Not a bad idea really -but if one has a 
guitarist who keeps asking  - `tis a mighty handy thing to be able to do!

On the other hand, since we seldom need to notate the peculiar trills
used by a zambian nose-bagpipe-flautist, we (along with many others)
feel no pressing need for such a facility.

> Developers are *not* the only people who get a say in what ABC ought
> to be, or what it should be used for.

O yes they are!  all the Linux  software for abc is FREE,
so I think nobody has the right to ask the `developers' to do ANYTHING.
- without paying them that is! 

If someone makes a deal with me to do a programming job, then I do it
the way they want it for pay - but not otherwise.

If I program for myself - then I do EXACTLY what I want - and i would
be surprised of most developers do not do just the same.
 
There are quite a lot of composition packages around already - some
of them shareware.   Would it not be better to keep abc simple
and concentrate on providing means of importing / exporting abc
to some of these packages? - by providing parsing routines for
selected shareware authors for ex.

That way,  abc  can still be used to `sketch' the music & express
the salient points, whilst adding the `bells and whistles' using
something else that CAN ALREADY do it...

This could of course, result in loss of detail when abc is re-exported,
which one would have to accept, since any conceivable abc notation
will still  probably be insufficient for a lot of the advanced music 
typograpy..

The `simplistic'  users can continue to use abc for free, and those
who actually want all the extra programming effort can pay -
seems fair to me!

The only other course open to someone determined not to pay
for software but still wanting special funstions is to do
what the rest of us do -  get out gcc / emacs / TeX and 
get started!


Regards, RJP

-- 
RJP - <[EMAIL PROTECTED]> .

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

Re: [abcusers] Developers responsibilities

[Bryancreer]

>From Steve Mansfield - 

>Try http://www.lesession.demon.co.uk/abc/abc_extensions#annot as a
>starting place - and if I've documented them in there, they must be in one
>of the abc standards documents on Chris W's site (I would suspect, but
>haven't checked, in the 1.7.6 proposal, as that's where most of
>abc_extensions.htm is based on).

Thanks Steve but I haven't been able to find that link on your site.  While 
looking for it  I did find -

>If you are reading this tutorial wishing only to understand how abc is 
written now, >you can safely ignore these links to proposed extensions. 
Features described in >these linked sections are NOT an agreed part of the 
abc notation standard, but are >proposed extensions to that standard that may 
in the future be adopted as a part of >the standard. Features decribed there 
should NOT be used in any abc file which is >intended for distribution, as 
the feature may not be understood by other users or 
>supported by their particular choice of abc software. 

Not a widely held view, I'm afraid.

There is more in the draft standard than I realised.  The use of ^ and _ in 
text are there along with a few other symbols.  Those two are getting used so 
I'd better include them in my software I suppose.

"^D.C." as an explicit use isn't, but !D.C.! is.  Unfortunately, that runs 
into trouble with abc2win's (non-standard) use of !.

Why is life so complicated?  (Because we make it so.)

Bryan

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

[abcusers] Re:Developers responsibilities

[Bryancreer]

Laurie Griffiths says -

>Fare??  Fair, I think.

Neatly avoiding answering the point.  Taking a chance aren't you Laurie?  
You're going to have to triple check every post you send from now on in case 
I spot a misplaced comma.  Don't worry.  Weather oar knot eye agree with watt 
ewe say, I won't bother with that.

>I also claim to be able to import MIDI files,..

I already said that for practical reasons you will always have to limit the 
scope but you have to do enough to make that claim true, not just "I import 
the subset of MIDI files that interests me."

>As I claim to display music notation then I would have a duty to make
>that as complete as possible (a lifetime's work I should think).

Some people have dedicated their lives to less worthwhile tasks.

>In fact what I do is try to do "a reasonable job" of all of these,

Good, but that might not be the same thing as doing what you need for 
yourself which is what you first said you did.

>It's something that isn't even worth arguing about.  Their "right"
>for want of a better word is a fact of life.  I couldn't take it
>away from them if I tried.  What would we do?  Try to patent
>ABC and then sue them?  I think not!

Neatly avoiding answering the question again and clearly illustrating the 
point I've been trying to make.  No, we are powerless to stop them.  All we 
can do is ask them to show some consideration for other developers and users. 
 You said that anarchy had rules but no rulers; now you seem to be saying it 
has rulers but no rules.  Is Chris Walshaw wasting his time asking people to 
agree on a standard?

You seem to think the world is the way it is and nothing can be done about 
it.  John Chambers wants a voluntocracy of governance by those who do the 
work.  Phil Taylor wants a democracy of developers.  I want a culture of 
co-operation between all in the abc community who want to contribute.

Perhaps we should take a vote on it.

Bryan

Spellchecker rejected Griffiths, Walshaw and voluntocracy .

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

Re: [abcusers] V:

[Phil Taylor]

Laurie wrote:

>I remembered a discussion a bit before that when there were two
>versions, one of which tended to present tunes as
>V:1
>
>V:2
>
>V:1
>
>V:2
>
>and another which did
>V:1
>
>V:2
>
>
>I remember Phil saying that to handle the one that he didn't
>you'd have to keep an internal copy of the whole score,
>which is of course exactly what Muse does.
>

That's correct.  BarFly will currently only display the first version
correctly because it displays each line as it is parsed.  It will
play either version.  I'll probably support display of the second
version at some point in the future, but it means a major re-write.

Some other points of contention were:

*  The interpretation of clefs other than the treble clef.
The introduction of the extended K: field which you already have in
Muse, and I will have in the next BarFly version fixes this rather
neatly, and also allows for the handling of transposing instruments.

*  Whether the V: field should allow the tune on the same line as the
field identifier i.e.

V:1 abcd abcd |
V:2 ABCD ABCD |

as opposed to

V:1
abcd abcd |
V:2
abcd abcd |

BarFly currently allows either.  I like the first for it's compactness,
and ease of comparing notes which form chords between the voices, but
no other programs can deal with it.

*  Placing of initial voice-specific commands in V: fields in the header.
BarFly uses this mechanism for lots of purposes;  other pargrams use
a combination of %%midi, %%staves and other such %% thingies in the
tune, or extend the V: field by putting commands on the V: line.

Phil Taylor


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

Re: [abcusers] V: again

[Phil Taylor]

James Allwright wrote:

>Since nobody yet seems to have even understood my description, I get
>the feeling that the concept is probably a bit too esoteric and confusing
>for the abc community.
>

I think I understood it OK.  Perhaps the word Synch is a bit confusing,
since it implies that the voices should be forcibly synchronised from
this point, rather than "since the voices are already in synch here we can
put in some fields which apply to all of them".

Phil Taylor


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

Re: [abcusers] V: again

[James Allwright]

On Wed 24 Jan 2001 at 12:19AM -0800, John Walsh wrote:
> 
>   Hmm.  Sort of like a tab stop? 

No, not like a tab stop at all.

> Tell me, can you use that to
> synchronize at other than a bar line? 

Yes, the idea is that voices can be synchronized whenever there is the
same musical time in each. The idea is not to bodge in some extra rests
to make the voices match up. The idea is to go into a 'global mode' at
the end of a multi-voice passage.

Since nobody yet seems to have even understood my description, I get
the feeling that the concept is probably a bit too esoteric and confusing 
for the abc community.

James Allwright

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

Re: [abcusers] V:

[Laurie Griffiths]

Bryan said:
>Which discussion was this?  It has cropped up several times.  
> The significant one was in the second half of November when 
> I think you were out in the Atlantic. (How did it go by the way? 

The fact that I'm alive means that it went well!  

 
Can someone tell me how to access the ABC Users list archive.
(Do we have one?)

I remembered a discussion a bit before that when there were two 
versions, one of which tended to present tunes as
V:1

V:2

V:1

V:2

and another which did
V:1

V:2


I remember Phil saying that to handle the one that he didn't 
you'd have to keep an internal copy of the whole score, 
which is of course exactly what Muse does.

Laurie

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

Re: [abcusers] V: again

[Phil Taylor]

John Walsh wrote:
>X:7
>T:Polyrhythmic with No Coherent Bar Division
>Z:The notes line up, but the bars don't
>B:MusiXTeX doc p 47
>M:3/4
>L:1/8
>K:C
>V:1
>F2 F2 F2|F2 F2 F2||F2 F2 F2|F2 F2 F2:|
>V:2
>M:2/4
>F2 F2|F2 F2|F2 F2||F2 F2|F2 F2|F2 F2:|
>V:3
>M:3/8 L:1/8
>F3|FFF|F3|FFF|F3|FFF|F3|FFF|F3|FFF|F3|FFF:|

Surely the third voice is half as long again as the other two?
If it were written like this it would be OK:

X:7
T:Polyrhythmic with No Coherent Bar Division
Z:The notes line up, but the bars don't
B:MusiXTeX doc p 47
M:3/4
L:1/8
K:C
V:1
F2 F2 F2|F2 F2 F2||F2 F2 F2|F2 F2 F2:|
V:2
M:2/4
F2 F2|F2 F2|F2 F2||F2 F2|F2 F2|F2 F2:|
V:3
M:3/8
L:1/8
F3|FFF|F3|FFF|F3|FFF|F3|FFF:|

BarFly displays the second version correctly, except that there's
no way to turn long barlines off in the current version, so the
barlines in V1 get drawn across all three staves.  All the notes
line up in the correct places, and it plays correctly.

I'm not sure that I understand what the SYNC command is for.  Is
it simply to define an area of text where all fields will be
interpreted as being global to all voices?  On the whole I find
it more intuitive to avoid global fields except in the header.

Phil Taylor


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

Re: [abcusers] V: again

[John Walsh]

James Allwright writes:

>The idea is that we introduce another V: directive
>
V:SYNC
>
>which marks the point in the abc where all the currently active voices
>synchronize together and we go back into a global mode. Any K:, L: or
>Q: field from this point on will apply to all voices (so we have a
>mechanism for global parameters). The V:SYNC also provides a checkpoint
>in the abc - if the different voices have different musical time, then
>we know that something has gone wrong and any good abc program should
>report an error.

Hmm.  Sort of like a tab stop?  Tell me, can you use that to
synchronize at other than a bar line?  Because I've just been playing a
little bit with multistaff music and voices, and from a few of the
examples I've looked at, I had the impression that if we ever got serious
about them, we'd have to introduce some kind of tabs to allow
synchronization at other than bar lines. (And de-synchronize at some bar
lines.)  It comes up in polyrhythmic music.  So I'm happy to see
that the suggestion came forth, but a bit surprised that it was in the
form of a header field, not an in-line tab.  An alternative would be to
use, say "&" as a tab stop in-line---that's what tex and latex use.  (It
would conflict with the use of & in abc2mtex, but I wonder if anybody else
has ever actually used it?)  The convention would be that all the voices
would line up at these tabs.


 The following example seems relevant.  It came from the users guide
to MusixTeX, which gave the MusiXteX code.  I translated it to abc, but I
admit that I don't really understand how to use the voices correctly on
this one. It's polyrhythmic music---the first voice is in 3/4, the second
in 2/4, and the last in 3/8. The notes should line up, but the only bar
lines at which all three parts line up are the double bars and the
repeats. All parts should finish at the same time. (I'm saying this,
because it may not be evident in the print-out---at least I wasn't able to
get it to work in what I've tried so far. There is probably a better way
to write out the abc---it should *at least* be possible to get the meters
of the different staves to be different. I tried to get it via in-line
changes of rhythm, but that didn't seem to work either.)

(This is part of a project which Laura Conrad has agreed to post
on Source Forge, so it should be available shortly at, I'm afraid, *much*
greater length.)

Cheers,
John Walsh

X:7
T:Polyrhythmic with No Coherent Bar Division
Z:The notes line up, but the bars don't
B:MusiXTeX doc p 47
M:3/4
L:1/8
K:C
V:1
F2 F2 F2|F2 F2 F2||F2 F2 F2|F2 F2 F2:|
V:2 
M:2/4
F2 F2|F2 F2|F2 F2||F2 F2|F2 F2|F2 F2:|
V:3
M:3/8 L:1/8
F3|FFF|F3|FFF|F3|FFF|F3|FFF|F3|FFF|F3|FFF:|

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