| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
dev:percussion [2016/01/04 09:00]
michael |
dev:percussion [2016/07/14 21:21]
michael [Objective] |
| ====== Percussion Notation ====== | ====== Percussion Notation ====== |
| ===== Objective ===== | ===== Objective ===== |
| Now that I'm learning to play the drums, I find it is not that easy to find a written drum part for a particular song I want to learn. I have many of these songs available as standard MIDI files, and I want to use Rosegarden to turn those into written drum notation I can read while in front of the kit. Any other objectives I achieve in this are secondary to this primary goal. Furthermore, I am focused on functionality much more than ease of use or shiny looks, and this is likely to be hacky rather than pretty. | To use Rosegarden to print drum notation for compositions that exist only in the MIDI realm, such as vintage computer game music. |
| |
| ===== Clef ===== | Rather than develop a nice, first rate feature that would be enjoyable to use, my aim is only to hack things to a point where I can get the task accomplished, even if the result is brutally ugly to use. |
| In this implementation, the two-bar clef will be effectively the same as the treble clef. This is purely for my own convenience, as I think in treble clef. | |
| |
| ===== Handling Polyphony ===== | ===== Phase 1 ===== |
| Drum kit notation is fundamentally polyphonic notation. While the beats sometimes line up in such a way that split-and-tied chords would work, I am going to take an approach that requires drum parts to be polyphonic 100% of the time, with separate segments for each type of drum played. | The Edit... Split... Split by Drum feature. This scans a segment to find the discrete pitches, then moves each pitch encountered into a new segment. All the F#3 go into a segment by themselves, all the Ab4, all the C0, etc. This is a good beginning, but it needs refinement. |
| |
| ===== Drum Splitter ===== | ===== Phase 2 ===== |
| Toward the ends of converting existing parts to written notation and of handling polyphony, the first thing I need to implement is a drum-oriented split function. | To work out which pitches to combine into a single segment, such as open and closed hi-hat. This will be limited to GM percussion only, and hard coded for the basic standard GM drum kit, cross-referenced to whatever LilyPond supports. If it isn't in basic GM or if LilyPond can't support it, then it doesn't get in. Hard coding the rules saves a massive amount of work. If users encounter non-GM files they wish to convert into drum notation, they'll have to remap the drums to GM first. If that became a frequent issue for someone with a particular vintage synth or whatever, this remapping could be scripted a lot more cheaply than fancy internals could be constructed. There just isn't any point in laying all that groundwork to create mappings when one mapping will be used the vast majority of the time, and when there are only a small number of exceptions (all pertaining to the snare and hi-hat as far as I recall). |
| |
| The function shall: | ===== Phase 3 ===== |
| * for each pitch 0 to 127 | Once the drum splitter is smarter, the next step is to collect a list of every kind of drum LilyPond can export, and create a way to designate a particular segment as containing that kind of drum. This means the pitch is irrelevant, and non-GM mappings could be accommodated here easily. The obvious way to go here is to add a combo box to the SPB to designate that this segment contains a hi-hat or what have you. |
| * search the segment for this pitch | |
| * if the pitch is found, create a new segment for this pitch, taking the label from the percussion key map | ===== Phase 4 ===== |
| * for known pitches (eg. snare) transpose the segment such that the pitch sounds suitably and the note is rendered at the correct height (eg. middle space C) | Once it's possible to designate a hi-hat segment, LilyPond export needs to be modified to deal with putting all of this together. It is probably sufficient to write each segment to a discrete Voice. I have no idea as yet how to deal with the problem of rests. |
| * for known pitches (eg. closed hi-hat) notate using correct note heads automatically | |
| | It should be possible to modify LilyPond export to notate things like cross-stick, accents, and ghost notes; the latter two of which could be guessed at reasonably by examining velocity, and using simple hard-coded ranges. Velocity less than //n// equals an automatic ghost note, velocity higher than //y// equals an accent. |
| | |
| | ===== Phase 5 ===== |
| | Possibly add some configuration and whatnot so there is more flexibility. |
| |
| etc.? | |
| |
| meh... I think I'll implement a rudimentary splitter to get started, and see where it all goes once my sleeves are rolled up. I don't have a firm plan for a number of issues, including: | |
| |
| * hi-hat, crash, ride, and snare can all trigger a variety of different samples via different pitches, and all but a handful of these pitches need to be notated on the same line | |
| * our handling of rests in polyphonic parts is really bad, and this drum stuff will showcase the absolute worst of it, absolutely all the time, and this needs gone through and sorted out | |
