Enhancement: chained trills collision avoidance could be more accurate

Originally posted by: n.putt...@gmail.com

From #670 (closed) (and mentioned in the regression test):

3. Trill chains shouldn't overlap horizontally.

Overriding 'padding will tweak the end position, though there's no one-size-fits-all
value.

If you want this to happen automatically, that's an enhancement, since the line
spanner code does no collision checking at bounds.

The problem for trills is related to the fixed size of the trill element: since there
are no spacing rods set, the length of each trill spanner is determined by its
bounds. Since there must always be an integer number of squiggles, sometimes the
last glyph is closer to the next trill, which triggers outside staff collision avoidance.

I'm not sure what you mean by updating trillspanner-auto-stop.ly. Your snippet has
no automatic stops.

Cheers,
Neil

Originally posted by: v.villenave

auto-stop: of course. Silly me! I should've read the regtest instead of dumbly
looking at the picture.

Now I understand why it's tricky.
What I don't get is how to work around this by overriding 'padding (I get the same
ugly avoidance no matter what value I try).

Updating the issue's title to make more sense (I hope).

Summary: Enhancement: chained trills collision avoidance could be more accurate
Labels: -Type-Defect Type-Enhancement

Originally posted by: n.putt...@gmail.com

Ha, you haven't looked at the other regression test either. ;)

Try #'(bound-details right padding) = #1

Originally posted by: n.putt...@gmail.com

Issue 1303 has been merged into this issue.

Originally posted by: n.putt...@gmail.com

Issue 3127 has been merged into this issue.

Originally posted by: goo...@ptoye.com

I'm not sure that this is a nit-pick. Chained trills really need to be chained rather than overlapping. Looking at some of my printed music, trills (whether chained or not) stop well before the next note, presumably so that they don't interfere with the next trill or expression mark.

Originally posted by: tdanielsmusic

Description has changed:

Diff:

  
--- old  
+++ new  
@@ -3,21 +3,23 @@  
 *Originally created by:* [v.villenave](http://code.google.com/u/v.villenave/)  
 *Originally owned by:* [v.villenave](http://code.google.com/u/v.villenave/)  
   
-% Here we go again with [issue 670](#670):  
+~~~~  
+:::  
+% Here we go again with  issue 670 :  
   
 \version "2.13.9"  
   
-%% Uncommenting both the \`~ a' fixes the issue,  
-%% but uncommenting ragged-right \#f re-enables it\!  
+%% Uncommenting both the `~ a' fixes the issue,  
+%% but uncommenting ragged-right #f re-enables it!  
    
-\layout \{  
-&nbsp; %ragged-right = \#\#f  
-\}  
-\relative c' \{  
-&nbsp; a1\startTrillSpan % ~ a  
-&nbsp; a\stopTrillSpan \startTrillSpan  
-&nbsp; [r1] \stopTrillSpan  
-\}  
-  
+\layout {  
+  %ragged-right = ##f  
+}  
+\relative c' {  
+  a1\startTrillSpan % ~ a  
+  a\stopTrillSpan \startTrillSpan  
+  R1 \stopTrillSpan  
+}  
+~~~~  
 It's not a regression AFAICS. The \#670 example still works.  
 BTW: should trillspanner-auto-stop.ly be updated with this?

Needs: -->
Patch: -->

Originally posted by: tdanielsmusic

added Enhancement + 1 deleted label

mentioned in issue #1297 (closed)

mentioned in issue #1303 (closed)

Perhaps until someone comes up with a more sophisticated algorithm we could at least have better properties by default. Reading "Behind Bars" and looking at two very well known scores (Mozart Sonata KV545, on IMSLP, not in public domain for the USA: Neue Mozart-Ausgabe, Serie IX, Werkgruppe 25, Klaviersonaten, Bd.2 [NMA IX/25/2] (pp.122-131) Kassel: Bärenreiter-Verlag; and Stravinsky "The Rite of Spring", Dover) it seems that some of Lilypond's default properties make matters look worse by default than they could be.

Gould recommends:

"The trill line extends for the entire duration of the note".
"In the middle of the bar, the trill line continues right up to the following note-head or its accidental (if it has one)".
"The trill line stops at a barline".

Gould's recommendations are in line with both mentioned scores. Most of these criteria are met in Lilypond by setting attach-dir to LEFT and to-barline to true. attach-dir will still ignore accidentals. I don't know of a similar property that takes accidentals into account.

Compare the same measure of Stravinsky's Rite of Spring, Lilypond (v. 2.22.1, with repetition, to see the effect of to-barline set to false) vs. Dover:

You can clearly see that the trill stops before the next note in Dover and at the barline, none of which is true in Lilypond except for the last note before the final barline. Compare with both attach-dir = #LEFT and to-barline = ##t:

The staccatissimo in Dover is put above the slur, but that's a different story. Perhaps it's something also worth investigating in a different thread.

Additionally, having an afterGraceFraction of 31/32 (perhaps even a smaller fraction, instead of the default 3/4) would match very well Mozart's score and Gould's recommendation. She writes "The finishing notes of a trill or tremolo are written as grace notes and should be placed before the barline". This is common practice. Compare Lilypond's default (measure 25 of Mozart) with Bärenreiter:

Lilypond with my suggested configuration:

Gould's example of a chained trill:

Lilypond:

"My" Lilypond:

I'd be happy to make (hopefully this time a less convoluted) merge request if you agree with this.

Cheers, Martín.

That sounds a lot like #6270. I have a patch somewhere setting to-barline and attach-dir, fixing the issue with accidentals and making broken trill spanners parenthesized at the beginning of the line, but didn't submit it because we didn't reach a conclusion on the latter change ...

That sounds a lot like #6270.

Actually it doesn't; I just worked on the same things because of that issue but didn't mention it there. I should have re-read that issue, sorry.

@martinrinconbotero, your suggestions sound good, thanks for the analysis!

Whom are you addressing?

Martín, and I've just edited the comment to say so.

@jeanas if your patch fixes the issue with accidentals as well, then maybe you should submit yours, perhaps without the parentheses issue for now until an agreement is made on that latter feature?

Will do. While at it, I almost have a fix for the main issue, except that it's not fully working because the trill glyph sticks out of its bounding box.

\markup \box \musicglyph "scripts.trill"

@lemzwerg Any thoughts about that?

Well, I think the glyph dimensions are quite good for normal text:

\markup { This is the trill glyph
          \smaller \smaller \musicglyph "scripts.trill"
          in a normal sentence. }
\markup { And here in parentheses:
          \concat { ( \smaller \smaller \musicglyph "scripts.trill" ). } }

\markup { This is the downbow glyph
          \smaller \smaller \musicglyph "scripts.downbow"
          in a normal sentence. }
\markup { And here in parentheses:
          \concat { ( \smaller \smaller \musicglyph "scripts.downbow" ). } }

For comparison reasons I also show the 'downbow' glyph, which doesn't stick out of the bbox.

If you need some correction for the left side of the trill glyph, this should be done for the TrillSpanner grob – maybe using a proper markup macro/function?

Thanks. Opened !1339 (merged).

@jeanas your changes look very promising. Congratulations! Would it be possible to change the afterGraceFraction value as well? Should we leave it for later? Should I do it myself? I mean, the Mozart example I gave is, I think, a very typical situation in lots of pieces. I haven't checked what does it look like when you use a very small fraction such as 255/256 (so that passages written with an accompaniment in 32nds, like in an Adagio, for example, don't have the same problem of an "aftergrace" in the middle of a measure). In any case, that value should be substantially smaller.

The merge request is already sizable and \afterGrace is not necessarily for use in trill spanners, so I wouldn't want to add it there. Changing it would preferably be discussed in a dedicated issue -- how about creating it? (Yes, we ask people to write on the bug list; the purpose is to filter out non-bugs and reword bug reports in technical language. Since you have done good bug reports and some contributions, you could start opening issues yourself in my opinion.)

I don't think we will be able to find a one-size-fits-all value for afterGraceFraction (look at { \afterGrace 31/32 d'1 c'8 d'1 } which is a bit ugly). In my view, the solution to that problem would rather be introducing a way for bar lines and such to be placed after grace notes rather than before. Now, we're veering into issue #34 territory …

...

Le 01/05/2022 à 22:09, Martín Rincón Botero (@martinrinconbotero) a écrit :

GitLab

Martín Rincón Botero https://gitlab.com/martinrinconbotero commented on a discussion #923 (comment 931799370):

@jeanas https://gitlab.com/jeanas your changes look very promising. Congratulations! Would it be possible to change the afterGraceFraction value as well? Should we leave it for later? Should I do it myself? I mean, the Mozart example I gave is, I think, a very typical situation in lots of pieces. I haven't checked what does it look like when you use a very small fraction such as 255/256 (so that passages written with an accompaniment in 32nds, like in an Adagio, for example, don't have the same problem of an "aftergrace" in the middle of a measure). In any case, that value should be substantially smaller.

— Reply to this email directly or view it on GitLab #923 (comment 931799370). You're receiving this email because you have been mentioned on gitlab.com.. If you'd like to receive fewer emails, you can unsubscribe https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe from this thread or adjust your notification settings.

assigned to @jeanas

mentioned in merge request !1339 (merged)

mentioned in issue #6338

closed with commit 5c34ee23

changed milestone to %2.23.9

mentioned in commit 5c34ee23

Enhancement: chained trills collision avoidance could be more accurate

Child items ...

Activity