Re: [abcusers] !Current specification!

[Stephen Kellett]

In message <[EMAIL PROTECTED]>, Steven Bennett 
<[EMAIL PROTECTED]> writes


Thats really distressing. I no longer have a valid reason to dislike 
Macs :-) They fixed the two things I really hated. Gnash.

Stephen
--
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!

[Stephen Kellett]

In message <[EMAIL PROTECTED]>, Jack Campin 
<[EMAIL PROTECTED]> writes
till they get the message.  (Quick, how *do* you remap the mouse
buttons to use a mouse left-handed for the duration of a catalog
search session on a Windows-based library computer where you have
no admin privileges?)
No idea. I'm right handed. I use a mouse with my left hand and I don't 
want the buttons remapped. Its not a big deal. The left most button is 
for clicking and the right button is for the context menu.

When I use a mouse with my right hand (on everyone else's computer) I 
expect the buttons to still be left for clicking, etc.

The latter is the reason all mice should have a minimum of two buttons.
Stephen
--
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!

[Jack Campin]

>> Thats one of my two dislikes of Macs done away with. The other one is
>> the menuing system. Click and hold is bad for anyone with WRULD / RSI.
>> The Windows Click, release, mouse/key around as you please then click
>> when you are ready is good for RSI. Can you configure the Mac to have
>> menus that are good for you rather than bad for you?
> Again, an old issue, long since fixed in Mac OS X -- you can click and
> release on the menu bar and the menu will stay popped up until you select
> from it.  (And you can click and drag as well...  Or click and release
> then use arrow keys.)  Older Mac systems had it too, called Sticky Menus
> (I forget if this appeared originally in Mac OS 8 or 9), and again, third
> parties have had this fixed for ages.

There was something built-in to the OS that gave you the option
of click-and-stay-dropped ("sticky") menus back as far as OS 7.6,
I think.  It's certainly there in OS 8.1.

I generally find sticky menus slightly annoying but not annoying enough
to turn them off.

The first mouse - actually bitpad puck - I used had four buttons.
I don't miss the other three, and anybody who puts an asymmetric
two-button mice on a public computer with no instructions on how
to remap the buttons needs to have one hand superglued to their bum
till they get the message.  (Quick, how *do* you remap the mouse
buttons to use a mouse left-handed for the duration of a catalog
search session on a Windows-based library computer where you have
no admin privileges?)


-
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!

[Steven Bennett]

> In message <[EMAIL PROTECTED]>, Steven Bennett
> <[EMAIL PROTECTED]> writes
>> You know, it's amazing that people still have this silly impression that
>> just because Apple only ships a mouse with one button, that the OS can only
> 
> You learn something every day :-) I don't know that its a silly
> impression - blame Apple's marketeers and Steve Jobs' reality distortion
> field :-). I know some die hard Mac fans (one even owns a Lisa as well
> as various Macs as part of his collection) and they haven't told me
> this. Have all Macs been able to have multi-mouse buttons or only the
> recent OS-X boxes?

Mac OS X supports the right mouse button and scroll wheel natively pretty
much everywhere, and applications may make use of additional buttons,
although Apple software itself didn't have any use for them until Mac OS X
10.3.  The right mouse button, as with windows, brings up a contextual menu.

Mac OS 9 had support for the right button to pop up the contextual menu.  I
*think* it supported right buttons natively on USB mice, but can't be sure -
definitely if you had a driver to generate the right event from the device,
it would work, though.

Third party mouse drivers have had support for extra buttons on the Mac
since the late 1980s.  Mostly things like doing double clicks and
click-locks, although they also allowed programming buttons to do all kinds
of wild and crazy things.


> Thats one of my two dislikes of Macs done away with. The other one is
> the menuing system. Click and hold is bad for anyone with WRULD / RSI.
> The Windows Click, release, mouse/key around as you please then click
> when you are ready is good for RSI. Can you configure the Mac to have
> menus that are good for you rather than bad for you?

Again, an old issue, long since fixed in Mac OS X -- you can click and
release on the menu bar and the menu will stay popped up until you select
from it.  (And you can click and drag as well...  Or click and release then
use arrow keys.)  Older Mac systems had it too, called Sticky Menus (I
forget if this appeared originally in Mac OS 8 or 9), and again, third
parties have had this fixed for ages.


>> Amigas -- 4000/2000/1000, 2 C-64s, a TI-99/4A, and a SWTPC 6800 that are all
> 
> TI-99/4A, now that is going back a long way. 16 bit, but registers in
> RAM, not on the CPU, weird beast. Never got to use one. Amiga - no
> budget, I had to settle for an Atari ST :-) Bizzarely enough they are
> still trying to resurrect Amiga (gets mentioned on Slashdot from time to
> time).

I know.  Alas, too little and way too late...

-->Steve Bennett

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

Re: [abcusers] !Current specification!

[John Chambers]

Steven Bennett writes:
| You know, it's amazing that people still have this silly impression that
| just because Apple only ships a mouse with one button, that the OS can only
| use one button, something which hasn't been true for many years.   I've been
| using multi-button mice on Macs since the late 80s.  My main mouse (actually
| a trackball) has 4 buttons plus a scroll wheel.  *All* of them are useful
| out of the box with the OS.  With the driver software installed, they're
| even more useful.

My wife likes to tell people about the 16-button mice she  used  back
when she was still doing Civil Engineering work.  Those mice also had
a small reticle on the front, for  help  in  digitizing  maps.   They
worked  fine on both Apple and Microsoft systems.  Of course, most of
the software didn't have anything bound to most of the buttons.   But
any CAD software knows how to use them.  It can be really handy to be
able to map an arbitrary command to a button.

It is a bit odd that Apple still prefers one-button mice. You'd think
that 3 would be a minimum, considering the nature of the human hand.

Of course, as musicians, it would also be handy if we could  plug  in
keyboards  designed to mimic our favorite instruments.  There are USB
piano-style keyboards, of course, but I haven't  yet  seen  one  that
looks and acts like a fiddle fingerboard.




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

Re: [abcusers] !Current specification!

[Stephen Kellett]

In message <[EMAIL PROTECTED]>, Steven Bennett 
<[EMAIL PROTECTED]> writes
You know, it's amazing that people still have this silly impression that
just because Apple only ships a mouse with one button, that the OS can only
You learn something every day :-) I don't know that its a silly 
impression - blame Apple's marketeers and Steve Jobs' reality distortion 
field :-). I know some die hard Mac fans (one even owns a Lisa as well 
as various Macs as part of his collection) and they haven't told me 
this. Have all Macs been able to have multi-mouse buttons or only the 
recent OS-X boxes?

Thats one of my two dislikes of Macs done away with. The other one is 
the menuing system. Click and hold is bad for anyone with WRULD / RSI. 
The Windows Click, release, mouse/key around as you please then click 
when you are ready is good for RSI. Can you configure the Mac to have 
menus that are good for you rather than bad for you?

Amigas -- 4000/2000/1000, 2 C-64s, a TI-99/4A, and a SWTPC 6800 that are all
TI-99/4A, now that is going back a long way. 16 bit, but registers in 
RAM, not on the CPU, weird beast. Never got to use one. Amiga - no 
budget, I had to settle for an Atari ST :-) Bizzarely enough they are 
still trying to resurrect Amiga (gets mentioned on Slashdot from time to 
time).

Stephen
--
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!

[Steven Bennett]

> In message <[EMAIL PROTECTED]>, Steven Bennett
> <[EMAIL PROTECTED]> writes
>> Actually, I use Objective C when programming on a Mac.
> 
> That explains my lack of awareness then. I don't use Macs and generally
> don't like them either. Windows or Unix fine, but don't make me use a
> computer with one mouse button.

You know, it's amazing that people still have this silly impression that
just because Apple only ships a mouse with one button, that the OS can only
use one button, something which hasn't been true for many years.   I've been
using multi-button mice on Macs since the late 80s.  My main mouse (actually
a trackball) has 4 buttons plus a scroll wheel.  *All* of them are useful
out of the box with the OS.  With the driver software installed, they're
even more useful.

I program and use Windows (98/ME/2K/XP) and Mac OS X for work, and at home I
have Windows 2K, Mac OS X, and Linux machines.  (Okay, that's only the
actively used machines -- I also have a Windows 98 box, a Win95 box, three
Amigas -- 4000/2000/1000, 2 C-64s, a TI-99/4A, and a SWTPC 6800 that are all
mostly retired...)

The Mac OS X machines are by far my favorites of the lot.

-->Steve Bennett

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

Re: [abcusers] !Current specification!

[Stephen Kellett]

In message <[EMAIL PROTECTED]>, Steven Bennett 
<[EMAIL PROTECTED]> writes
Actually, I use Objective C when programming on a Mac.
That explains my lack of awareness then. I don't use Macs and generally 
don't like them either. Windows or Unix fine, but don't make me use a 
computer with one mouse button.

Yes, GCC can compile Objective C.  (And Objective C++, as well)
Excellent.
portable.  If you're using the windowing/graphics system, it's probably 95%
Shouldn't be an issue. The parser won't be touching those.
9x/ME -- Gnu), but as I said, it's intended as a reference work - to show
*how* to parse ABC in a clearly understandable fashion.  I hope people will
Sure, but I think many would want to compile it and possibly step 
through bits in the debugger, or test their ideas on your reference 
before wading in for a full implementation elsewhere. Hence my interest 
in the compilers.

Stephen
--
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!

[Steven Bennett]

> In message <[EMAIL PROTECTED]>, Steven Bennett
> <[EMAIL PROTECTED]> writes
>> That it's written in Objective C should be fairly irrelevant, BTW -- it's
>> almost trivial to pick up and understand the Objective C extensions to
>> ANSI-C, and the resulting code is much easier both to write and read than
>> either C or C++ would be.  IMHO.
> 
> You must be a rarity. Objective C. I've yet to actually meet anyone
> thats used this language. Objective C, from what I've read is VHS's
> Betamax. Better, but didn't succeed in the marketplace.

Actually, I use Objective C when programming on a Mac.  Because of the Cocoa
framework there, it's *very* popular amongst Mac programmers, and is hands
down the best programming choice for Mac applications.

> Relevant or irrelevant, that is the #pragma? Its only irrelevant if
> there are compiler implementations that all contributors can use on the
> various platforms people want. Is there a GNU Objective C or equivalent?
>
> Don't take this an attack on your work or use of Objective C. Its not,
> I'm just unaware of any Objective C compilers people can use without
> having to buy yet another tool (something I can't see people doing when
> contributing to a free project). Of course, if you can show me I'm
> wrong, that'll be fine.

Yes, GCC can compile Objective C.  (And Objective C++, as well)  In fact,
GCC is the compiler used in the Apple provided developer tools on Mac OS X.
You do, however, need to have some libraries, however, to do nearly
anything.  (Much like you'd want the standard C libraries for C, or STL for
C++...)

Fortunately, there's also an open source implementation of much of the Mac
OS X Cocoa libraries called GNUStep which lets you write to those libraries
on Linux, UNIX, BSD, and to some extent, Windows 2000/XP based systems.  If
you're not using the windowing/graphics system, it should be entirely
portable.  If you're using the windowing/graphics system, it's probably 95%
portable to Linux, and about 85% portable to Windows.

My parser will be using the non-graphic parts of Cocoa & GNUStep, so it
should be highly portable.

The printing code I'm writing, on the other hand, will necessarily use
graphics, but I'm hoping it will work on most (and maybe all) systems.  On
the Mac, at least, it will output PDF natively - I'm not sure on the other
platforms what the output will be yet.

> Assuming there are Objective C compilers around that people can use that
> brings up the question of language binding. How straightforward is it to
> produce a C/C++ callable API for your Objective C created code? (If you
> can do it for C/C++ we can sort out the Java/.net/Delphi/Python etc
> straightforwardly).

Objective C libraries are effectively the same as C libraries.  Not too
surprising since Objective C is mainly turned into C during preprocessing.
With a tiny bit of glue, you should be callable from nearly anything.  I
plan to write that glue and sample code from C and C++ on several platforms.

Not that being a plug-in parser was a design goal.  It should certainly be
usable that way (for nearly any currently popular environment except Windows
9x/ME -- Gnu), but as I said, it's intended as a reference work - to show
*how* to parse ABC in a clearly understandable fashion.  I hope people will
look at it at some point, not so much to use it intact (it is, after all,
not going to be efficient by it's nature), but as a guide to how to write
their own parser to fit *their* needs.  Which are no doubt different than
mine.

-->Steve Bennett

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

Re: [abcusers] !Current specification!

[Stephen Kellett]

In message <[EMAIL PROTECTED]>, Steven Bennett 
<[EMAIL PROTECTED]> writes
That it's written in Objective C should be fairly irrelevant, BTW -- it's
almost trivial to pick up and understand the Objective C extensions to
ANSI-C, and the resulting code is much easier both to write and read than
either C or C++ would be.  IMHO.
You must be a rarity. Objective C. I've yet to actually meet anyone 
thats used this language. Objective C, from what I've read is VHS's 
Betamax. Better, but didn't succeed in the marketplace.

Relevant or irrelevant, that is the #pragma? Its only irrelevant if 
there are compiler implementations that all contributors can use on the 
various platforms people want. Is there a GNU Objective C or equivalent?

Don't take this an attack on your work or use of Objective C. Its not, 
I'm just unaware of any Objective C compilers people can use without 
having to buy yet another tool (something I can't see people doing when 
contributing to a free project). Of course, if you can show me I'm 
wrong, that'll be fine.

Assuming there are Objective C compilers around that people can use that 
brings up the question of language binding. How straightforward is it to 
produce a C/C++ callable API for your Objective C created code? (If you 
can do it for C/C++ we can sort out the Java/.net/Delphi/Python etc 
straightforwardly).

Stephen
--
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!

[Steven Bennett]

> Why only writing a parser for one language (either C, C++, C# or Java)?
> Surely it should be possible to generate a parser for any language from
> a BNF grammar specification using a parser generator like SLK?
> Incidentally, SLK is available for both Win32 as Linux.

If ABC could be specified strictly as a BNF grammar, then I'd agree with
you.  Alas, there are so many exceptions and special cases (even in 2.0...)
that I doubt there will ever be a totally complete and accurate BNF grammar
for it.  (Although Henrik Norbeck has done a very good job of approaching
something relatively close to it...)

That said, the parser I've been working on for the last few months has a
high priority design goal of being usable as a reference work in the way
described.  I should warn you, however, that I quickly discovered that
usefulness as a reference work is pretty much diametrically opposed to speed
and efficiency in the code -- this thing is going to run slow and use a lot
of memory when it's done.  (Who knows when? ;)  But pretty much anyone
looking at the code should be able to easily see not only *how* it parses
ABC, but *why* it is done in a given way.  (And it will be commented *very*
thoroughly...)

That it's written in Objective C should be fairly irrelevant, BTW -- it's
almost trivial to pick up and understand the Objective C extensions to
ANSI-C, and the resulting code is much easier both to write and read than
either C or C++ would be.  IMHO.

-->Steve Bennett

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

Re: [abcusers] !Current specification!

[Christian M. Cepel]

Richard Robinson wrote:
On Sun, Apr 25, 2004 at 09:41:27PM +0100, Neil Jennings wrote:
 

Rubbish. To be useful, the parser should be a procedure with an API which
can be called from a standard
executable program. If you produce an acsii file, you have just replaced one
problem with another.
   

Well; if someone wants to wrap the parser with something to produce
XML-ish output, that's not a problem. So long as the parser API is
clear, and properly separated from the output-generating code.
 

I had more pictured a Java-esq api than a parser that writes out 
something that would itself have to be parsed...

I call a function in the parser with some bit of abc, and depending on 
what I asked it to do (which function I called), it returns some 
'expected' output.  At the same time, there would be methods I could 
call on the object, and in an exception handler to see if there were 
additional useful bits of information, or errors that I can choose to 
ignore, or try to make some use of.

For this reason, multi threading would be a must, and having the parser 
not exit after each query (like someone was suggesting with a 
STDIN=>STDOUT command line program).  It  would need to stay loaded with 
the state of the last query (or possibly every query until a command to 
end the session (and dump the state)) available for reference.  

For instance, perhaps I want to ram a bit of ABC through the parser in 
my program and display the output errors and all.  It would be enough 
that the parsed information was returned for me to display, and a simple 
error flag.  If I don't want to tell the end user that there's x, x, and 
x wrong with their abc, then there's no reason for the added overhead of 
the parser sending that information back to me to dump or display.   
Perhaps I could do something like Phil's Smiley face in in BarFly in my 
software to let the user know that the error flag was returned...  Then 
if the user commands the program to tell them what the parser was 
unhappy with, my program can then query the errors from the last session 
and my program can display that information. 

--
 //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!

[Richard Robinson]

On Sun, Apr 25, 2004 at 09:41:27PM +0100, Neil Jennings wrote:
> Rubbish. To be useful, the parser should be a procedure with an API which
> can be called from a standard
> executable program. If you produce an acsii file, you have just replaced one
> problem with another.

Well; if someone wants to wrap the parser with something to produce
XML-ish output, that's not a problem. So long as the parser API is
clear, and properly separated from the output-generating code.

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

[Neil Jennings]

Rubbish. To be useful, the parser should be a procedure with an API which
can be called from a standard
executable program. If you produce an acsii file, you have just replaced one
problem with another.


- Original Message -
From: "Bernard Hill" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: 25 April 2004 13:29
Subject: Re: [abcusers] !Current specification!


> In message <[EMAIL PROTECTED]>, Stephen Kellett
> <[EMAIL PROTECTED]> writes
> >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 my opinion any parser should produce ascii code and be
> self-contained, written as a command-line procedure using stdin and
> stdout
>
> abcparse outputfilename
>
>
> The structure of the outputfile would probably obey some sort of XML
> language (although I hate it).
>
> --
> Bernard Hill
> Braeburn Software
> Author of Music Publisher system
> Music Software written by musicians for musicians
> http://www.braeburn.co.uk
> Selkirk, Scotland
>
> To subscribe/unsubscribe, point your browser to:
http://www.tullochgorm.com/lists.html

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

Re: [abcusers] !Current specification!

[Bernard Hill]

In message <[EMAIL PROTECTED]>, Stephen Kellett 
<[EMAIL PROTECTED]> writes
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 my opinion any parser should produce ascii code and be 
self-contained, written as a command-line procedure using stdin and 
stdout

abcparse outputfilename

The structure of the outputfile would probably obey some sort of XML 
language (although I hate it).

--
Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] !Current specification!

[Bert Van Vreckem]

Christian M. Cepel wrote:
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?
Hear, hear. Whoever's interested is free to use the facilities of the 
abc.sf.net project. Send me your SourceForge user name and I make you a 
project member and even admin if you want.

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++.
Why only writing a parser for one language (either C, C++, C# or Java)? 
Surely it should be possible to generate a parser for any language from 
a BNF grammar specification using a parser generator like SLK? 
Incidentally, SLK is available for both Win32 as Linux.

> 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#.
Java Strings are immutable objects. This allows for some optimisations, 
but it has its consequences. In general, primitive types are passed by 
value, while objects (including arrays) are passed by reference. But a 
String object can't be changed, so, indeed, what you describe here will 
not work...

Cheers,

bert
--
Bert Van Vreckem  
Te audire non possum. Musa sapientum fixa est in aure.
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
> > >

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.tu

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

Re: [abcusers] !Current specification!

[Bernard Hill]

In message <[EMAIL PROTECTED]>, Neil Jennings 
<[EMAIL PROTECTED]> writes
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.
Hear hear on all points!
--
Bernard Hill
Braeburn Software
Author of Music Publisher system
Music Software written by musicians for musicians
http://www.braeburn.co.uk
Selkirk, Scotland
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] !Current specification!

[Christian M. Cepel]

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

Re: [abcusers] !Current specification!

[Neil Jennings]

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

Re: [abcusers] !Current specification!

[Christian M. Cepel]

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.  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, and 
it was hit and miss with software implementation as developers started 
supporting it, and also grudgingly because 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. 

(Kindof like the Netscape/IE browser wars and the w3c's grudgingly 
including features one or the other browser has forced in and proven to 
be successful and desired by the web community)

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.

I guess I need to go back and re-read the standard.  I've not deeply 
looked at it since my development project 2-3 yrs ago.

Thanks

//Christian

David Webber wrote:

From: "Christian M. Cepel" <[EMAIL PROTECTED]>

 

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,
   

It wouldn't be at the end of a line - it would be in the middle
indicating that the music should be drawn with a line break there.
And so there could be more than one.
So  ..!ff!..

coud be fortissimo.  Or it could be write up to the first
exclamation mark on one line - write two f notes on the next line
and the continue on the following line.
Now you and I could probably guess what it meant, but in writing a
coputer program, all code which is necessary just to allow for these
two possibilities and make a judgement starts to become a real pain.
It effectively prevents sensible parsing of abc.   This is why it is
important to design a proper ABC specification.
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!

[David Webber]

From: "Christian M. Cepel" <[EMAIL PROTECTED]>

> 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,

It wouldn't be at the end of a line - it would be in the middle
indicating that the music should be drawn with a line break there.
And so there could be more than one.

So  ..!ff!..

coud be fortissimo.  Or it could be write up to the first
exclamation mark on one line - write two f notes on the next line
and the continue on the following line.

Now you and I could probably guess what it meant, but in writing a
coputer program, all code which is necessary just to allow for these
two possibilities and make a judgement starts to become a real pain.
It effectively prevents sensible parsing of abc.   This is why it is
important to design a proper ABC specification.

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!

[Christian M. Cepel]

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

Re: [abcusers] Current specification - Deathlike appearance.

[David Webber]

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

Re: [abcusers] Current specification - Deathlike appearance.

[Neil Jennings]

At 06:10 PM 4/22/04, you wrote:

2.  if I've got this right, it would seem to be like shooting
oneself in the foot to approve (eg)  !pp! now as a dynamic (for
1.7.6) only to deprecate it in v2 and say one must use +pp+,  and
then use ! as a line break, especially as there is nothing in the
file (or is there?) to indicate whether it is an abc1.7.6 or abc2
file.
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.
Neil

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

Re: [abcusers] Current specification - Deathlike appearance.

[David Webber]

From: "Christian M. Cepel" <[EMAIL PROTECTED]>

> *There has been a draft for a revised standard (with version
number
> 1.7.6 and dated 08/05/00), but it never acquired an "official"
status.
> *
> I know there is lots of debate regarding 1.7.6 and 2.0, but I fail
to
> understand why 1.7.6 cannot be given "official" status for the
sake of
> developers.

Forgive me if I'm getting confused after long absence but...

1. the problem with 1.7.6 appears to be that (like 1.6) it only
applies to single part music.   Which makes it limiting as a format
for use by general music editors.

2.  if I've got this right, it would seem to be like shooting
oneself in the foot to approve (eg)  !pp! now as a dynamic (for
1.7.6) only to deprecate it in v2 and say one must use +pp+,  and
then use ! as a line break, especially as there is nothing in the
file (or is there?) to indicate whether it is an abc1.7.6 or abc2
file.

If 1.7.6 is given official status I would expect to see !pp! in
version 2  (and therefore no ! for line breaks). Don't get me
wrong: I don't really care which it is as long as it is consistent.

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 - Deathlike appearance.

[Christian M. Cepel]

A couple of revisions

> I believe, it also looks bad, when Chris' website is the most linked
> to
> 'introduction to the ABC concept' and the last official standard was
> approved of 'umpteen odd' years ago.   It looks like little official
> work has been done on ABC and like so many things you may visit on the
> internet, has been allowed to weaken and die.  Having been on this
> list
> for over 5 years, I know that that is certainly NOT the case.

The best thing appearancewise of approving 1.7.6 as official is that
the date it is made official is date that is shown when people look
and see when recent work has been done on the specification.. I.e.,
some date in the not too distant future (I hope).  Added to that the
longstanding discussion of the 2.0 standard looks like more work is
continuing on the back of recent work (which is true, but I sound like
a politition worrying about appearance).

I just would love it if ABC's popularity grew such that Finale
included it as an import/export feature (Maybe they do, but they've
yet to send me an upgrade offer from 2001 that persuades me that it's
worth the cost... especially after annoying me with 600 letters a
month each one warning me that I'm running out of time to take them up
on their offer...)

> course I'm asked not to.  I tried to register abcmusic.org, but it was
> already registered to a Nicki Bannister of Birmingham, West Midlands,
> GB.  When I visit that site, I find a domain registration site that is
> squatting on abcmusic.org, as well as:
> abcmusic.co.uk
> abcmusic.com
> abcmusic.net
> abcmusic.org.uk
> abcmusic.ltd.uk
> abcmusic.plc.uk
>
> Way uncool.  I'm mailing them to see exactly what their intentions are
> for these sites (I'm assuming squatting).

I may have been mistaken in my assumptions here. Abcmusic.ltd.uk, and
abcmusic.plc.uk were being shown as 'available' on that website, not
squatted on... and it looks like at least some different folks have
registered these sites, so it's not a case of squatting..
abcmusic.org - Squatted or reserved, no public development. Redirect
to Registration page.
abcmusic.co.uk - Developed website
abcmusic.net - German site, trap online shopping redirect.
abcmusic.com - Reserved and DNS'd, but not pointed to any webserver. 
If that person is on here and needs free webhosting for the cause of
furthering abc, let me know and I might be able to offer you something
for you to develop on.
abcmusic.org.uk - Squatted or reserved, no public development.
Redirect to Registration page... Looks even more likely to be squatted
as there is no name given for the registrant.

Just wanted to correct this before someone came down on me hard for my
mistaken assumptions.

 //Christian

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

Re: [abcusers] Current specification - Deathlike appearance.

[Christian M. Cepel]

Quote from that website...

*There has been a draft for a revised standard (with version number 
1.7.6 and dated 08/05/00), but it never acquired an "official" status.
*
I know there is lots of debate regarding 1.7.6 and 2.0, but I fail to 
understand why 1.7.6 cannot be given "official" status for the sake of 
developers.  1.7.6 is, I think, less controversial than 2.0, and has 
largely been accepted, and offers many advantages for programmers/abc 
notaters who are seeking to both stay strictly to standard AND provide 
the most comprehensively functioning program and well notated music.

I think, also, that making 1.7.6 official would sort of codify certain 
things that would then apply and give direction to those working on / 
debating the 2.0 proposed draft.

I believe, it also looks bad, when Chris' website is the most linked to 
'introduction to the ABC concept' and the last official standard was 
approved of 'umpteen odd' years ago.   It looks like little official 
work has been done on ABC and like so many things you may visit on the 
internet, has been allowed to weaken and die.  Having been on this list 
for over 5 years, I know that that is certainly NOT the case. 

On a side note..

For simplicity, and for future, I just registered AbcMusicNotation.org, 
and AbcNotation.org and will be pointing them to Chris' site, unless of 
course I'm asked not to.  I tried to register abcmusic.org, but it was 
already registered to a Nicki Bannister of Birmingham, West Midlands, 
GB.  When I visit that site, I find a domain registration site that is 
squatting on abcmusic.org, as well as:
abcmusic.co.uk
abcmusic.com
abcmusic.net
abcmusic.org.uk
abcmusic.ltd.uk
abcmusic.plc.uk

Way uncool.  I'm mailing them to see exactly what their intentions are 
for these sites (I'm assuming squatting).

//Christian M. Cepel



David Webber wrote:

From: "Bert Van Vreckem" <[EMAIL PROTECTED]>

 

The home of the 2.0 standard is http://abc.sf.net/standard/, but I
   

think
 

Irwin Oppenheim, who prepared the 2.0 draft, has not recently
   

worked on
 

it...
   

Thanks Bert,  I'll re-read it.

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

[David Webber]

From: "Bert Van Vreckem" <[EMAIL PROTECTED]>

> The home of the 2.0 standard is http://abc.sf.net/standard/, but I
think
> Irwin Oppenheim, who prepared the 2.0 draft, has not recently
worked on
> it...

Thanks Bert,  I'll re-read it.

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

[Bert Van Vreckem]

David Webber wrote:
I was active in this group for a short period some months ago.

There were some inconsistencies needing to be resolved for an ABC 2
spec at that time, and I thought I'd leave time for dust to settle
before getting on with ABC import for my notation software MOZART.
Can someone point me to the current version of the specification?
Have inconsistencies been resolved?
The home of the 2.0 standard is http://abc.sf.net/standard/, but I think 
Irwin Oppenheim, who prepared the 2.0 draft, has not recently worked on 
it...

Cheers,

bert

--
Bert Van Vreckem  
Te audire non possum. Musa sapientum fixa est in aure.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html