Phil Taylor wrote:
On 5 Dec 2004, at 19:30, RWW Taylor wrote:
The back-quote character appears on the standard Mac keyboard on the
upper-leftmost key, above the tab very convenient.
On my G4 PowerBook it's the key to the left of the Z, so I guess it's
not really standardised, even on
Well, considering you really need to parse most fields *anyway* in order for
the parser to have a context for parsing the actual tune data (for example,
if Key is currently G, then the F note I just read is actually an F#...),
I'm not sure it makes much sense to leave that decision up to the
Phil Taylor wrote:
I'd like to keep the API as simple as possible. Pass in a pointer to a
string
containing one tune, get back a pointer to a linked list of structs
which is easy
to convert to a picture of the music (anything from postscript to a
bitmap) or
to sound (midi, Quicktime tune
Steve Bennett wrote:
Hmmn -- I know a way to test that. If you're seeing this message, than that
means my theory is probably correct, since the email address I'm using to
send this to is NOT subscribed to the list, and I'm sending the message to
the abcusers-list address.
Well... *That*
Thanks, I'll give that a try.
--Steve Bennett
Tom Keays wrote:
Try Toby Rider [EMAIL PROTECTED]
On Mon, 30 Aug 2004, Steven Bennett wrote:
Steve Bennett wrote:
Hmmn -- I know a way to test that. If you're seeing this message, than that
means my theory is probably correct, since
Jeff Szuhay wrote:
Someone stated that using ANSI C would be best but that we would
definitely want to use the object oriented extensions to make it object
oriented C (not C++)... Perhaps that is ANSI C today... I dunno... I
haven't programed in C for 5 years and perhaps ANSI has certified
Christian M. Cepel wrote:
Steven Bennett wrote:
Objective-C was a big surprise to me when I was forced to learn it for a Mac
programming contract. For a language which is basically standard C with a
very small set of extensions to add OO support, it's both easy to use and
surprisingly
Paul Rosen wrote:
This certainly seems like a universal problem, not just ours. I'm only
familiar with the Windows environment, and it is simple to make a DLL with a
straight C or COM or .NET interface that any other windows program can use.
Is there no mechanism like that on MAC and LINUX?
Remo D. wrote:
Hi there. I've prepared a proof of concept. It's only a scanner for ABC
files but already features Lua handlers (as well as C handlers).
My biggest concern is that ABC (especially when you try to support older
*and* newer versions, which is really necessary given how much stuff
K:none is already defined in the ABC 2.0 draft spec, although there's a
slight ambiguity in that spec, since none is also shorthand for
clef=none. When I implemented that section of my parser, I resolved that
in favor of the key, and required the full clef=none if you want no clef.
K: by itself
John Chambers wrote:
Steven Bennett writes:
| K:none is already defined in the ABC 2.0 draft spec, although there's a
| slight ambiguity in that spec, since none is also shorthand for
| clef=none. When I implemented that section of my parser, I resolved that
| in favor of the key
Paul Rosen wrote:
What projects are there? My imagination leads me to the following. I'd love
to know how else ABC could be used.
Standard Notation
Tablature
MIDI Player
Transposer
Indexer
Pattern Matcher
Conversion to another format
Instruction (probably needing fragments)
The
Bernard wrote (portions snipped):
I disagree entirely on the maximise portability. The maximum is ascii. You
can even read it without a computer.
...
Sorry, but it seems archaic to me (in a situation such as we are talking
about) not to write the file in ascii.
First off, we're talking
To add my two cents to this discussion: While I have my doubts that any
single parser design could fit the needs of more than maybe half (being
generous) of the possible applications out there, it's still a worthwhile
project.
I would avoid producing output in any format which needs further text
Phil Taylor wrote:
OK, I understand that. What was bothering me though, is how Steven B's
parser is going to deal with regular ascii strings which include a
space followed by a bracket. It's no problem when everything is
unicode, or everything is ascii, but if we are to have ascii abc which
Christian M. Cepel wrote:
It was my understanding that all unicode character sets contain English
characters mapped to the same values they're mapped to in other sets.
Close -- Unicode is a *single* character set. For convenience, you'll
frequently run into references to Unicode code pages,
John Chambers wrote:
Lest you think this is way off topic, I might mention that I've been
involved in attempts to use non-ASCII char sets in my ABC tunes. I
have a lot of international folk dance tunes, and it would be
really nice to be able to spell the titles right. Also, I like to
I'm just doublechecking since this conversation spun off of the
universal parser conversation...
This conversation, while interesting doesn't actually pertain to the
parser does it? I've been trying to follow it in case it does.
My understanding is that a parser will not do any file
According to Apple docs (I'll take their word for it... ;):
0x2028 -- Unicode line separator
0x2029 -- Unicode paragraph separator
--Steve Bennett
Stephen Kellett wrote:
In message [EMAIL PROTECTED], Steven Bennett
[EMAIL PROTECTED] writes
line endings needing to match throughout
John Chambers wrote:
Yeah, but you could argue that it's not as big a problem with
Windows, because Windows (and MSDOS) is a separate OS that is its own
standard and has never been even minimally compatible with any
other system. People expect that porting software to Windows
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
On Tue, Apr 27, 2004 at 12:01:00PM -0400, Steven Bennett wrote:
Note that while ABC 1.6 and 1.7.6 explicitly allow these fields in-between
tunes, ABC 2.0 draft states they can only be at the beginning of a file.
(There really ought to be a note about this in the Deprecated Syntax
section
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
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
Hi all!
I've been working (ever so slowly) on my ABC parser, and one item which came
up was the specification of the clef field as listed in 2.0 spec. (Note
that this message is 2.0 specific -- I'm aware there are other issues in
what various pre-2.0 programs did that may be relevant, but that's
Richard Robinson wrote:
Is anybody else here looking much at MusicXML ? I've been having a look
over the last few days, and I must say, I'm rather impressed. It seems
to me that this could all be tremendously useful to us, as ABC users.
I looked at it and can see a number of places where it
It was an outrageous example on purpose. It's *definitely* not legal ABC
2.0, but the definition I was hearing implied that it would be legal ABC
1.*. Which I didn't think it *ought* to be. Which is why I offered my own
definition of what the actual 1.* behavior ought to be.
That said, the
Steven Bennett writes:
| It was an outrageous example on purpose. It's *definitely* not legal ABC
| 2.0, but the definition I was hearing implied that it would be legal ABC
| 1.*. Which I didn't think it *ought* to be. Which is why I offered my own
| definition of what the actual 1
So... If it can only occur on tune and lyric lines, and it can only
occur
where a staff break or lyric line break would be valid, then that is
why I
suggested a definition along the lines of:
A backslash (\) at the end of a line means do not break the staff or
lyric line at this point if
relate to. Although,
you should modify your statement so that it can occur on
tune, lyric, and symbol lines (add the symbol to the list).
tom
Steven Bennett said:
So... If it can only occur on tune and lyric lines, and it can only
occur
where a staff break or lyric line break would
I. Oppenheim wrote:
As for the 1.6 and 1.7.6 specifications, regardless of what program X, Y, or
Z does, the written spec is awfully vague. I have several possible
approaches to different elements of this, but the basic concept appears to
be that \ at the end of a line isn't so much a
Hi!
I'm in the process of writing Yet Another ABC Parser as part of a larger
project I've been working on for a while. (There are umpteen jillion
reasons why I'm not using an existing parser - the biggest being this one is
written in Objective C, but that's besides the point...)
Ideally I'd
Phil Taylor wrote:
(IMHO,
there should be NO data in an ABC2 file which exists outside the context of
the current tune -- I don't know if anyone else agrees with this, but it
makes the most sense to me...)
I have to disagree. One very useful feature of abc is the possibility
of embedding
Has anyone given any thought to supporting Unicode and/or UTF8 files in the
new standard? Much of my text editing nowadays (I work on Mac OS X...)
produces Unicode encoded text files by default, and I think this is going to
become more commonplace over the next few years. Also, supporting
Phil Taylor wrote:
To return to the original suggestion in the title of this thread, it
has been suggested many, many times before. One of the first postings
I ever made to this list (or was it the developer's list?), made
exactly the same suggestion - for goodness sake lets write the
On Fri, 18 Jul 2003, Jack Campin wrote:
[mostly snipped because it was such colorful rhetoric...]
...this is such ... Authoritarian
Actually, I have to admit it *is* rather authoritarian of me. 20+ years of
dealing with incompatible and poorly defined computer file formats,
protocols, and
The whole idea (and the goal any standards maker should be working towards)
is to provide a mechanism and incentive for both the content developer and
the tools developer to implement and stick to the new standard. This is
useful to both -- the tools developer should use an old parser if the
37 matches
Mail list logo
