Drum notation, scheme functions and midi

[Rune Zedeler]

Hi list!

While waiting for a guile 1.4 compatible development-version i did a bit of
thinking about how to do an a bit less hacky implementation of drum-notation.

I realised the fact that I actually pretty much like the way it works now:
<begin how drum-notation works now in 1.5.20 >
In "drumpitch-init.ly" we have three things:
- We have a mapping from drum-names to ly-pitches corresponding to the
midi-location of drum-pitches - but using the fact that several ly-pitches
corresponds to the same midi-pitch (i.e. cis and des is the same in midi) to
distinguish different drums that sounds the same in midi (i.e. hihat and
closed-hihat).
- Then we have several mappings from pitches to paper - that is: mappings that
for each drum pitch assigns a note-head-style, a script and a position on the
staff.
- Finally we have a scheme function, "drums->paper", that applies a given one
of the mappings to a piece of music.

To play a drum-staff through midi you simply place the voice in a staff with
midi-instrument "drums". This makes the staff use midi channel 10 so that the
pitches will be mapped to drums.
To put some drums on paper you set \clef percussion and apply the scheme
function "drums->paper" which takes one of the pitch2paper-mappings and uses
it for inserting note-head-style-changes, scripts and changing the pitches of
the music in order to make the drums appear the right way on the paper.
<end how it works now>

There is only a few problems on this - and I would prefer solving the problems
one at a time instead of doing a total reimplementation of drum-notation.
The problems are:

Prob 1: One have to create two score parts in order to make the midi-output
right.
The same problem applies to repeats. It should be solved, and I am probably
not the one to solve it. The solution will probably include a total rewrite
of the midi-implementation - or at least a way of applying scheme functions
to the music that only the midi-processor can see - and not the
paper-processor.

Prob 2: The global scheme-name-space is too polluted by drumpitch-init.ly.
This is easily solved by changing the structure of the mappings.

Prob 3: It is a problem that after including "drumpitch-init.ly" one can no
longer use normal note-names.
The solution, imho, would be to add a ly-command that instead of replacing the
old notenames with new ones MERGES a set of new note-names to the ones
already defined.
Another solution would be to add a \drums-interpretation context. But, really,
I cannot see the reason for doing so. The user should still be allowed to
change the names of the different drum-pitches - so this would just mean that
we would have to implement the entire \notes-interpretation context once
again with no differences.
One could argue that a drum-pitch should consist of something totally
different from octave-pitch-alteration - something like
midipitch-notehead-staffposition-script - but this violates the lilypond
thought of separating the music from how it is printed on paper. So in all
cases the user have to somehow state how the drums should be converted to
paper.
The way it works now is easy to use and very free and comprehensive, imho.

Prob 4: - And this is the "real" problem: The "apply"-syntax is too clumsy and
not flexible enough.
My favorite solution to this involves two things:
a: Instead of syntax
\apply #<SCM-FUNC> <ARG>
I would suggest
\<SCM-FUNC> <ARG>
or, if this is impossible,
\#<SCM-FUNC> <ARG>
The reason for this is that using scheme functions will require much less key
presses, will look less temporary, and will suppress the difference between
lilypond-commands and add-on scheme functions - making the scheme add-ons
more comprehensive for the masses.
b: Allow the scheme function to take any number of arguments of any type and
return an argument of any type instead of only allowing functions taking one
"music"-argument and returning a "music"-argument. It is annoying that scheme
afaik have no type-checking - but I think it is possible to determine the
number of arguments required for a given scm-function.
Some ideas for what this could be used for: The smart-transpose and similar
commands would be nicer. One could actually use the same syntax for
smart-transpose as for transpose. Especially one could write the
transpose-pitch in a normal way instead of the clumsy, hacky (make-pitch a b
c).
Another application (I thought of it after the resent enharmonic transpose
from cis to des -problem) would be a "fromto" scheme command (easily written)
taking two pitches and returning the distance between them (relative to c').
One could then do
\transpose \fromto cis des \music2tranpose
instead of the incomprehensive
\tranpose deses' \music2tranpose
Notice that this would work automatically without having to rewrite the
tranpose-command in any way.


That was that, afaics. Please comment.

-Rune