I've put on a page (http://abcp.sourceforge.net/abcpsyn.shtml) a very
terse description of the syntax ABCp is able to recognize.
As always I offer it to your criticism. Feel free to ask what is not
clear (I put together the doc on the fly).
What I'm really interested in is to understand if I
Hi there! I think I've reached a critical point in the ABCp development
and I'm here (once again) to ask for your comment.
The low level interface is almost complete in the sense that further
improvements should be determined on a real usage basis and I'm starting
to think about the higher
Wil Macaulay wrote:
Yes, I do have a suggestion: if you really want to implement a
'generic parser', start by choosing a standard to implement. If you
want to suggest changes to the standard, do so as an independent
process. Otherwise you'll end up with a parser that only parses
non-standard
Yes, I do have a suggestion: if you really want to implement a 'generic
parser', start by choosing a standard to implement. If you want to
suggest changes to the standard, do so as an independent process.
Otherwise you'll end up with a parser that only parses non-standard abc...
having said
Neil Jennings wrote:
I still think my suggestion is more general, as it allows the internal
part name (one letter) to be totally independent of the displayed text
(Part description).
Remo's proposal would only allow one word (part name) to start with
each letter. Therefore if there was a part
My program would reject (ignore) any part specification longer than one
letter.
Your proposal could lead to ambiguous part specifications, if one name
matched part of another name.
I can see the need for the part specification to have two 'parts', one
the single letter identifier to be used in
Neil Jennings wrote (about Remo proposal):
My program would reject (ignore) any part specification longer than
one letter.
Your proposal could lead to ambiguous part specifications, if one name
matched part of another name.
Remo proposal (below) avoids ambiguity by distinguishing between
Em 25 Oct 2004, [EMAIL PROTECTED] escreveu:
My program would reject (ignore) any part specification longer than one
letter.
Your proposal could lead to ambiguous part specifications, if one name
matched part of another name.
Remo's proposal avoids the ambiguity by distinguishing the
Thanks. I'll take as a sinonym for +slide+ then!
R.D.
John Chambers wrote:
Remo D. asks:
| I still have to fix parts and continuations with the latest suggestion
| but there's something else that I can do very quickly: can anyone tell
| me what the decoration J is?
In abc2ps, it produces the short
repeats.
Neil
- Original Message -
From: Remo D. [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 23 October 2004 11:22
Subject: [abcusers] [ABCp] Parts
Most of the examples I've examined (thanks again folks!) use a single
uppercase letter for denoting each part. P:A in a tune means
Neil Jennings wrote:
Because the P: text appears above the staff, people have mis-used it to add
comments which have nothing to do with parts.
In the tune header, it can have a formula such as (AB)2(AC)3
In the body, it must be just a single letter
HARMONY can play tunes according to the formula,
I've made some changes and some testing. Everything is far from being
stable or even usable but for those that are interested I've uploaded
the source on sourceforge.net: http://sourceforge.net/projects/abcp.
I've included in the zip file the executable for re2c (as long as the
source files)
Hudson Lacerda wrote:
It seems that you coded a line continuation similar to those of bash or C
That's what I did. Continuation gets reported (a T_CONTINUE event) and
the scanner stays in the same state.
[V:1] abcde \
[V:2] ABCDE \
[V:1] cdedc
[V:2] CDEDC
is equivalent to:
[V:1] abcde cdedc
Most of the examples I've examined (thanks again folks!) use a single
uppercase letter for denoting each part. P:A in a tune means this is
the part 'A' and P:ABACAB at the beginning means, if I understood it
correctly, play part A, then B, then C
This is what the standards suggest but in
On 23 Oct 2004, at 09:36, Remo D. wrote:
Hudson Lacerda wrote:
It seems that you coded a line continuation similar to those of bash
or C
That's what I did. Continuation gets reported (a T_CONTINUE event) and
the scanner stays in the same state.
That's correct. We have had long discussions on
I still have to fix parts and continuations with the latest suggestion
but there's something else that I can do very quickly: can anyone tell
me what the decoration J is?
Tnx.
R.D
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Remo D. asks:
| I still have to fix parts and continuations with the latest suggestion
| but there's something else that I can do very quickly: can anyone tell
| me what the decoration J is?
In abc2ps, it produces the short diagonal line to the lower left
of a note head that means a slide up to
Remo D. wrote:
Hudson Lacerda wrote:
It seems that you coded a line continuation similar to those of bash
or C
That's what I did. Continuation gets reported (a T_CONTINUE event) and
the scanner stays in the same state.
[V:1] abcde \
[V:2] ABCDE \
[V:1] cdedc
[V:2] CDEDC
is equivalent to:
[V:1]
Hello.
Remo D. wrote:
[...]
There is one thing that I'm not sure about. Should I support the 1.6
syntax for continution? Supporting both is not an easy task and I
would prefer not doing it.
[...]
Does anybody thinks that supporting al this variations on continuation
is absolutely crucial? I
Hi.
Remo D. wrote:
[...]
Hudson suggestion
P.S. Please take in account tuplets with many digits, like
(11:8:11CDEFGABcde^f
made me think about the needing for a T_ENDNPLET token. In other
words from (3ABC four events would be triggered: T_NPLET, T_NOTE;
T_NOTE, T_NOTE and T_NPLET.
Is that
Hi! You wrote:
I have some real-life files that often causes some software problems,
since I tend to notate more chromatic music than most (what ever that
means...). I could send you a few, if you'd like...
Thanks, I'd appreciate! You could zip and send them to via email. If we
you find any
Thanks everyone for the directions on the test files, I've started to
collect them and I'll give them a serious look next weekend!
Hudson suggestion
P.S. Please take in account tuplets with many digits, like
(11:8:11CDEFGABcde^f
made me think about the needing for a T_ENDNPLET token. In other
It might not be amiss for us to create a freely available repository on
the sourceforge project page for people to add to and sample. Such has
been discussed in the past, but I don't know if it's ever been
done...leastwise, it's an oft asked question always with a piecemeal answer.
On 16 Oct 2004, at 20:00, Remo D. wrote:
snip impressive progress report
I would appreciate if someone could share with me a set of abc file to
be used as test suite. I remember someone mentioned the fact he was
working on something similar.
I have a test suite which I used to test BarFly, but
Remo D. wrote:
I would appreciate if someone could share with me a set of abc file to
be used as test suite. I remember someone mentioned the fact he was
working on something similar.
I have some real-life files that often causes some software problems,
since I tend to notate more chromatic
Remo D. wrote:
I would appreciate if someone could share with me a set of abc file
to be used as test suite.
The jcabc2ps package contains several test files.
http://trillian.mit.edu/~jc/music/abc/src/
http://trillian.mit.edu/~jc/music/abc/src/jcabc2ps/abc/
Hudson Lacerda
P.S. Please take in
Hi there!
I'm quiely working on the generic parser for ABC, the lack of news is
caused by my very short spare time!
I accepted the suggestion about adding another level of parsing. After
recognizing, say, a L: field, the a function parses the field and
extract the numerator and denominator of
You're also welcome to use the facilities of the abc.sf.net project. Just
let
me know and I give everyone involved the necessary permissions...
Many thanks, that's a great option! It will give ABCp a high visibility.
My next objective is to reach the status of beta from the current state of
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
In message [EMAIL PROTECTED], Paul Rosen
[EMAIL PROTECTED] writes
What about fermata over a barline?
I didn't know it was possible, but, OK.
For a little book giving a lot of information about Music notation I
commend Gerou: Essential Dictionary of Music Notation. I don't think any
writer of
On Sat, Sep 11, 2004 at 02:17:00AM -0400, Paul Rosen wrote:
First of all, I was working from the 1.6 document, I probably should have
been using a newer one. I noticed that
http://www.gre.ac.uk/%7Ec.walshaw/abc/abc-draft.txt contains some
interesting stuff. Is that the latest that has
On 11 Sep 2004, at 07:17, Paul Rosen wrote:
rhythm - arbitrary length string.[can this be interpreted in any
way?]
Yes. Several programs (BarFly, abcMus, abc2midi) use it to invoke a
stress
program when playing. However, it's probably best to leave it as a
string
here and let the controlling
In message [EMAIL PROTECTED], Paul Rosen
[EMAIL PROTECTED] writes
as you might have read in other posts, I would be very interested in any
work on API for accessing ABC file once parsed. I still did not have a
clue
for creating one and I would welcome any suggestion! Just let me know when
you
Paul Rosen writes:
elemskip - arbitrary length string.[What does this do?]
Elemskip is the distance between notes, a real number. It is used by abc2mtex,
but probably not by any other program. It's good to have the parser accept an
arbitrary
string, tho, since if the field is
as you might have read in other posts, I would be very interested in any
work on API for accessing ABC file once parsed. I still did not have a
clue
for creating one and I would welcome any suggestion! Just let me know when
you got an idea.
I would break the problem into two parts: first
John Chambers wrote:
| well if my 2p are worth at least 2p to you, do it in ansi C if you want
| anyone to use it. The advantages of portability and general
| comprehensability outweigh some fun features that nonstandard extensions
| may have. I like SNOBOL but I would avoid inflicting it on other
To: [EMAIL PROTECTED]
Subject: Re: [abcusers] ABCp proof of concept
Amazing! I taught SNOBOL (3 and 4) to graduate level music students in
19 (gulp) 69-70. I even wrote a primer to teach it. I did some fairly
hefty music analysis programs with it too. Now I've forgotten it all
and thought
Atwood, Robert C said:
... (snobal text removed) ...
Any thoughts on using a tool like lex/yacc / flex/bison for parser
generation?
For the parser that I am working on, I am using Python. I
have the complete parser working now, using simpleparse, which
uses an EBNF description as its input.
Any thoughts on using a tool like lex/yacc / flex/bison for parser
generation?
After some research around, I landed on re2c (http://re2c.sourceforge.net)
which is reported to create faster lexical scanners than lex. It uses a
different approach and creates a lexical scanner that has no library
Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christian M.
Cepel
Sent: 26 August 2004 21:37
To: [EMAIL PROTECTED]
Subject: Re: [abcusers] ABCp proof of concept
Steven Bennett wrote:
Jeff Szuhay wrote:
Uh... Objective-C? :-P
(Oh, I couldn't help myself. You can
Hi there!
I've made no progress on the API. Thanks for the suggestion that a time
iterator is needed for sure, but I'm still struggling to put togheter a
meaningful API. Even understanding one of the many described on the net it's
too much for me in this moment.
I've found an interesting
Oops! I forgot the link: http://www.dentato.com/abcp
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Hi there!
As you may have noticed, I have time to dedicate to this project only
during weekends. I would never had enough time to answer to all the email on
the list so I prefer to include all the suggestion in the proof of concept.
I hope you will have the time of downloading it, see if it
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
Steven Bennett wrote:
Jeff Szuhay wrote:
Uh... Objective-C? :-P
(Oh, I couldn't help myself. You can slap me for that one),
I wouldn't slap you for that -- I almost answered the same thing myself, but
I suspect I would have meant it more seriously... grin
Objective-C was a big surprise to
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
Steven Bennett wrote:
As much though I love and prefer Objective C, and would use it for my own
projects, I'd still recommend straight ANSI C for this particular project,
given it's stated goals. Mainly because Objective-C isn't very well known
outside the Mac world, but also because there are
Mainly because Objective-C isn't very well known outside the Mac
world,
True, but it is firmly in GCC 3.1 and beyond.
but also because there are runtime bindings (just like C++)
This is a good point and a reason to stick with ANSI C.
To subscribe/unsubscribe, point your browser to:
I'd have to opt for the second option. Where myTune is a C struct and
it gets passed through to all the relevant apis. This sort of interface
can be made to be very OO and is trivially easy to wrap in an OO wrapper
for say C++ or Python etc. That seems to provide for maximim flexability.
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 an
updated C spec to
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?
Hi there!
Thanks for your replays. I try to summarize the points so far (at least my
conclusions), please correct me if I'm wrong.
1) To increase portability we should stick to plain ANSI C. I'm perfectly
fine with it. The complications I was referring to, Paul, were those that
you encounter
1) To increase portability we should stick to plain ANSI C. I'm
perfectly
fine with it. The complications I was referring to, Paul, were those
that
you encounter when you try to access a C++ library from another language
(including C).
Well, I see why you want to stick with C. I'll study
Paul Rosen said:
I am very interested in the work you're doing. Unfortunately, I have very
little time these days! Once in a while, I'll have a week where I can
spend a little time each evening on this, but not very often. If I had
time, I'd plunge right in the middle of the work.
Your
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
As far as using Lua for the handlers, I'm not certain what advantage that
gains you if any, especially given how much context you'll need to be
passing back and forth to the handlers, and the need to call back into C
to
get the next token. (Is that even possible in Lua?) I suspect the
Hi Christian. You're right, comments are what I'm looking for.
I just want to add to what you said, that the scanner is 100% ANSI C (look
at abcpscan.re not at abcpscan.c!).
The next big decision to take is if the whole parser should be in C or if I
should start using Lua right now.
Consider
As always, comments are welcome. Actually more than welcome! If none is
interested I'll refrain to keep posting about it. Just let me know.
I am very interested in the work you're doing. Unfortunately, I have very
little time these days! Once in a while, I'll have a week where I can spend
a
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).
I've also tried to go into details: http://www.dentato.com/abcp/poc.htm but
it's hard to be clear and precise without becoming boring!
I compiled it on WinXP
59 matches
Mail list logo
