drum notation

[Rune Zedeler]

I have some issues hopefully to fix before 1.6.
One of them is drum notation.
Doing a permanent implementation means doing a drum-head-engraver and an 
auto-script-engraver (that automatically adds scripts to notes depending 
on the pitch-information)
Both seems quite simple to do.
The less simple things are how to represent the drum instruments and 
distingush them from normal notes.
I see different approaches:

a) use the general midi scheme to represent the different drums. 
Different drums that are played on the same gm-key can be distinguished 
by using different accidentals (i.e. fis for closed highhat, ges for 
highhat). Create contexts PercThread, PercVoice and PercStaff. 
PercThread is similar to thread except that it contains the 
drum-engravers instead of the note-head-engraver, and 
accidental-engraver is turned off. The two other contexts are similar to 
the normal ones except that they accept drum-sub-contexts instead of 
normal sub-contexts.

b) use same representation as in a, but add information to each 
pitch-object of whether the pitch is a real pitch or a normal pitch. Let 
the note-head-engraver ignore drum pitches, and add the drum-engravers 
to the normal thread-contexts and let them ignore normal pitches.

c) use another representation. I.e. use a name,timbre,state tuppel 
(three strings) instead of the current octave,notename,accidental (three 
ints) tuppel. name could have values like 
"bassdrum","highhat","tom","guiro"; timbre could have values like 
"default","high","mid","low","floor"; and state could have values like 
"default","open","closed","long","short".


ad a: This is the ugliest approach, which would be easiest to implement 
(if the choise falls on "a" then I guess I should be able to do it 
witout help). I don't really like "a", though. First of all there is not 
much point in representing a drum as octave-notename-accidental. The 
scheme is further more dictated by midi - and dictating a notation 
scheme by an ugly standard like midi is definitely not nice.
The good thing about a, ofcourse, is that midi playback implements 
itself. Further more none of the other engravers need to think about 
drum notes in any way - because the engravers are turned off whenever a 
drum note occurs. (perhaps the tie-engraver should be changed a bit, 
though? Haven't checked out how it determines the position of the note 
heads)
Bad things include that we end up drowning in special, almost similar 
contexts, and that if one should wish to have normal and drum notes in 
the same staff then it would be impossible.

ad b: This is sort of inbetween a and c. Again I should be able to do 
this more or less without help (perhaps just add a fourth parameter to 
make-pitch), but some of the bad things of "a" still apply.

ad c: This is the approach that I prefer, but it includes some major 
restructuring of the code, and I am not sure how to do this.
Perhaps add sub-classes to pitch (tonal and percussion), or perhaps 
replace the current trippel with a trippel-union. Or perhaps keep the 
pitch-class as it is and make a new percussion class - and then add 
sub-types to note-request (pitched noterequest and percussion 
noterequest) instead. This could be done by replacing Melodic_req with a 
 Timbral_req with a subtype Melodic_req. Not really sure about the more 
far-from-c parts of c++ (actually the only object-oriented language that 
I know the basics of is J*va...) - so I'm not sure if this would be a 
natural way to do it in c++.
After implementation "c" should work without any problems that I can 
think of.


There is also the problem of how to input the drum notes. Surely the current

\include "drum-pitch-init.ly"
drums = \notes ...
\include "nederlands.ly"
restofmusic = \notes ...

is an ugly approach, but I am not sure whether

drums = \drums ...
restofmusic = \notes ...

or

drums = \notes(drums)
restofmusic = \notes

is the best/easiest.

Generally putting information of input-type into the pitches would come 
handy in many places, I think. Thinking tab-notation in particular.

I will start on the two drum engravers now  -  the only way they are 
affected about the selection of the above choises are in the way that 
they translate pitches into note-head-styles, staff-postions and scripts 
- and this is in all case something that should be configurable from 
within scheme.
Hopefully there are some comments on the subject when I finished the 
engraving part of the engravers.

-Rune