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: Dan Eble
Subject: Re: Support articulations, slurs and breaths in MIDI (issue 26470047)
Date: Fri, 15 Nov 2013 09:08:21 -0500

I am thankful for MIDI improvements in general, and for these features in 
particular.  I’m not reviewing the code, but is one thing I want to throw a 
little cold water on.

> \fermata, which needs to change the tempo


Fermata performance is not necessarily uniform.  In some music it just marks 
the end of each line of the poem, and it is left as a matter of interpretation 
whether to perform it as a long hold, an extra beat, a shortening of the note 
to breathe in tempo, or not at all.  It can vary from line to line and even for 
the same line in different stanzas.

If the performer will by default modify the tempo at fermatas, I hope that 
there will at least be a simple and documented way to suppress it at chosen 
points.

I’m curious if this patch handles offset fermatas well, e.g.

soprano = { e4 e’\fermata }
alto    = { b2\fermata }

If these appear on different staves or partcombined, what happens to the tempo? 
 In the context I have in mind, the soprano should change on the beat, 
unaffected by the alto’s fermata.

> Notes in a slur overlap slightly in MIDI output. This approximates how
> they're played on keyboards, and triggers the legato mode of many
> synthesizers. The degree of overlap is controlled by the slurOverlap
> context property.


[Uh oh, here comes the urge to rant about pianists arranging cello parts.  
Must... resist...]

As a string player, I wonder if it would be difficult to call out to a scheme 
function which receives two chords and returns the overlap, which can be 
negative to indicate that the transition must have a gap rather than an 
overlap.  I imagine that other instruments also have their own limitations when 
it comes to slurring.

Also, is overlap defined in units that are independent of tempo?  To me it 
would seem unnatural for a slur between the same two notes to overlap longer at 
40 bpm than it does at 120 bpm.  I would want my overlap function to say “this 
requires a big shift, so perform it with a 125-ms gap” rather than having to 
figure out how to express the gap in terms of the current tempo.

Thanks again,
— 
Dan

On Nov 15, 2013, at 04:30 , address@hidden wrote:

> Reviewers: ,
> 
> Message:
> Shouldn't Lilypond's MIDI output be as beautiful as its engraving
> output?
> 
> This patch is a step toward that: it makes the most common articulations
> work in MIDI without requiring the use of articulate.ly and a separate
> \score. It also overlaps notes in slurs, which gives better results on
> legato instruments (e.g. winds and strings) than articulate.ly's
> approach of shortening unslurred notes.
> 
> Since the meanings of articulations vary widely, their performance can
> be customized or disabled through properties on the articulation (and
> the parser is modified to make c-. equivalent to c\staccato, so setting
> its properties works). This is less convenient than it ought to be,
> especially for \breathe — is there a better way? Currently slurOverlap
> is a context property because I couldn't find a better place to put it,
> but maybe the other properties should also be on contexts so they're
> easier to set.
> 
> This change doesn't interfere with articulate.ly, since the script's
> output doesn't contain any articulations.
> 
> Problems:
> 
> 1) Length calculations use written durations rather than absolute time,
> which is not ideal — switching from 2/2 to 2/4 shouldn't affect the
> sound at all. I think this can be handled by looking up the tempo and
> time signature.
> 
> 2) Perform-length is not enough to support everything articulate.ly does
> — it can't express ornaments that add notes (e.g. \mordent) or change
> timing (e.g. swing). Ideally, articulations would be able to replace
> notes with arbitrary music, not just change the length. AFAICT this is
> hard to implement, because it requires feeding the replacements back
> into the performers without interfering with the ongoing iteration. (It
> also requires changing how Audio_item times are determined, so they can
> start at times other than now_mom(), but I have a solution for this.) An
> easier alternative would be to have the perform hook return a list of
> notes, but this doesn't cover \fermata, which needs to change the tempo.
> 
> 
> Description:
> Support articulations, slurs and breaths in MIDI.
> 
> Articulations and breaths can alter the length and volume of the note.
> (Breaths affect the previous chord.) This is controlled by their
> perform-length and perform-volume properties. The standard articulations
> now have these properties where appropriate.
> 
> Notes in a slur overlap slightly in MIDI output. This approximates how
> they're played on keyboards, and triggers the legato mode of many
> synthesizers. The degree of overlap is controlled by the slurOverlap
> context property.
> 
> Shorthand articulations indirect to their long versions. Previously a
> shorthand (e.g. -.) looked up its name (dashDot) to get an articulation
> name (staccato), and then created a new ArticulationEvent with that
> name, ignoring the existing global (staccato). This meant changes to
> the long names (such as adding properties) didn't affect the shorthand.
> 
> Now it looks up the articulation name to get the existing
> ArticulationEvent.
> This makes c-. behave exactly like c\staccato.
> 
> Please review this at https://codereview.appspot.com/26470047/
> 
> Affected files (+106, -31 lines):
>  M lily/audio-item.cc
>  M lily/drum-note-performer.cc
>  M lily/include/audio-item.hh
>  M lily/midi-item.cc
>  M lily/note-performer.cc
>  M lily/parser.yy
>  M ly/music-functions-init.ly
>  M ly/script-init.ly
>  M scm/define-context-properties.scm
>  M scm/define-music-properties.scm
>  M scm/music-functions.scm
> 
> 
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel




reply via email to

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