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 _______________________________________________ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
