[email protected] wrote: > I might propose a follow-up patch, to clarify in > define-music-properties.scm that the 'volume' property affects the > "note-on-velocity", as it should to represent an accent, rather than the > "channel volume" of the channel. People who care about the midi output > are likely to care about that distinction. > > I would need, however, an appropriate new name for the property, and the > best I can think of now is 'strength'.
Is “relative-volume” clearer? Also, should it have something like “perform” in its name (or “midi”, like the midi* context properties) to make it easy for users looking for a layout property to ignore it? The trouble with calling it ‘velocity’ is that dynamics currently also set velocity rather than channel volume, which is why they can't change the volume in the middle of a note. (There's code for using the channel volume, but it's disabled, apparently because of bugs?) Also users might expect velocity to be an absolute MIDI velocity of 1 to 127 rather than something relative to the dynamic. Should the type predicate for numeric properties be ‘real?’ or ‘number?’? I used ‘real?’ (since complex numbers don't make sense as volumes), but the existing properties use ‘number?’, which may be more comprehensible to users. I'm working on supporting multi-note articulations like trills and mordents. For them, perform-note needs to take a note-event, not just a length, so it knows the pitch. (It can return a length, or a list of note-events.) Or should perform-length be separate from perform-note? That would make the behavior of notes with multiple midi-affecting articulations more predictable. The most common combination is accent + anything else, which works fine, because multiple volume properties multiply. Combinations like \prall\staccato are unpredictable, though — the result depends on which articulation comes first. If perform-length is separate from perform-note, perform-length can just apply first. I found two bugs in the current patch: 1) A breath after a rest (or staccato) mistakenly shortens the last note, just like grace notes. 2) Looking up articulation names in the environment breaks if someone has a variable called “staccato” — which might happen if they're naming variations: plain, inverted, dotted, staccato. Redefining standard variables is not proper, but it's currently safe, so it would be nice to not break it. A cleaner alternative is to simply define dashDot = \staccato, leaving it to the user to replace both if they want to redefine an articulation. _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
