add articulation support to multi measure rests

add articulation support to multi measure rests

This adds an event type MultiMeasureArticulationEvent and a grob type
MultiMeasureRestScript and allows to add articulations/scripts to multi
measure rests. This means that you can use \fermata now instead of
\fermataMarkup.

\fermataMarkup is deprecated, the regression tests are updated
(convert-ly + manual changes in stencil-scale.ly and multi-measure-rest-text.ly).

[lemzwerg, 2019-04-19 15:34:25]

Without testing: LGTM, thanks!

https://codereview.appspot.com/562710043/diff/582610043/input/regression/mult...
File input/regression/multi-measure-rest-text.ly (right):

https://codereview.appspot.com/562710043/diff/582610043/input/regression/mult...
input/regression/multi-measure-rest-text.ly:20: R2.^\shortfermata
Shouldn't this be rather `\shortFermata'?

https://codereview.appspot.com/562710043/diff/582610043/scm/define-music-type...
File scm/define-music-types.scm (right):

https://codereview.appspot.com/562710043/diff/582610043/scm/define-music-type...
scm/define-music-types.scm:317: . ((description . "Articulations on multi
measure rests.")
multi measure → multi-measure

[Malte Meyn, 2019-04-19 20:58:00]

https://codereview.appspot.com/562710043/diff/582610043/input/regression/mult...
File input/regression/multi-measure-rest-text.ly (right):

https://codereview.appspot.com/562710043/diff/582610043/input/regression/mult...
input/regression/multi-measure-rest-text.ly:20: R2.^\shortfermata
On 2019/04/19 15:34:25, lemzwerg wrote:
> Shouldn't this be rather `\shortFermata'?

No, \shortfermata is the current command name. Changing it is not in the scope
of this issue (5511), but related issues are 5487 and maybe 5486: I haven’t
added script commands for very short and Henze fermatas yet.

https://codereview.appspot.com/562710043/diff/582610043/scm/define-music-type...
File scm/define-music-types.scm (right):

https://codereview.appspot.com/562710043/diff/582610043/scm/define-music-type...
scm/define-music-types.scm:317: . ((description . "Articulations on multi
measure rests.")
On 2019/04/19 15:34:25, lemzwerg wrote:
> multi measure → multi-measure

Yep. Same at line 338 and 329, that’ll be part of the next patch set.

[Malte Meyn, 2019-04-20 15:52:33]

add documentation (Changes, NR, NR-de translated, NR-otherlanguages commented
out), “multi measure”→“multi-measure”

[Malte Meyn, 2019-04-21 20:26:25]

use correct comment syntax

[dak, 2019-04-27 08:54:16]

Multimeasure rests can be split into multiple rests and across lines.  That's
what makes then a Spanner rather than an Item and is the main cause of this
complication.  How are you dealing with such a split?  A fermata only makes
sense on the last such rest, most text markups make sense only on the first such
rest.

https://codereview.appspot.com/562710043/diff/572630043/input/regression/mult...
File input/regression/multi-measure-rest-text.ly (right):

https://codereview.appspot.com/562710043/diff/572630043/input/regression/mult...
input/regression/multi-measure-rest-text.ly:19: R2._\fermata _"Ad lib"
I don't think the order of \fermata and "Ad lib" is to be determined by
LilyPond: this is a single item.

[dan_faithful.be, 2019-04-27 11:27:44]

On Apr 27, 2019, at 04:54, dak@gnu.org wrote:
> 
> Multimeasure rests can be split into multiple rests and across lines.
> That's what makes then a Spanner rather than an Item and is the main
> cause of this complication.  How are you dealing with such a split?  A
> fermata only makes sense on the last such rest, most text markups make
> sense only on the first such rest.

See Malte’s answer when I raised the same concern:
http://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00087.html
<http://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00087.html>

It’s a bit long to quote, but his major premise is that \fermata on a compressed
multimeasure rest is ambiguous to the point of being useless.
— 
Dan

[dak, 2019-04-27 11:31:24]

Dan Eble <dan@faithful.be> writes:

> On Apr 27, 2019, at 04:54, dak@gnu.org wrote:
>> 
>> Multimeasure rests can be split into multiple rests and across lines.
>> That's what makes then a Spanner rather than an Item and is the main
>> cause of this complication.  How are you dealing with such a split?  A
>> fermata only makes sense on the last such rest, most text markups make
>> sense only on the first such rest.
>
> See Malte’s answer when I raised the same concern:
> http://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00087.html
> <http://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00087.html>
>
> It’s a bit long to quote, but his major premise is that \fermata on a
> compressed multimeasure rest is ambiguous to the point of being
> useless.

But we are talking about a \fermata on an _uncompressed_ multimeasure
rest here.  If the compression leaves just a single rest, placing the
fermata does not pose a conundrum to typesetting (it may pose one to the
musician but that's entirely the composer's choice and fault).

-- 
David Kastrup

[dan_faithful.be, 2019-04-27 19:48:18]

On Apr 27, 2019, at 07:31, David Kastrup <dak@gnu.org> wrote:
> 
> But we are talking about a \fermata on an _uncompressed_ multimeasure
> rest here.  If the compression leaves just a single rest, placing the
> fermata does not pose a conundrum to typesetting (it may pose one to the
> musician but that's entirely the composer's choice and fault).

I agree, though I won’t suggest that the issue should block acceptance of this
patch, since \fermataMarkup had the same problem.  Treating it as a known issue
would be nice.
— 
Dan