lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Support articulations, slurs and breaths in MIDI (issue 26470047)


From: Devon Schudy
Subject: Re: Support articulations, slurs and breaths in MIDI (issue 26470047)
Date: Sat, 23 Nov 2013 11:31:17 -0500

address@hidden 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]