I summarized a couple of emails
> I don't know neither your nor Hudson's background, but my impression is
> that like me you are musicians rather than programmers.
> [...] are you trying to volunteer for writing a open source drum map
parser
> yourself?
I'm actually a more a programmer than a musician, and yes, I'm
volunteering for that.
The ABCp project is there to create an open source parser that,
hopefully, the other programmers will want to use as front-end to their
specific applications. This should ease their task and should lead to a
more consistent ABC syntax.
Unfortunately I'm alone in this effort and I don't have too much free
time for this. Things are progressing slowly.
These discussions are very helpful for me giving hints on the direction
to take.
Let's take the following as requirements for the syntax:
> a) It should be as short and simple as possible
> b) It has to be exact and unambigious
> c) It should confirm as closely as possible to current abc syntax
> structure
> d) It has to allow for a percussion map to be defined for a single
> voice in a multivoice score
> e) Percussion mapping code inside the tune body may or may not be
> allowed, but must not be mandatory
First of all assume the following default:
"When clef=perc the note heads change according the accidentals"
and let's consider the possible solutions.
1) %%setdrum command defined as follows:
<setdrum> ::= '%%setdrum' <instrument> [['note=']<note>]
[['head=']<head>]
<instrument> ::= <number> | <GMpercussion>
<note> ::= {'^'|'_'} <pitch> {'\'' | ','}
GM percussion names can be obtained from any GM percussion map
removing blanks.
Capitalization is uninmportant. Blanks can be replaced by '-' or '_'
if you want.
Numbers are acceptable as well.
It says that in a percussion voice (clef=perc), a note <note> is to
be played
by the MIDI instrument <instrument> and to printed according the note
pitch
with the specified notehead.
If notehead specification is missing, the default applies.
If the note specification is missing, the mapping will be cleared.
^^^^ NOTE THAT THIS IS DIFFERENT FROM WHAT DISCUSSED SO FAR! ^^^^
If the command is found in the header and it follows a voice
definition (V:) it
applies to that voice only otherwise it applies to all the voices in
the tune.
If the command is found in the body, it applies to the current voice
only.
a) -> It looks rather simple to me.
b) -> The proposed semantic makes it unambigious
c) -> It uses the existing '%%' syntax (and the proposed I: syntax)
d) -> Mapping percussion for a single voice is possible.
e) -> Percussion mapping code inside the tune body is allowed
through both the [I:setdrum ...] and '%%' syntax.
2) Voice syntax augmented as follows:
<voice> ::= 'V:' <parms> ['instr=' <instrument>] ['head='<heads>]
All notes in the voice will be played by the specified MIDI
instrument and
will be printed with the specified notehead.
a) -> It simple to read but it requires a separate voice for each
instrument. It uses pitch only for printing, each note will
be played the same.
b) -> The proposed semantic makes it unambigious
c) -> It extend the usual voice paramenters.
d) -> Only mapping for a single voice is possible.
e) -> Mapping is allowed only in the header.
3) Decoration syntax augmented as follows:
'+'<GMpercussion>'+' '+'<head>'+' <note>
Play the note with the specified instrument and print it with the
specified
notehead.
'+'<GMpercussion>('+' '+'<head>('+' <note>
As above but create a mapping between the note and the
instrument/notehead
until the next '+'<GMpercussion>)'+' and '+'<head>)'+'
a) -> It's rather intrusive and may create confusion. It might be
convenient for occasional percussion.
b) -> The proposed semantic makes it unambigious
c) -> It extend the decoration semantic. Extends the syntax already
existing (e.g. +<(+ and +<)+)
d) -> Only mapping for a single voice is possible.
e) -> Mapping is allowed only in the body.
Now, from a purely syntactic point of view I don't see any problem in
implmenting all the three (and in fact I already did) but I'm not sure
we should propose a syntax with three differente components!
Regarding the '&' operator I agree it's a complex one to deal with but
it's complexity has nothing to do with percussion.
Remo D.
------------------------ Yahoo! Groups Sponsor --------------------~-->
Most low income households are not online. Help bridge the digital divide today!
http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/mjFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/abcusers/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
