Re: [abcusers] dynamics (was)

[Wendy Galovich]

On Wednesday 31 October 2001 17:50, [EMAIL PROTECTED] wrote:
> Thinks.  Must try and come up with a more relevant subject line for this
> thread.
>
> James Allwright said -
>
> >I don't think you'll ever get the standards committee to speak as
> > one..
>
> I think we have to accept that the standards committee is now defunct.
>
> >It is still possible for someone who cares about an abc standard
> >to help the process along; get hold of every abc program you can,
> >go through them carefully and then document the compatibilities
> >and incompatibilities carefully on the web. If you do this
> >carefully and comprehensively enough it be a valuable resource to
> >guide any new abc developer on interpreting the more subtle aspects
> >of abc.
>
> This is more like it.  I think the someONE is a problem.  Could we make
> this a shared task?  A lot of it may already have been done.  I think a lot
> of work on cross referencing different implementations has been done by
> John Chambers and Phil Taylor has recently done some work on the different
> versions of the V: command.  Individual developers could contribute their
> own data.  What we need is a way of collating this information in a single
> location.

A Wiki page? See http://www.usemod.com/cgi-bin/wiki.pl?WhatIsaWiki

What I'm thinking here is that if an editable page - say, a table listing abc 
applications against each detail of the standard specifications, was publicly 
available, a sizeable group of contributors could work on it, and the task of 
updating it wouldn't have to fall to one designated person.

Wendy

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

Re: [abcusers] requesting goodies from developers

[Phil Taylor]

Richard Robinson wrote:

>By "section header", do you mean the global header lines, external to any
>tune ? I've been wondering about this recently, whether many people use
>them. I like them, I find they can save a lot of fiddly typing, but I'm
>not sure what programs handle them.
>
> (Surely it's not _that_ hard for a GUI app. ? Reading & applying them is
> fairly simple, just go through the file & suck the tunes into memory,
> with default headers applied where necessary. Writing is an extra fiddle,
> if you want to remember the globals, but you don't actually change the
> meaning of anything by not doing that. )

>From the abc 1.6 definition:

"  Information fields
  ==

The  information  fields  are  used  to  notate  things  such  as
composer,  meter, etc. in fact anything that isn't music. Most of
the information fields are for use within a tune  header  but  in
addition  some  may be used in the tune body, or elsewhere in the
tune file. Those which are allowed elsewhere can be used  to  set
up  a  default  for  the whole or part of a file. For example, in
exactly the same way that tunebooks are organised, a  file  might
start  with  M:6/8 and R:Jigs, followed by some jigs, followed by
M:4/4 and R:Reels, followed by  some  reels.  Tunes  within  each
section then inherit the M: and R: fields automatically, although
they can be overridden inside a tune header."


So within a file you can have global header lines (at the beginning
of the file before any tunes) and section header lines (in between
tunes at the start of each section).

BarFly supports the global stuff, which can include information fields,
macro and symbol definitions, but not section headers between tunes.
In order to support these the parser would have to parse the whole file
from the beginning in order to display the 900th tune.  Remember that
the file may have been edited since the last operation without the
edits being saved, so it's not sufficient to just parse the whole
thing when it's opened.

As far as possible I prefer abc tunes to be self-contained.

Phil Taylor


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

[abcusers] text line break

[Jack Campin]

I've been doing a lot of stuff lately where it make sense to indicate
where text lines in a song finish, without doing full-on underlay of
the sort allowed for by the w: construct.

The way I've been doing it is the way old hymnbooks did it, using
double bars.  But this seems rather heavyweight and clashes with
ABC's repeat syntax.

Would a special symbol help anybody else?  "!!" maybe (in the hope
that abc2win's "!" gets into the standard and hence becomes reserved).

Note that in BarFly (and any other program with the same attitude
to linebreaks) this would HAVE to allow a staff break as a barline
or double bar does at present, there'd be no point in having it
otherwise - you don't want to start a text line on the last note
of a staff line, which is what would happen where lines begin with
upbeats.

===  ===


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

Re: [abcusers] requesting goodies from developers

[Richard Robinson]

On Wed, 31 Oct 2001, Phil Taylor wrote:

> Jack Campin wrote:
> 
> >The 1.6 standard is doing pretty well, in that virtually everything
> >in it *is* implemented consistently; there are only three significant
> >misimplementations I can think of - abc2win's idea of tempo, BarFly's
> >idea of where a line breaks, and abc2ps's way of handling gracenotes -
> >and only the last of those lets the user in for much typing to work
> >round it.
> 
> You could add abc2win's use of the exclamation mark, and it's insistence
> on having the notes in chords in a particular order.  Also, I don't think
> any programs other than abc2mtex implements section headers (section
> headers are really only possible to deal with in a program which reads
> through an abc file linearly - programs which treat abc files in a random
> access fashion as all of the GUI applications do find this very difficult).

By "section header", do you mean the global header lines, external to any
tune ? I've been wondering about this recently, whether many people use
them. I like them, I find they can save a lot of fiddly typing, but I'm
not sure what programs handle them.

 (Surely it's not _that_ hard for a GUI app. ? Reading & applying them is
 fairly simple, just go through the file & suck the tunes into memory,
 with default headers applied where necessary. Writing is an extra fiddle,
 if you want to remember the globals, but you don't actually change the
 meaning of anything by not doing 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] Multivoice doc

[Phil Taylor]

James Allwright wrote:

>It is still possible for someone who cares about an abc standard
>to help the process along; get hold of every abc program you can,
>go through them carefully and then document the compatibilities
>and incompatibilities carefully on the web

I started to do something similar to this with respect to the V:
field.  It proved to be very hard work.  It is still incomplete,
and almost certainly contains errors, but you can read the results at:

http://www.barfly.dial.pipex.com/multivoice.txt

Corrections and additions are very welcome.

Phil Taylor


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

Re: [abcusers] requesting goodies from developers

[Phil Taylor]

Jack Campin wrote:

>The 1.6 standard is doing pretty well, in that virtually everything
>in it *is* implemented consistently; there are only three significant
>misimplementations I can think of - abc2win's idea of tempo, BarFly's
>idea of where a line breaks, and abc2ps's way of handling gracenotes -
>and only the last of those lets the user in for much typing to work
>round it.

You could add abc2win's use of the exclamation mark, and it's insistence
on having the notes in chords in a particular order.  Also, I don't think
any programs other than abc2mtex implements section headers (section
headers are really only possible to deal with in a program which reads
through an abc file linearly - programs which treat abc files in a random
access fashion as all of the GUI applications do find this very difficult).

But you are right, the 1.6 standard is mostly adhered to very closely.

Phil Taylor


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

Re: [abcusers] dynamics (was)

[Laurie Griffiths]

I had hoped that we could make progress on some of the things which are
already implemented here and there (and in fact the implementations are not
totally incompatible).
>From memory (if any of these are in actually the standard then forgive me)
w: to specify words
v: to specify voices
Some way to specify clefs (implementations use k: and v:)

There are of course plenty of other things to do and to argue about.

This is not the Voice Of The Committee, just me.

Laurie

- Original Message -
From: James Allwright <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 31, 2001 11:32 AM
Subject: Re: [abcusers] dynamics (was)


On Wed 31 Oct 2001 at 05:17AM -0500, [EMAIL PROTECTED] wrote:
>
> There seems to be some confusion here.  Has the standards committee
decided
> anything or not?  Could we have a clear statement from the committee
(rather
> than individual members) on what it has achieved and its current status?
>

I don't think you'll ever get the standards committee to speak as one
person with a unified voice. My opinion is similar to Phil's. I took
the approach of identifying all the new features in the new draft
standard and seeing which ones were universally approved and which
ones were not. This seemed like a good way to make progress, and I
got the impression that disagreement was restricted to relatively
minor features and obscure options of major features. However, the
thread petered out without any definite conclusions; people were
either not interested in this approach or distracted by other
projects.

It is still possible for someone who cares about an abc standard
to help the process along; get hold of every abc program you can,
go through them carefully and then document the compatibilities
and incompatibilities carefully on the web. If you do this
carefully and comprehensively enough it be a valuable resource to
guide any new abc developer on interpreting the more subtle aspects
of abc.

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


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

Re: [abcusers] dynamics (was)

[Richard Robinson]

On Wed, 31 Oct 2001 [EMAIL PROTECTED] wrote:

> In a posting a few days ago, Laura Conrad spoke first of the
> difficulties of achieving agreement on a standard and then spoke of the
> sort of the sort of open-source project that she would like to see.  I
> took these as one topic reflecting more of the same association of
> standard and software project and used my now notorious "outlaw"
> reference.  She then said that she was simply making two separate points
> in the same email and I (if you recall) apologised.  I may have been a
> little premature in doing so as, since then, Richard Robinson and others
> have argued that the development of the abc standard should be
> associated with a software project. 

I have reviewed all my postings to this thread, since Laura's comments and
before. I can't find any such statements.

I don't see a conflict, actually. A spec. "should" describe how software
behaves, software "should" behave as described, and wouldn't it be nice if
the thousand flowers could converge on a single description ? Writing code
and writing documentation are not unrelated, but they're not identical
skills either; lots of people are better at one than the other, and lots
of people _are_ invloved, in whatever way is accessible to them. Even if
it be arguing the toss about priorities on the mailing list ... My feeling
is that things are likely to go better when people are scratching the
itches that they actually feel. If somebody proposes that they might write
some code, I presume they have thought for themselves about what they
could do, and that that is what they think best, and I prefer to accept
that rather than getting upset because they're not scratching whatever
itch I'm feeling.

I think John's comments, yesterday, sum things up pretty well, as regards
software and/or specification. 


-- 
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] requesting goodies from developers

[Jack Campin]

Gianni Cunich wrote:

[Gianni, please don't quote an entire message when replying; you quoted
 a heck of a lot in your reply and then your software appended the whole
 of my text as well.]

>> What features do you need and why?  Does anybody else need them?
> I'm not concerned about asking new or particular features. I've been
> asking for an update of the standard, introducing what has been agreed
> about in the drafts, plus a solutions to the main features the developers
> on this mailing least have not been able to reach any agreement at all
> so far - i.e. multistave and multivoice scores -. Do you think I'm alone
> in this requests?

No, but that amounts to asking for a lot more new features to be added
to *all* the ABC applications out there; a different set for each one
and with the difficulty of implementation of an extension being very
variable depending on which platform you're adding it to.  (John Chambers'
extended-variant-repeat construct is easy to add to a purely graphical
implementation and quite hard for a player program; my suggestion for
percussion staves is easy to add to a pure player program and a lot
harder for a staff-notation generator if the assumption that staves
have five lines was wired in too deep).


> In other words, what I am concerned with is a developement of the abc
> notation as an exchange format. I wish to be sure that if I upload on the
> web or swap on a mailing list anything that's not a sketchy Irish session
> tune written in sketchy Irish session tunes fashion - say a three part
> Italian fiddles plus bass transcription - those who will be wishing to
> make use of it could trust, whatever software they use, that they will
> be able to display (at least for what matters) the score I'd print with
> the software I use, or listen to a midi files that ensure a correct
> listening rather than making a mess of the tune.

With the multi-voice stuff, the differences are resolvable with fairly
simple editing; the main problem is the different pitch conventions
for non-treble staves between BarFly and the abc2ps variants, and BarFly
has transposition utilities to help with that (I presume something
analogous is possible on platforms that support abc2ps).  I've used
Laura's ABC files without much trouble and she's done the same with
mine, though neither of us has made any concessions to the other's
usual platform.

One of ABC's main strengths is that the user can easily tinker with it
(impossible for graphic file formats); need a version with different
note density, different chording or an unusual transposition? - just
make it yourself.  It's a format for musicians, not for the sort of
passive listeners who are best served by MIDI files.  Learning to play
a piece always takes a certain amount of time, so it's no great hardship
if a fraction of that time is spent in getting the piece into a form you
can use.

The user makes more difference than the developer here.  If an ABC
file is clearly written *as source*, with the right choice of default
note length and laid out with some regard to the musical structure,
it's easy to work round dialect differences because you can see what
you're editing.  Easier than it is to modify a sloppily-encoded piece
that fits your own platform's model perfectly but in ways only a
computer can understand.  (We should maybe have an annual obfuscated
ABC contest to underline this point).

So, what you could do is carefully code up a piece of the sort you're
talking about and upload it somewhere.  Doesn't matter which platform
you use; if the music's worthwhile it'll act as an incentive for the
developers to add features to handle it.  (BTW, isn't Frank's Vivaldi
concerto an example of the sort of thing you're talking about?  What
goes wrong with it?)


> [attributed to a developer] "the abc is such a poorly implemented
> standard, full of inconsistencies and ambiguities..."

The 1.6 standard is doing pretty well, in that virtually everything
in it *is* implemented consistently; there are only three significant
misimplementations I can think of - abc2win's idea of tempo, BarFly's
idea of where a line breaks, and abc2ps's way of handling gracenotes -
and only the last of those lets the user in for much typing to work
round it.

The last one is a specific problem for abc2ps.  It has been fixed
in some of the variants, but there's nothing at present to dissuade
somebody doing a new version based on the unfixed code and thereby
resurrect the bug.  A shared code library where the gracenote-handling
modules could be once-and-for-all, definitively updated would finally
bury the earlier version with a stake through its heart (with pipers
the world around dancing on its grave).

===  ===


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

Re: [abcusers] dynamics (was)

[Anselm Lingnau]

[EMAIL PROTECTED] writes:

>Richard Robinson's speculations as to what I might say ran completely 
> counter to what I was actually saying.  He first said that I would go on to 
> explain that open-source was a bad form of development whereas I actually 
> said that it was just one of several equally legitimate methods.
> [...]
> It is, because the same applies to a lot of other interested parties who 
> either cannot or choose not to take part in an open-source project.
> [...]
> I think she was, in fact, right.  Talk of a standard is meaningless because 
> nobody has the power to enforce it. Let us talk, instead, of a protocol for 
> the exchange of information as I have suggested before.  Instead of fighting 
> over the points we disagree on, let's start by establishing what we do agree 
> on and let's do it on this list, not in secret conclave.

In my opinion, what would be nice to have is

  1. a well-defined ABC standard describing a common feature set for `most'
 applications. This should include most if not all of what is now
 specified in the 1.6 standard (we could leave out some of the more
 contentious items for now).

  2. a method for proposing, debating, and accepting additions to this
 standard, which will result in new versions of the standard.

  3. a provision for individual applications (or groups of applications)
 to add features in a way that does not conflict with what other
 applications do. We need this to support `niche' application areas
 that are probably not interesting enough to the world at large to
 deserve inclusion in the baseline standard (and thereby support by
 all conforming ABC applications). This should include a way for
 ABC files to denote exactly which additional feature sets on top of
 the ABC standard they need. (The namespace approach of XML seems
 to be an interesting inspiration.)

  4. a `reference implementation' of an application that reads a purported ABC
 file and checks it for conformance to the current standard. It should
 be made very clear that the written standard is what decides ABC
 conformance, not `the reference application (or any other ABC application)
 accepts it, so it must be conforming'. If the conformance-checking
 application detects a violation of the ABC standard in an ABC file, it
 should optionally output diagnostic information explaining it.

 If possible this application should be built on top of an ABC-reading
 library which is written in C (for maximum portability) and 
 published under a suitable license such as the BSD license, to make
 it acceptable to both the developers of open-source ABC 
 applications and those who for whatever reason do not subscribe
 to the open-source idea. For extra credit, this application (and/or 
 library) should be extensible to accommodate additions as per 3.
 Such a library would be very useful to open-source developers, 
 while others could take it or leave it, as long as whatever they
 came up with themselves did the same thing.

  5. a `test suite' of suitable ABC files that allows developers to 
 check whether a given ABC application does `the right thing'. This is
 obviously tricky since there are ABC applications that do lots of
 different things, and what is `right' often depends on the application.

I have no magic recipe that will let us arrive at this blissful state 
of affairs with none of the problems that we have experienced so far. I 
still hope that we can get a bit closer, though.

There is no way that an ABC standard can be enforced other than by 
`peer pressure'. However, for this it is necessary for the peers to 
agree exactly where the pressure should lead.

Anselm
-- 
Anselm Lingnau .. [EMAIL PROTECTED]
Nothing [...] will ever be attempted, if all possible objections must be first
overcome.-- The Artist, in _Rasselas_ by Samuel Johnson

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

Re: [abcusers] dynamics (was)

[Bryancreer]

Richard Robinson said -

>That was my intention, of course; to illustrate that talk of "outlawing" 
>_is_ a silly suggestion, no matter whose mouth it's put into. It is "a bit
>strong", yes.

When the abc sourcefourge project was set up last year, one of its first tasks was identified as sorting out the standard.  When the standards committee was set up in March, its website was set up under abc.sourceforge.net.  The existing and draft standards were loaded into sourceforge.  In a posting a few days ago, Laura Conrad spoke first of the difficulties of achieving agreement on a standard and then spoke of the sort of the sort of open-source project that she would like to see.  I took these as one topic reflecting more of the same association of standard and software project and used my now notorious "outlaw" reference.  She then said that she was simply making two separate points in the same email and I (if you recall) apologised.  I may have been a little premature in doing so as, since then, Richard Robinson and others have argued that the development of the abc standard should be associated with a software project.  I believe !
that this would be detrimental to the participation of the developers and users of other software implementations.  They would, to some extent, be excluded.  "Outlawed" is a rhetorical exageration but is not fundamentally wrong.

   Richard Robinson's speculations as to what I might say ran completely counter to what I was actually saying.  He first said that I would go on to explain that open-source was a bad form of development whereas I actually said that it was just one of several equally legitimate methods.

He  then went on to say -

>Or are you going to argue against anything any project that isn't in VB ?

No, because what I have been saying is that I don't believe that the abc standard should be associated with ANY software development so this suggestion is completely contrary to what I have been saying.

He now says -

>And, yes, a project in a language you don't know would be difficult for
>you to participate in.

Thank you.  If you'd said that a few days ago, it would have saved us a lot of trouble.

>If that is an argument that's worth your time to compose and post,

It is, because the same applies to a lot of other interested parties who either cannot or choose not to take part in an open-source project.

>why is so silly of me to inquire if it's an argument
>against anything in languages you don't use ? 

Because it shows that you haven't really been listening to what I've been saying.

>I can't promise that we will see eye to eye .

I don't expect us to, but can you at least make the effort to understand what I'm saying and address yourself to the points I'm making rather that your own speculations.  If I suggest A and you say "Oh well, I expect you think X" and then attack me on that basis it doen't get us anywhere and implies that you have no real objections to my original suggestion.

>> suggestions proper consideration, rather than opposing them on principle just 
>> because they come from me, and that you will restrict your reponses to what I 
>> actually say rather than your own wild speculations about things you think I 
>> might say (as you have done twice in this thread alone)?
>
>This looks to me like wild speculation on your part.

No.  It is direct experience of what is happening now and has happened a great deal in the past.  I have wasted a lot of time trying to get my point over to people who don't seem to have actually read what I said before firing off their response.


>What was the second point ?

In a triumph of hope over experience -

When Laura Conrad said -

>The discussion convinced everybody after a couple of
>months that there was no point in putting work into a standard in the
>present development environment.  Which I think means it was a
>productive discussion, which produced the right answer.

I think she was, in fact, right.  Talk of a standard is meaningless because nobody has the power to enforce it. Let us talk, instead, of a protocol for the exchange of information as I have suggested before.  Instead of fighting over the points we disagree on, let's start by establishing what we do agree on and let's do it on this list, not in secret conclave.

Bryan Creer

[abcusers] arrogant self-selected clique

[Bryancreer]

Frank Nordberg said -

>Richard Robinson wrote:
>
>> 
>> Particularly, the way that every
>> time a new poster appears here, they are informed that this is a no-good
>> bunch of people, an arrogant self-selected clique
>...
>
>Yep, that sounds like us ;-)

I've never thought that you (we?) were a no-good bunch of people.  Would I still be trying to debate with you if I thought that?  There are some very talented people on this list but conflicting egos seem to make them incapable of working together.  I'm afraid "self-selected clique" is simply a statement of fact.  "Arrogant"?  Well, I don't think I've ever actually said that but..  I recall that you, Frank, were invited to join the standards committee but declined, showing a praiseworthy, if misplaced, humility.  If there had to be a committee I think you should have been on it.

>Did Aaron ever get an answer to his dynamics question, btw?

I think he did actually.  Do you like my new thread subject?

Bryan Creer

Re: [abcusers] dynamics (was)

[James Allwright]

On Wed 31 Oct 2001 at 05:17AM -0500, [EMAIL PROTECTED] wrote:
> 
> There seems to be some confusion here.  Has the standards committee decided 
> anything or not?  Could we have a clear statement from the committee (rather 
> than individual members) on what it has achieved and its current status?
> 

I don't think you'll ever get the standards committee to speak as one
person with a unified voice. My opinion is similar to Phil's. I took
the approach of identifying all the new features in the new draft
standard and seeing which ones were universally approved and which
ones were not. This seemed like a good way to make progress, and I
got the impression that disagreement was restricted to relatively
minor features and obscure options of major features. However, the
thread petered out without any definite conclusions; people were
either not interested in this approach or distracted by other
projects.

It is still possible for someone who cares about an abc standard
to help the process along; get hold of every abc program you can,
go through them carefully and then document the compatibilities
and incompatibilities carefully on the web. If you do this
carefully and comprehensively enough it be a valuable resource to
guide any new abc developer on interpreting the more subtle aspects 
of abc.

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

Re: [abcusers] dynamics (was)

[Bryancreer]

Laurie Griffiths said -

>There was a move - and I was part of it - to try to make some sort of
>progress on the standard.  Part of the thinking was that the fewer people
>involved the quicker we might agree.  Part of the thinking was that if we
>enhanced the standard, even if we didn't do it the way some people would
>have liked, it would still be progress and still good for everyone because
>something is almost always better than nothing.

and Richard Robinson said-

>ABC is not perfect. A number of people have tried, and put work into, a
>number of approaches to improving things. A number of improvements have
>been made, even if not the ones that some people hoped for. 

whereas Laura Conrad  recently said -

>The discussion convinced everybody after a couple of
>months that there was no point in putting work into a standard in the
>present development environment.  Which I think means it was a
>productive discussion, which produced the right answer.

to which Phil Taylor responded -

>I have to dissent somewhat here.  I personally was not convinced that the
>task was pointless, and was quite prepared to continue.  As far as I remember,
>the discussion petered out without any decisions being taken, and I rather
>thought that it would be taken up again.

There seems to be some confusion here.  Has the standards committee decided anything or not?  Could we have a clear statement from the committee (rather than individual members) on what it has achieved and its current status?

Bryan Creer

Re: [abcusers] dynamics (was)

[Frank Nordberg]

Richard Robinson wrote:

...

> 
> Particularly, the way that every
> time a new poster appears here, they are informed that this is a no-good
> bunch of people, an arrogant self-selected clique
...

Yep, that sounds like us ;-)

Did Aaron ever get an answer to his dynamics question, btw?


Frank Nordberg
http://www.musicaviva.com


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