On Monday 26 September 2011 12:57:37 D. Michael McIntyre wrote:
> Implementing a new clef glyph to get on paper is easy, but making it work is
> going to be really involved. The existing clefs just act as a conversion
> factor for height on staff. If it would have been at height n in treble
> (all internals work in treble) then it's going to be at height n +
> conversionFactor in bass or tenor or whatever.
What I have in mind (and how, among others, mscore seems to work) is a
combination of a mapping and conversion as you describe.
Let's assume we extent the keymapping section in the studio with some extra
attributes. Now we have a number (is the MIDI pitch) and a name. We need at
least two extra atributes. First a notation-pitch. When displaying a note on a
staff we will use this notation-pitch instead of the MIDI pitch. If a segment
belongs to a percussion track we will always display a percussion clef and use
the notation pitch instead the MIDI pitch to calculate the height on the
staff. The duration of the note itself is not that important because
percussion has no real duration, only a start (maybe except for a roll on a
drum).
Another attribute we require is a note head. A snare drum is usually noted
using a normal note, a high-hat uses a X as a notehead.
Percussion is noted on a 5-line staff (drumset) or a 1-line staff so maybe
another attribute will tell how to handle a certain percussion instrument (= a
MIDI pitch) on a 5- or 1-line staff.
We can provide a default setting but using a simple dialog a user can modify
the setting. Mscore uses already such a dialog.
> The hardest part of all of this is deciding where to compromise to reach the
> largest number of potential users. It seems like it would be almost
> impossible to do an infinitely flexible mechanism that could take into
> account every different standard for percussion notation, and every
> different MIDI drum mapping.
By letting any user define him/her own mapping will solve this problem, isn't
it?
> We might want to settle on the most common
> standard used by the biggest majority of published drum sheet music, and
> limit the mapping to General MIDI. Or not. I can't make that call at all,
> because I know bupkis about percussion notation.
I'm not a percussionist either (I'm playing the clarinet and alto saxophone)
but I happen to be a librarian of an orchestra for some years now which gave
me access to a lot of scores, including percussion parts. And, more important,
I know some percussionists who are willing to help in notation aspects.
>
> It's just a fat lot of stuff for me to try to get my head around. The last
> time I brought this topic up, someone referred me to a 15,000-page treatise
> on percussion notation, and I decided to run away.
Percussion notation isn't that simple, I agree. But a 15.000-page treatise, I
think I would ignore it. I'm certainly not capable of implementing a
percussion notation for all kind of advanced percussion. However a "normal"
drumset part should be feasible.
>
> If we ever do have a working two bar percussion clef though, we have
> thousands of instrument presets in the "create segments with" database that
> are currently disabled.
I don't think that's required. Just one preset will do, "Percussion" which
will set the percussion clef and will force the notation editor to use the
notation-pitch instead of the MIDI pitch.
To conclude, an approach as implement by mscore should be feasible and I'm
willing to sepnt some time on this.
Best regards, Niek
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
