LilyIssues / Issues / #660 ossia staff doesn't stop at correct horizontal position

Google Importer - 2009-07-07

Originally posted by: alans...@prosoidia.com

The same thing happens if, instead of removing the engraver, you remove the stencil.
As a workaround, the following code replaces the stencil with a white box that covers
the extra staff lines to the right of the bar line:

TSwo = {
\once \override Staff.TimeSignature #'X-extent = #'(0 . 1.6)
\once \override Staff.TimeSignature #'stencil = #ly:text-interface::print
\once \override Staff.TimeSignature #'text = \markup {
\with-color #white \filled-box #'(-0.7 . 3) #'(-2.5 . 2.5) #1 }
}

%%original snippet with stencil removed twice, replaced with white box the final time

\relative c'' {
\time 2/4 c2 |

<< { c2 }
     \new Staff
     { \override Staff.TimeSignature #'stencil = ##f
      c2 | } >>

<< { c2 }
     \new Staff
     { \override Staff.TimeSignature #'stencil = ##f

     c2 | \TSwo } >>

\time 3/4 c2. |
}

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2009-12-11

Originally posted by: lemzw...@googlemail.com

(No comment was entered for this change.)

Labels: -Priority-Medium Priority-Low

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-09-06

Originally posted by: dak@gnu.org

Here is a slightly less cumbersome workaround:
\relative c'' {
\time 2/4 c2 |

<< { c2 }
     \new Staff \with {
       \remove "Time_signature_engraver"
     }
     { c2 } >> |

<< { c2 }
     \new Staff \with {
       \remove "Time_signature_engraver"
     }
     { c2 \grace { \stopStaff s4 } } >> |

\time 3/4 c2. |
}

Labels: -Priority-Low

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-03

Originally posted by: dak@gnu.org

Issue 4108 has been merged into this issue.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-03

Originally posted by: dak@gnu.org

Issue 660: ossia staff doesn't stop at correct horizontal position

http://codereview.appspot.com/153960043

Labels: Patch-new
Owner: dak@gnu.org
Status: Started

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-03

Originally posted by: dak@gnu.org

Patchy the autobot says: passes tests.

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-04

Originally posted by: dak@gnu.org

Rethinking this after some experiments, this is not good at all: it stops at the barline regardless of whether or not a time/key/clef signature or something else follows, and it would be rather tricky to do that depending on the following stuff: the PaperColumn that this attaches to is the same for all staves. One could go through the PaperColumn looking for any non-empty grobs belonging to the current stuff but that seems excessive and still second-guesses the user's intentions.

So what actually should happen is that LilyPond obeys Staff.StaffSymbol.to-barline (which it apparently doesn't for some reason). Which may default to ##t if we find that convenient, though for applications like "ossia staff" you need to override other properties anyway so we might just keep it unset by default.

Labels: -Patch-review Patch-needs_work

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-04

Originally posted by: dak@gnu.org

Heed to-barline, set to #t by default, add to staff-symbol-interface for clarity

http://codereview.appspot.com/153960043

Labels: -Patch-needs_work Patch-new

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-04

Originally posted by: dak@gnu.org

Regarding the choice of having to-barline default to #t: this is incompatible to the previous behavior, but everybody reported the previous behavior as a bug. People who have built some workaround using whiteout will likely end up having problems with this choice.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-04

Originally posted by: dak@gnu.org

Patchy the autobot says: Quite peculiar problems in bar-extent.ly and magnifyStaff-staffline-thickness

Labels: -Patch-new Patch-needs_work

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-04

Originally posted by: dak@gnu.org

Inhibit default to-barline action for Staff_symbol

http://codereview.appspot.com/153960043

Labels: -Patch-needs_work Patch-new

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-05

Originally posted by: dak@gnu.org

Patchy the autobot says: passes tests.

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-05

Originally posted by: dak@gnu.org

Ok, there are 2 things I find myself wondering about with regard to this issue.

Number 1 is: with the latest addition, there is no common code path between to-barline for normal spanners and to-barline for StaffSymbol. They still serve the same purpose. Should the common name be retained or a new one coined.

Number 2 is: they don't actually serve the same purpose in all regards. The standard to-barline is only concerned about bar lines, while _this_ to-barline is actually concerned about prefatory matter. But _should_ they be about the same issue?

Here is an example where to-barline seems to be less than satisfactory exactly because it only works at bar lines:
{
b1\< | \key fis\major b1\! | b2\< \key c\major b2\! |
}

gaga.preview.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-05

Originally posted by: tdanielsmusic

Slightly off-topic for this issue, but I don't understand why the default value for Hairpin.to-barline is #t. This means hairpins cannot be made to end on the first note of the bar without an override even though they can be made to end on any other note in the bar without one. The opposite seems a more natural default, with an override being necessary only to shorten the hairpin to end just before the bar line.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-06

Originally posted by: pkx1...@gmail.com

Patch on countdown for October 9th

(also see Trevor's comment #14)

Labels: -Patch-review Patch-countdown

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-06

Originally posted by: dak@gnu.org

Issue 4108 has been merged into this issue.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-07

Originally posted by: k-ohara5...@oco.net

Re. #13,
My opinion is that the various implementations of to-barline are close enough to share a name. People often use the same word for different behaviors if the behaviors are at least analogous. Whales and fish and dogs and people all 'swim'.

The default behavior of to-barline=#t on hairpins seems reasonable. Certainly the hairpin stops before the barline in scores, and looks bad if it crosses; it often extends under the barline in parts, but does not look so bad if it stops early.

I don't think hairpins stop early if it ends on the note just after a mid-measure clef-change, or a mid-measure key-change as in #13. So again I think LilyPond is fine. I am having trouble finding examples of such cases, though, to check.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-07

Originally posted by: dak@gnu.org

> My opinion is that the various implementations of to-barline are close enough to share a name.

Actually, I think I need to get them closer. It turns out that \stopStaff in mid-bar in parallel to a key change will make the bar too short since the key change in a freshly starting bar is allowed to hang back before its time. So this "to-barline" implementation should actually only work at a barline. I have to see whether I can reliably detect the effect of the to-barline action.

The current behavior should be better than before overall, but currently there are cases where the results are undesirable.

Sigh. I don't get anything done at the moment.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-08

Originally posted by: tdanielsmusic

Re #14 and #17
I take Keith's point re Scores. As I'm mainly concerned with choral music, where there are no bar lines between the staves, I overlooked that rather ugly effect. In any case, #t has been the default for Hairpin.to-barline for many years, so simply changing it now to #f is not an option.

Trevor

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-09

Originally posted by: pkx1...@gmail.com

I'm not sure what to do with this - it looks like it can be pushed and the comments from Keith and Trevor are digressions (new tracker?).

David I am sure you will know what to do and change the tracker accordingly if it needs work or more review/discussion, however assuming nothing is to be changed the patch can be pushed as it has hit countdown. So I am changing the label to that.

Labels: -Patch-countdown Patch-push

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-10

Originally posted by: dak@gnu.org

Go through break-align-symbols. Pffft.

http://codereview.appspot.com/153960043

Labels: -Patch-push Patch-new

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-10

Originally posted by: dak@gnu.org

It's worth noting that the following score still looks hilariously absurd after the patch.

\relative {
\repeat unfold 3 {
    \new Staff { \time 6/8 \key ces\major c'4. }
    \new Staff { \key cis\major c }
    \new Staff { \key c\major c }
}
}

But that's not really this issue.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-10

Originally posted by: dak@gnu.org

Patchy the autobot says: passes tests.

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-12

Originally posted by: pkx1...@gmail.com

Patch on couuntdown for October 15th

Labels: -Patch-review Patch-countdown

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-10-14

Originally posted by: pkx1...@gmail.com

Patch counted down - please push

Labels: -Patch-countdown Patch-push

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ossia staff doesn't stop at correct horizontal position

Issue Tracker for LilyPond

Searches

Help

#660 ossia staff doesn't stop at correct horizontal position

Discussion