Re: [abcusers] reusable parser

[Christian M. Cepel]

Jack Campin wrote:

\[order fixed - please don't top-post]
Stephen Kellett wrote: Christian M. Cepel 
 

<[EMAIL PROTECTED]> writes
   

I would assume that such a beast would be written in straight ansi
c to make it available to any present  or future operating system
sporting a c compiler, as well as to make it as small and as resource 
non-intensive as possible.
 

C++ Surely? C is very restrictive in comparison. Writing object based 
code in C is hard work (read: un-necessary extra code, and lack of type 
safety) compared to C++.
   

Resource economy is a non-issue - it's not going to be that big and
by the time it's done, any computer that will use it will be much,
much bigger and faster than anything now running ABC software.
 

Java and C# are not worthwhile alternatives. Both quite restrictive 
because nothing is truly passed as a reference (try modifying a string 
object you pass in and see if it really was changed after the method 
call - if it was really passed as a reference it would be).  Makes
things trivial in C and C++ a real pain in Java and C#.
   

But, things relevant to this problem?

Sharing by reference is a great way to make code less maintainable,
and parsers don't need to do it, ever.
If they were easier to compile into libraries, SML, Haskell, Lisp
or Prolog would be better options - they all have a hell of a lot
of accumulated experience in use for parsing refractory syntaxes.
Is this a case of "if the only tool you have is a hammer, every
problem looks like a folk singer"?
-
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

 

I'm afraid you've lost me once again.  I suffer from small brain 
condition.  I'm not sure if you're for or against the idea of an open 
source shared parsing engine, and for it, what shape you suggest it take.

I also fail to see the concern with top posting, but then I spoze people 
must have their pet peeves.

--

 //Christian

Christian Marcus Cepel| And the wrens have returned &
[EMAIL PROTECTED] icq:12384980  | are nesting; In the hollow of
371 Crown Point, Columbia, MO | that oak where his heart once
65203-2202 573.999.2370   | had been; And he lifts up his
Computer Support Specialist, Sr.  | arms in a blessing; For being
University of Missouri - Columbia | born again.--Rich Mullins
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

[abcusers] reusable parser

[Jack Campin]

[order fixed - please don't top-post]
Stephen Kellett wrote: Christian M. Cepel 
> <[EMAIL PROTECTED]> writes
>> I would assume that such a beast would be written in straight ansi
>> c to make it available to any present  or future operating system
>> sporting a c compiler, as well as to make it as small and as resource 
>> non-intensive as possible.
> C++ Surely? C is very restrictive in comparison. Writing object based 
> code in C is hard work (read: un-necessary extra code, and lack of type 
> safety) compared to C++.

Resource economy is a non-issue - it's not going to be that big and
by the time it's done, any computer that will use it will be much,
much bigger and faster than anything now running ABC software.


> Java and C# are not worthwhile alternatives. Both quite restrictive 
> because nothing is truly passed as a reference (try modifying a string 
> object you pass in and see if it really was changed after the method 
> call - if it was really passed as a reference it would be).  Makes
> things trivial in C and C++ a real pain in Java and C#.

But, things relevant to this problem?

Sharing by reference is a great way to make code less maintainable,
and parsers don't need to do it, ever.

If they were easier to compile into libraries, SML, Haskell, Lisp
or Prolog would be better options - they all have a hell of a lot
of accumulated experience in use for parsing refractory syntaxes.

Is this a case of "if the only tool you have is a hammer, every
problem looks like a folk singer"?

-
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] !Current specification!

[Stephen Kellett]

C++ Surely? C is very restrictive in comparison. Writing object based 
code in C is hard work (read: un-necessary extra code, and lack of type 
safety) compared to C++.

Java and C# are not worthwhile alternatives. Both quite restrictive 
because nothing is truly passed as a reference (try modifying a string 
object you pass in and see if it really was changed after the method 
call - if it was really passed as a reference it would be). Makes things 
trivial in C and C++ a real pain in Java and C#.

Stephen

In message <[EMAIL PROTECTED]>, Christian M. Cepel 
<[EMAIL PROTECTED]> writes
I would assume that such a beast would be written in straight ansi c to 
make it available to any present  or future operating system sporting a 
c compiler, as well as to make it as small and as resource 
non-intensive as possible.
--
Stephen Kellett
Object Media Limitedhttp://www.objmedia.demon.co.uk
RSI Information:http://www.objmedia.demon.co.uk/rsi.html
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] !Current specification!

[John Kraybill]

I am also using VB at the moment.

John Kraybill

- Original Message -
From: "Neil Jennings" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, April 24, 2004 12:07 PM
Subject: Re: [abcusers] !Current specification!


> Sounds a great idea, but I would probably not be able to contribute, as I
am
> locked into VB.
> I presume any such parser would have to create the output as an object
> suitable for use by all the other programs.
> Design of this would be a major undertaking.
> Neil
>
>
> - Original Message -
> From: "Christian M. Cepel" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: 23 April 2004 20:34
> Subject: Re: [abcusers] !Current specification!
>
>
> > Might it not be interesting to start a project on Sourceforge with CVS
> > tracking for a centralized open source parser module or engine that can
> > be utilized by everyone?
> >
> > If the parser were being written in lockstep with the specification,
> > proper design might indeed be the result.  Kindof an evolution meets
> > extreme programming approach. (Not that I really ever understood Extreme
> > programming).
> >
> > Would anyone else be interested in such?
> >
> > Neil Jennings wrote:
> >
> > >The draft standard seems to contain many things which make life
difficult
> > >for parsers. A bit of proper design could have avoided this.
> > >I shoud throw my parser away and start again - but it would take some
> time!
> > >There is so much else to write without having to waste time reinventing
> > >wheels.
> > >
> > >- Original Message -
> > >From: "Christian M. Cepel" <[EMAIL PROTECTED]>
> > >To: <[EMAIL PROTECTED]>
> > >Sent: 23 April 2004 15:32
> > >Subject: Re: [abcusers] !Current specification!
> > >
> > >
> > >
> > >
> > >>I was thinking about this last night...and I don't see a problem with
> > >>parsing for a *x* token, a !x! token and ! at the end of a line, even
if
> > >>there are whitespace characters between ! and your EOL token.  A
> > >>backwards compatible, or version insensitive parser, which would be
the
> > >>kindest to your end user who may have grabbed a tune off the net, and
> > >>not even have looked at the abc, or know even how to edit the abc,
would
> > >>be the best option not insensitive about all things, but kind
enough
> > >>to recognize that !x! is valid 1.7.6 stuff and display it.  You could
> > >>even make your software encourage use of the newer constructs.
"Your
> > >>tune contains outdated notation that can easily be brought up to date
> > >>w/o changing the way it displays or sounds when played.  Would you
like
> > >>to update the notation? Y/N"   A bit Microsoft word-esk, but even so.
> > >>
> > >>Would this not be so?
> > >>
> > >>
> > >>Btw, abcmusicnotation.org and abcnotation.org should be well on their
> > >>way, propagating through dns servers and available to most.
> > >>
> > >>
> > >>David Webber wrote:
> > >>
> > >>
> > >>
> > >>>From: "Neil Jennings" <[EMAIL PROTECTED]>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > In 2.0, there is a %% directive in which the version is specified.
> > I would expect that this would be mandatory if the file is written
> > using  2.0 standard or later, otherwise
> > there wouldn't be much point in having it.
> > 
> > 
> > 
> > 
> > >>>Ok that helps.  But it still seems pretty silly making a new
> > >>>official standard (1.7.6) with !pp! while the draft 2.0 standard
> > >>>deprecates it in favour of using ! for something else and using
> > >>>+pp+.
> > >>>
> > >>>Dave
> > >>>David Webber
> > >>>Author MOZART the music processor for Windows -
> > >>>http://www.mozart.co.uk
> > >>>For discussion/support see
> > >>>http://www.mozart.co.uk/mzusers/mailinglist.htm
> > >>>
> > >>>To subscribe/unsubscribe, point your browser to:
> > >>>
> > >>>
> > >http://www.tullochgorm.com/lists.html
> > >
> > >
> > >>>
> > >>>
> > >>>
> > >>--
> > >>
> > >>  //Christian
> > >>
> > >>Christian Marcus Cepel| And the wrens have returned &
> > >>[EMAIL PROTECTED] icq:12384980  | are nesting; In the hollow of
> > >>371 Crown Point, Columbia, MO | that oak where his heart once
> > >>65203-2202 573.999.2370   | had been; And he lifts up his
> > >>Computer Support Specialist, Sr.  | arms in a blessing; For being
> > >>University of Missouri - Columbia | born again.--Rich Mullins
> > >>
> > >>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
> > >
> > >
> > >
> >
> >
> > --
> >
> >   //Christian
> >
> > Christian Marcus Cepel| And the wrens have returned &
> > [EMAIL PROTECTED] icq:12384980  | are nesting; In the hollow of
> > 371 Crown Point, Columbia, MO | that oak where his heart once
> > 65203-2202 573.999.2370   | had been; And he lifts up his
> > Computer Support Specialist, Sr.  | arms in a blessing; For being
> > Un

Re: [abcusers] !Current specification!

[John Kraybill]

I agree with Dave here. Change the 1.7.6 spec to agree with the 2.0 spec by
changing the ! characters to + characters. We should do that immediately
before any more non-backwards compatible ABC files are created.

...And while we're changing it we should add the +mp+ and +fp+ to the 1.7.6
spec and I suggest adding the +fp+ to the 2.0 spec.

Thanks all!
John Kraybill

- Original Message -
From: "David Webber" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, April 24, 2004 10:21 AM
Subject: Re: [abcusers] !Current specification!


>
> From: "Jack Campin" <[EMAIL PROTECTED]>
>
> > The point of having ! in the middle of a line is that that's the
> ONLY
> > place where it can have a positive effect on readability.  Having
> it at
> > the end of a line is the ONLY place where it has a consistently
> negative
> > effect on it (since it's redundant there).
>
> Thanks.  That was my understanding.
>
> If this is so popular, then perhaps !pp! etc should be changed to
> +pp+ in the 1.76 spec, to make it agree with the 2.0 spec (in which
> I assume all the reasons discussed led to this definition).
>
> Dave
> David Webber
> Author MOZART the music processor for Windows -
> http://www.mozart.co.uk
> For discussion/support see
> http://www.mozart.co.uk/mzusers/mailinglist.htm
>
> 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] !Current specification!

[Christian M. Cepel]

I'm not the person to lead such an endeavor, but I'd love to be a part 
of it and work on it.

I would assume that such a beast would be written in straight ansi c to 
make it available to any present  or future operating system sporting a 
c compiler, as well as to make it as small and as resource non-intensive 
as possible.

The most important aspect of the project would be documentation.  It 
would require a very clear, useful, and functional API... I think.

Any volunteers with the requisite skills?

Neil Jennings wrote:

Sounds a great idea, but I would probably not be able to contribute, as I am
locked into VB.
I presume any such parser would have to create the output as an object
suitable for use by all the other programs.
Design of this would be a major undertaking.
Neil
- Original Message -
From: "Christian M. Cepel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: 23 April 2004 20:34
Subject: Re: [abcusers] !Current specification!
 

Might it not be interesting to start a project on Sourceforge with CVS
tracking for a centralized open source parser module or engine that can
be utilized by everyone?
If the parser were being written in lockstep with the specification,
proper design might indeed be the result.  Kindof an evolution meets
extreme programming approach. (Not that I really ever understood Extreme
programming).
Would anyone else be interested in such?

Neil Jennings wrote:

   

The draft standard seems to contain many things which make life difficult
for parsers. A bit of proper design could have avoided this.
I shoud throw my parser away and start again - but it would take some
 

time!
 

There is so much else to write without having to waste time reinventing
wheels.
- Original Message -
From: "Christian M. Cepel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: 23 April 2004 15:32
Subject: Re: [abcusers] !Current specification!


 

I was thinking about this last night...and I don't see a problem with
parsing for a *x* token, a !x! token and ! at the end of a line, even if
there are whitespace characters between ! and your EOL token.  A
backwards compatible, or version insensitive parser, which would be the
kindest to your end user who may have grabbed a tune off the net, and
not even have looked at the abc, or know even how to edit the abc, would
be the best option not insensitive about all things, but kind enough
to recognize that !x! is valid 1.7.6 stuff and display it.  You could
even make your software encourage use of the newer constructs."Your
tune contains outdated notation that can easily be brought up to date
w/o changing the way it displays or sounds when played.  Would you like
to update the notation? Y/N"   A bit Microsoft word-esk, but even so.
Would this not be so?

Btw, abcmusicnotation.org and abcnotation.org should be well on their
way, propagating through dns servers and available to most.
David Webber wrote:



   

From: "Neil Jennings" <[EMAIL PROTECTED]>





 

In 2.0, there is a %% directive in which the version is specified.
I would expect that this would be mandatory if the file is written
using  2.0 standard or later, otherwise
there wouldn't be much point in having it.


   

Ok that helps.  But it still seems pretty silly making a new
official standard (1.7.6) with !pp! while the draft 2.0 standard
deprecates it in favour of using ! for something else and using
+pp+.
Dave
David Webber
Author MOZART the music processor for Windows -
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
To subscribe/unsubscribe, point your browser to:

 

http://www.tullochgorm.com/lists.html

 

 

--

//Christian

Christian Marcus Cepel| And the wrens have returned &
[EMAIL PROTECTED] icq:12384980  | are nesting; In the hollow of
371 Crown Point, Columbia, MO | that oak where his heart once
65203-2202 573.999.2370   | had been; And he lifts up his
Computer Support Specialist, Sr.  | arms in a blessing; For being
University of Missouri - Columbia | born again.--Rich Mullins
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
 

 

--

 //Christian

Christian Marcus Cepel| And the wrens have returned &
[EMAIL PROTECTED] icq:12384980  | are nesting; In the hollow of
371 Crown Point, Columbia, MO | that oak where his heart once
65203-2202 573.999.2370   | had been; And he lifts up his
Computer Support Specialist, Sr.  | arms in a blessing; For being
University of Missouri - Columbia | born again.--Rich Mullins
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

 



--

 //Christian

Christian Marcus Cepel| And the wrens hav

Re: [abcusers] !Current specification!

[Christian M. Cepel]

Thank you Jack.  I've a better understanding now.

And David...   That just couldn't work.  It's far too simple, and just 
makes too much sense :)

How 'unofficially official' is the 1.7.6 standard?  Is it still open for 
change, or could there be an intermediate between it and 2.0?  I've 
never understood the versioning system used for abc. 

I think, despite reading quite a bit, there are still quite a few things 
I do not understand.

//Christian

David Webber wrote:

From: "Jack Campin" <[EMAIL PROTECTED]>

 

The point of having ! in the middle of a line is that that's the
   

ONLY
 

place where it can have a positive effect on readability.  Having
   

it at
 

the end of a line is the ONLY place where it has a consistently
   

negative
 

effect on it (since it's redundant there).
   

Thanks.  That was my understanding.

If this is so popular, then perhaps !pp! etc should be changed to
+pp+ in the 1.76 spec, to make it agree with the 2.0 spec (in which
I assume all the reasons discussed led to this definition).
Dave
David Webber
Author MOZART the music processor for Windows -
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

 



--

 //Christian

Christian Marcus Cepel| And the wrens have returned &
[EMAIL PROTECTED] icq:12384980  | are nesting; In the hollow of
371 Crown Point, Columbia, MO | that oak where his heart once
65203-2202 573.999.2370   | had been; And he lifts up his
Computer Support Specialist, Sr.  | arms in a blessing; For being
University of Missouri - Columbia | born again.--Rich Mullins
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] !Current specification!

[Neil Jennings]

Sounds a great idea, but I would probably not be able to contribute, as I am
locked into VB.
I presume any such parser would have to create the output as an object
suitable for use by all the other programs.
Design of this would be a major undertaking.
Neil


- Original Message -
From: "Christian M. Cepel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: 23 April 2004 20:34
Subject: Re: [abcusers] !Current specification!


> Might it not be interesting to start a project on Sourceforge with CVS
> tracking for a centralized open source parser module or engine that can
> be utilized by everyone?
>
> If the parser were being written in lockstep with the specification,
> proper design might indeed be the result.  Kindof an evolution meets
> extreme programming approach. (Not that I really ever understood Extreme
> programming).
>
> Would anyone else be interested in such?
>
> Neil Jennings wrote:
>
> >The draft standard seems to contain many things which make life difficult
> >for parsers. A bit of proper design could have avoided this.
> >I shoud throw my parser away and start again - but it would take some
time!
> >There is so much else to write without having to waste time reinventing
> >wheels.
> >
> >- Original Message -
> >From: "Christian M. Cepel" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: 23 April 2004 15:32
> >Subject: Re: [abcusers] !Current specification!
> >
> >
> >
> >
> >>I was thinking about this last night...and I don't see a problem with
> >>parsing for a *x* token, a !x! token and ! at the end of a line, even if
> >>there are whitespace characters between ! and your EOL token.  A
> >>backwards compatible, or version insensitive parser, which would be the
> >>kindest to your end user who may have grabbed a tune off the net, and
> >>not even have looked at the abc, or know even how to edit the abc, would
> >>be the best option not insensitive about all things, but kind enough
> >>to recognize that !x! is valid 1.7.6 stuff and display it.  You could
> >>even make your software encourage use of the newer constructs."Your
> >>tune contains outdated notation that can easily be brought up to date
> >>w/o changing the way it displays or sounds when played.  Would you like
> >>to update the notation? Y/N"   A bit Microsoft word-esk, but even so.
> >>
> >>Would this not be so?
> >>
> >>
> >>Btw, abcmusicnotation.org and abcnotation.org should be well on their
> >>way, propagating through dns servers and available to most.
> >>
> >>
> >>David Webber wrote:
> >>
> >>
> >>
> >>>From: "Neil Jennings" <[EMAIL PROTECTED]>
> >>>
> >>>
> >>>
> >>>
> >>>
> In 2.0, there is a %% directive in which the version is specified.
> I would expect that this would be mandatory if the file is written
> using  2.0 standard or later, otherwise
> there wouldn't be much point in having it.
> 
> 
> 
> 
> >>>Ok that helps.  But it still seems pretty silly making a new
> >>>official standard (1.7.6) with !pp! while the draft 2.0 standard
> >>>deprecates it in favour of using ! for something else and using
> >>>+pp+.
> >>>
> >>>Dave
> >>>David Webber
> >>>Author MOZART the music processor for Windows -
> >>>http://www.mozart.co.uk
> >>>For discussion/support see
> >>>http://www.mozart.co.uk/mzusers/mailinglist.htm
> >>>
> >>>To subscribe/unsubscribe, point your browser to:
> >>>
> >>>
> >http://www.tullochgorm.com/lists.html
> >
> >
> >>>
> >>>
> >>>
> >>--
> >>
> >>  //Christian
> >>
> >>Christian Marcus Cepel| And the wrens have returned &
> >>[EMAIL PROTECTED] icq:12384980  | are nesting; In the hollow of
> >>371 Crown Point, Columbia, MO | that oak where his heart once
> >>65203-2202 573.999.2370   | had been; And he lifts up his
> >>Computer Support Specialist, Sr.  | arms in a blessing; For being
> >>University of Missouri - Columbia | born again.--Rich Mullins
> >>
> >>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
> >
> >
> >
>
>
> --
>
>   //Christian
>
> Christian Marcus Cepel| And the wrens have returned &
> [EMAIL PROTECTED] icq:12384980  | are nesting; In the hollow of
> 371 Crown Point, Columbia, MO | that oak where his heart once
> 65203-2202 573.999.2370   | had been; And he lifts up his
> Computer Support Specialist, Sr.  | arms in a blessing; For being
> University of Missouri - Columbia | born again.--Rich Mullins
>
> 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] !Current specification!

[David Webber]

From: "Jack Campin" <[EMAIL PROTECTED]>

> The point of having ! in the middle of a line is that that's the
ONLY
> place where it can have a positive effect on readability.  Having
it at
> the end of a line is the ONLY place where it has a consistently
negative
> effect on it (since it's redundant there).

Thanks.  That was my understanding.

If this is so popular, then perhaps !pp! etc should be changed to
+pp+ in the 1.76 spec, to make it agree with the 2.0 spec (in which
I assume all the reasons discussed led to this definition).

Dave
David Webber
Author MOZART the music processor for Windows -
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm

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

Re: [abcusers] !Current specification!

[Jack Campin]

>> I was under the understanding that since Jim Vint introduced
>> the ! token  in Abc2Win and that it was only valid as a final
>> character (excluding whitespace characters) before EOL.
> No, you can find it anywhere in ABC2WIN-created files.

What I should have added: particularly in those files created by
experienced users.  Newcomers to a formal notation often invent
syntactic restrictions that aren't really there.


>> As the adoption was grudging, I thought it was insistent that it NOT be 
>> inline, but only at the end of a line where it does not really affect 
>> reading.

That's completely backwards.

The point of having ! in the middle of a line is that that's the ONLY
place where it can have a positive effect on readability.  Having it at
the end of a line is the ONLY place where it has a consistently negative
effect on it (since it's redundant there).

I argued that ! should coexist with -as-staffbreak, just to
avoid cluttering the ends of lines up with unnecessary ! signs - BarFly
hasn't implemented that, but in practice the number of \ escapes you'd
need if you had both would be not far short of the number of end-of-line
!s you need with its present setup, so it's no big deal.

-
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] !Current specification!

[Jack Campin]

> I was under the understanding that since Jim Vint introduced
> the ! token  in Abc2Win and that it was only valid as a final
> character (excluding whitespace characters) before EOL.

No, you can find it anywhere in ABC2WIN-created files.


> I had assumed that it had been grudgingly adopted as such in the
> standard.  Grudgingly because it started appearing everywhere in
> abc files, because people liked it,

No.  I've been arguing for it for a VERY long time, though I've never
used ABC2WIN and, given the sort of coding it seems to encourage,
never intend to (nor, I think, have I ever used an ABC2WIN-created file
without heavy manual editing to make it human-readable).  This is the
sort of use I make of it:

X:0074
T:Duncan's Dance.
M:6/8
L:1/8
Q:3/8=120
I: || ||
%% D E ^F G A B c d e ^f g a
K:G
Bcd g3 | Bcd g3 | Bcd efg|aAA A2z|
Bcd g3 |!Bcd g3 | dcB ABc|BGG G3||
BAB GEE| GEE E3 |!BAB GEE|FDD D3 |
BAB GEE| FAG FED| g3  dAc|BGG G3|]

The point is that the tune needs three staff lines to display well on
my setup, there are always going to be situations where it requires
human intervention to get the linebreaks in the right places, and
despite what you say here...

> ABC notation is not supposed to be a print description with formatting
> inline, but simply an absolutely parsimonious description of the music
> with any print/render directives to be included in comments, and not
> disrupting the readability abc by being inline.

that has NEVER described the way ABC handles staff breaks.  The 1.6
standard has an explicit, non-comment construct for them: 
generates a staffbreak unless preceded by a \ escape.  The problem
that creates is a conflict with readable source.  The way I tried
to resolve the conflict before BarFly started to support ! was to
write this:

Bcd g3 |Bcd g3 |Bcd efg|aAA A2z|\
Bcd g3 |
Bcd g3 |dcB ABc|BGG G3||\
BAB GEE|GEE E3 |
BAB GEE|FDD D3 |\
BAB GEE|FAG FED|g3  dAc|BGG G3|]

which is not too bad on a tiny example like this, but with a big
complicated 18th century slow air (the sort of tune where explicit
control of stafflinebreaks is most necessary and where alignment
of parallel phrases makes an enormous difference to accuracy of
transcription) it gets to look like an appalling mess.

-
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