|
|
Created:
6 years, 3 months ago by Malte Meyn Modified:
6 years, 2 months ago CC:
lilypond-devel_gnu.org Visibility:
Public. |
Descriptionissue 3208: MMRs for > 1 m. only count m.
MMRs with measure-count == 1 (single whole measure rests) don’t change
their behaviour (i. e. they respect measure length when choosing the
displayed rest symbol).
MMRs with measure-count > 1 now only respect measure-count and don’t
scale that by closest_duration_log which depends on measure-length.
What do Gould et al. say about the whole issue? I don’t find the discussion on the tracker very clear
Patch Set 1 #Patch Set 2 : use only whole rests and longer #Patch Set 3 : add regtest #
Total comments: 1
Patch Set 4 : small whitespace correction #
Total comments: 1
Patch Set 5 : move round-up-to-longer-rest to calc_closest_duration_log and improve regtest #MessagesTotal messages: 23
use only whole rests and longer
Sign in to reply to this message.
On 2017/12/26 12:13:50, Malte Meyn wrote: > use only whole rests and longer If we only count measures and don’t look at measure counts, a whole/breve/longa/maxima rest always represent 1/2/4/8 measures so it doesn’t make sense to use shorter rests. This respects MultiMeasureRest.usable-duration-logs but only for duration-logs <= 0. Should it disrespect it completely (and only use that grob property for single whole measure rests)? I think not.
Sign in to reply to this message.
Could you provide an image?
Sign in to reply to this message.
On Dec 26, 2017, at 08:41, lemzwerg@googlemail.com wrote: > > Could you provide an image? > > https://codereview.appspot.com/333340043/ While you’re at it, could you add a regression test to your patch? (Or is there already a regression test that demonstrates this bug?) Regards, — Dan
Sign in to reply to this message.
On 2017/12/26 13:41:16, lemzwerg wrote: > Could you provide an image? Done at the tracker. Note that the image shows another bug: half rests are shown as whole rests because of buggy staff-position. This explains the weird 15 bar rest for 1/4 time. I’ll add a regression test. Can anyone ask Gould about this topic? My patch follows Phil’s comment on the tracker from 2013 ;)
Sign in to reply to this message.
add regtest
Sign in to reply to this message.
----- Original Message ----- From: <lilypond@maltemeyn.de> To: <lemzwerg@googlemail.com>; <dan@faithful.be> Cc: <reply@codereview-hr.appspotmail.com>; <lilypond-devel@gnu.org> Sent: Tuesday, December 26, 2017 2:53 PM Subject: Re: issue 3208: MMRs for > 1 m. only count m. (issue 333340043 bylilypond@maltemeyn.de) > On 2017/12/26 13:41:16, lemzwerg wrote: >> Could you provide an image? > > Done at the tracker. Note that the image shows another bug: half rests > are shown as whole rests because of buggy staff-position. This explains > the weird 15 bar rest for 1/4 time. > > I’ll add a regression test. > > Can anyone ask Gould about this topic? My patch follows Phil’s comment > on the tracker from 2013 ;) > > https://codereview.appspot.com/333340043/ AFAICS Gould is not explicit on the correct handling of MMRs like this. -- Phil Holmes
Sign in to reply to this message.
LGTM! https://codereview.appspot.com/333340043/diff/40001/lily/multi-measure-rest.cc File lily/multi-measure-rest.cc (right): https://codereview.appspot.com/333340043/diff/40001/lily/multi-measure-rest.c... lily/multi-measure-rest.cc:298: int dl = min(0 , calc_closest_duration_log (me, measure_count, false)); min (0, calc_...)
Sign in to reply to this message.
small whitespace correction
Sign in to reply to this message.
On 2017/12/26 21:41:26, Malte Meyn wrote: > small whitespace correction ('j')
Sign in to reply to this message.
https://codereview.appspot.com/333340043/diff/50003/input/regression/multi-me... File input/regression/multi-measure-rest-measure-length.ly (right): https://codereview.appspot.com/333340043/diff/50003/input/regression/multi-me... input/regression/multi-measure-rest-measure-length.ly:16: \override MultiMeasureRest.usable-duration-logs = #'(2 1 0 -1 -2) Seeing this override in a test raises the suspicion that it is a prerequisite for correct output, leading to doubts that lilypond performs as expected in the default case. It's not my place to give commands, but consider testing each case separately: one demonstrating that lilypond works by default, and another demonstrating that it handles overrides correctly. Another thing I see is that calc_closest_duration_log() also uses the property round-up-to-longer-rest. If this were my change, I would try to satisfy myself that there won't be any unwanted interactions with that property, and possibly cover it in a regression test if it seems easy for the next person to break.
Sign in to reply to this message.
On 2017/12/27 22:52:06, Dan Eble wrote: > Another thing I see is that calc_closest_duration_log() also uses the property > round-up-to-longer-rest. If this were my change, I would try to satisfy myself > that there won't be any unwanted interactions with that property, and possibly > cover it in a regression test if it seems easy for the next person to break. Thank you for that hint. Indeed there is an unwanted interaction. The following prints two maxima rests instead of one maxima + one longa + one breve + one semibreve. I’ll have to work on this. { \override MultiMeasureRest.expand-limit = 15 \override MultiMeasureRest.round-up-to-longer-rest = ##t \time 3/1 R\breve.*15 }
Sign in to reply to this message.
While trying to fix that the following question came to my mind: Do we really want the compressed rests to respect usable-duration-logs? PRO: The user could want to be able to change the behaviour (f. e. don’t use maxima rests for ≥ 8 bars rest but two longa rests). CON: The user could want semibreve/whole rests for every time signature (including long durations like \time 17/2) but compressed rests (f. e. R2*17*6 for 6 bars rest in \time 17/2) should use longer values (a longa and a breve in this case).
Sign in to reply to this message.
On 2017/12/28 11:14:18, Malte Meyn wrote: > While trying to fix that the following question came to my mind: > > Do we really want the compressed rests to respect usable-duration-logs? > > PRO: The user could want to be able to change the behaviour (f. e. don’t use > maxima rests for ≥ 8 bars rest but two longa rests). > CON: The user could want semibreve/whole rests for every time signature > (including long durations like \time 17/2) but compressed rests (f. e. R2*17*6 > for 6 bars rest in \time 17/2) should use longer values (a longa and a breve in > this case). PRO: Backwards-compatibility in cases like { \compressFullBarRests \override MultiMeasureRest.usable-duration-logs = #'(0 -1) \time 4/4 R1*6 } (But would we want that?) PRO: You wouldn’t need another grob property if you want to change the behaviour of compressed rests. CON: You could havenother grob property and control the behaviour of single bar and compressed rests independently. CON: It’s easier to code (at least if you don’t have such an extra property).
Sign in to reply to this message.
On Dec 28, 2017, at 05:49, lilypond@maltemeyn.de wrote: > > Thank you for that hint. Indeed there is an unwanted interaction. The > following prints two maxima rests instead of one maxima + one longa + > one breve + one semibreve. I’ll have to work on this. > > { > \override MultiMeasureRest.expand-limit = 15 > \override MultiMeasureRest.round-up-to-longer-rest = ##t > \time 3/1 > R\breve.*15 > } > > https://codereview.appspot.com/333340043/ I don’t consider myself qualified to answer your questions about use cases, but _if_ it is appropriate to ignore round-up-to-longer-rest for church rests, it looks easy to achieve that by moving the following term out of calc_closest_duration_log() into its caller calc_measure_duration_log(). to_boolean (me->get_property ("round-up-to-longer-rest”) That would leave calc_closest_duration_log() doing exactly what it is told in terms of rounding. Regards, — Dan
Sign in to reply to this message.
On 2017/12/28 16:55:53, dan_faithful.be wrote: > I don’t consider myself qualified to answer your questions about use cases, but > _if_ it is appropriate to ignore round-up-to-longer-rest for church rests, it > looks easy to achieve that by moving the following term out of > calc_closest_duration_log() into its caller calc_measure_duration_log(). > > to_boolean (me->get_property ("round-up-to-longer-rest”) > > That would leave calc_closest_duration_log() doing exactly what it is told in > terms of rounding. Good idea, even if we should decide that we should ignore usable-duration-logs completely. Here comes the next patch set that does this and improves the regression test.
Sign in to reply to this message.
move round-up-to-longer-rest to calc_closest_duration_log and improve regtest
Sign in to reply to this message.
On 2017/12/26 16:03:31, mail_philholmes.net wrote: > > Can anyone ask Gould about this topic? My patch follows Phil’s comment > > on the tracker from 2013 ;) > > > > https://codereview.appspot.com/333340043/ > > > AFAICS Gould is not explicit on the correct handling of MMRs like this. I think you’re right. (I found the German translation at our university library.) For single measure rests she writes (section II.6) • semibrevis rest for any time signature • exception: brevis rest for 4/2, 8/4 and longer → LilyPond does this but adds • exception: longa rest for 4/1 and longer, maxima rest for 8/1 and longer For compressed multi measure rests she writes (section III.18) • \override MultiMeasureRest.expand-limit = [one of 1 “modern”, 9 “classic”, or 2 “many editions”] • how 2, 3, 4, 5, 6, 7, 8, 9 measure rests are written if expand-limit = 9; she doesn’t mention time signature/measure length at all here → LilyPond does this with the following exceptions • default expand-limit is 10, not 9 • the forms for 2 to 9 bars rest are only the ones shown by her for measure lengths < 2/1 until this patch comes and fixes that In section III.18 she writes something like “put a 1 above a single measure rest” and shows only an example with a semibrevis rest (without mentioning measure length) but doesn’t do that in II.6 …
Sign in to reply to this message.
On 2018/01/03 20:37:33, Malte Meyn wrote: > I think you’re right. (I found the German translation at our university > library.) > > For single measure rests she writes (section II.6) > • semibrevis rest for any time signature > • exception: brevis rest for 4/2, 8/4 and longer > → LilyPond does this but adds > • exception: longa rest for 4/1 and longer, maxima rest for 8/1 and longer > > For compressed multi measure rests she writes (section III.18) > • \override MultiMeasureRest.expand-limit = [one of 1 “modern”, 9 “classic”, or > 2 “many editions”] > • how 2, 3, 4, 5, 6, 7, 8, 9 measure rests are written if expand-limit = 9; she > doesn’t mention time signature/measure length at all here > → LilyPond does this with the following exceptions > • default expand-limit is 10, not 9 > • the forms for 2 to 9 bars rest are only the ones shown by her for measure > lengths < 2/1 until this patch comes and fixes that > > In section III.18 she writes something like “put a 1 above a single measure > rest” and shows only an example with a semibrevis rest (without mentioning > measure length) but doesn’t do that in II.6 … is there an example where a single measure rest looks different standing alone than one in an expanded multi-measure rest of odd measures?
Sign in to reply to this message.
On 2018/01/04 19:48:36, benko.pal wrote: > is there an example where a single measure rest looks different standing alone > than one in an expanded multi-measure rest of odd measures? Not in Gould’s “Behind Bars”, neither in Gardner Read’s “Music notation”. They both don’t mention compressed rests in combination with longer measures. I’ve got the impression that neither LilyPond’s current behaviour nor my suggested patch are optimal. I’ve sent this question to some major music publishers, maybe they can help ;)
Sign in to reply to this message.
2018-01-06 17:48 GMT+01:00 <lilypond@maltemeyn.de>: > On 2018/01/04 19:48:36, benko.pal wrote: >> >> is there an example where a single measure rest looks different standing alone >> than one in an expanded multi-measure rest of odd measures? > > Not in Gould’s “Behind Bars”, neither in Gardner Read’s “Music > notation”. They both don’t mention compressed rests in combination with > longer measures. > > I’ve got the impression that neither LilyPond’s current behaviour nor my > suggested patch are optimal. I’ve sent this question to some major music > publishers, maybe they can help ;) Great, I hope some of those will reply. My entirely irrelevant preferences lean towards the current behaviour; I expect it matches Bach's practice (relevant principles of mensural notation were sort of known), but I know it doesn't match modern printing. Of Werner's examples I prefer the Saint-Saëns one (do the same as for common bar lengths as 4/4 or 3/8, but mark every single full measure rest by an explicit "1") to the NBA one (I expect they avoid printing a multi-measure rest of odd length, and instead of a 7 bar rest they print a 6-bar multi-measure rest and a standalone single full measure rest; if that's really so, it would be quite a big nuisance to implement in LilyPond). p
Sign in to reply to this message.
Pada tanggal 8 Jan 2018 05:34, <aurana87@gmail.com> menulis: > https://codereview.appspot.com/333340043/ >
Sign in to reply to this message.
|