\version "2.19.46" \header { texidoc = " LilyPond should obey the vertical positions of ties as specified with @code{tie-configuration}. Here is a counterexample, where the positions of longer ties get changed. " } \paper { line-width = 80\mm } \relative { \override TieColumn.tie-configuration = #'((0 . 1) (2 . 1) (4 . 1)) <b'^~ d^~ f^~>1 | \break q | }
So what did you expect to see? Where does the visual result differ? What does "positions of longer ties get changed" mean? From what? What are "longer ties"? With a line break? If so, which part of the ties behaves incorrectly? Before break, after break, both?
Yes, it is good and important that you include a minimal example but it doesn't replace a problem description. You assume that any person who might investigate this problem (or even just be interested enough about it to follow the bug tracker or search for similar known problems) knows exactly what
tie-configuration
is supposed to do here according to your understanding of it.At first sight I had difficulties to understand the issue, too...
Then I did some empirical research. Obviously, setting tie-configuration will result in newly calculated control-points. They are based on the car of each given pair to determine the y-values (the calculating-mechanism isn't entirely clear to me, though) and the cdr for the direction.
The NR states: "The first number indicates the distance from the center of the staff in half staff-spaces, and the second number indicates the direction (1 = up, -1 = down). "
Seems pretty clear to me. It dos not explain the calculating mechanism from getting the pairs car to the resulting control-point-value, but this would ofcourse beyond the intention of the NR.
I'd say the bad output results more in insufficient values for 'tie-configuration.
Try '((0 . 1) (3 . 1) (5 . 1)) which will almost exactly return the same output compared with not setting 'tie-configuration.
I used the following test-code:
Otoh, if the NR is not clear enough, could you suggest a better wording?
Sorry for being too sparse.
The same vertical positions of the ties before and after the break – I'm manually setting the distances, so I expect that lilypond obeys, even if the result might be suboptimal.
For short ties (as after the break), lilypond uses the positions given in
tie-configuration
, but for longer ties (I haven't tried to find out the exact length) something else influences the vertical positions, which is unexpected and thus bad. I suspect that lilypond tries to avoid that ties touch the staff lines or something like that. However, it shouldn't do that for manually positioned stuff.The line break itself doesn't matter, AFAICS. It's just a means to make the example small.
The ties before the break are not positioned as specified in
tie-configuration
.I disagree. I don't want lilypond to override my manual settings. This makes it impossible to fine-tune the vertical positions: I would have (a) to rely on trial and error, and (b) to re-do the positioning in case the layout changes.
There is somethign weird about the value of 0 in tie configuration.
If you use the following, it is respected.
\paper { line-width = 80\mm }
\relative {
\override TieColumn.tie-configuration =
#'((0.01 . 1) (2 . 1) (4 . 1))
<b'^~ d^~="" f^~="">1 | \break
q |
}
Well, from your replies so far, I must state, I completely misunderstood what this issue is about.
I hope(!) I understand better now ...
One observation, it makes a big difference whether zero is put in as 0 or as 0.0.
Compare the output for
'((0.0 . 1) (2 . 1) (4 . 1))
with the one for
'((0 . 1) (2 . 1) (4 . 1))
Bad check for exactness somewhere?
You can say that again.
lily/tie-formatting-problem.cc:1192
[...]
if (scm_is_pair (entry))
{
Tie_specification &spec = specifications_[k];
So what is the deal with "has_manual_position" as opposed to "has_manual_delta_y" ?
The doc for the property just states:
(tie-configuration ,list? "List of @code{(@var{position} .
@var{dir})} pairs, indicating the desired tie configuration, where
@var{position} is the offset from the center of the staff in staff
space and @var{dir} indicates the direction of the tie (@code{1}=>up,
@w{@code{-1}}=>down, @code{0}=>center). A non-pair entry
in the list causes the corresponding tie to be formatted
automatically.")
Obviously, somebody had a plan for something here.
It's not my plan, but I note that integer positions are the positions of note heads (because the units are half staff spaces). So perhaps the thinking is that if you use an integer, you're specifiying a standard note head position; if you use a non-integer, you're specifying an offset from a standard note head position.
Whatever plan it is/was, the following values for 'tie-configuration return different values for the control-points.
The difference is hard to see in pdf, use high resolution or read out the values with my function above.
Supporting different behaviour for both inputs does not do a favour to anyone.
I suggest we take the input, may it be exact or not, as what the user wants. Not further fiddling around with it in any way.
I fully support that, and thanks to all for helping with the issue and identifying the cause.
I've just found the
tie-manual-vertical-tune.ly
regtest. After some thinking I believe that Han-Wen's idea is sensible and useful. Maybe it's sufficient to simply document it? We might decide on a different interface later on in case someone comes up with something better.If you agree, I'll provide a documentation patch.
At leat the description in said regtest is wrong:
It's rather a matter of exactness:
And what to do with (/ 4 5)?
Well, the description of the regtest sounds sensible :-) Would it be possible to change the code so that it does exactly what the regtest talks about, i.e., only making a difference between an integer (i.e., a number without a decimal point) and a float?
What about the following ad-hoc code to test for exact integers?
Where does that leave the people with fractional use of bar lines, like various "uniform" systems for the chromatic scale?
I think that as long as we stay with a single property with multiple meanings, the current behavior might make sense. I just don't think that staying with a single property with multiple meanings is doing anybody a favor here.
I fully agree that a better, generalized interface might a good idea. However, the above only tries to make the implementation work as described in the regtest, which is better than the current state, I believe. Note that I'm not happy about the ad-hoc integer constants -10000 and 10000; any suggestions how to improve that?
I'm very bad at designing interfaces, so I leave a fundamental fix to the issue – in case there is a desire to do this – to other people.
Because? It complicates the test and creates a condition that may be slightly easier to state in informal words and harder in Scheme.
So you prefer the opposite? Fixing the description of the regtest (plus documenting this feature)? I don't have a preference here.
If those are the only two considered options, I think I prefer going with keeping the behavior and changing the documentation.
But frankly, this is an abomination. A user should just be able to tweak the ties individually and be done (and then relative position is available anyway via
\offset
without requiring extra folderol). The wholetie-configuration
thing stinks.If that's not on the table, I think I prefer going with changing the documentation. One slight advantage is that we don't get any incompatibilities until we indeed change this to work via per-tie tweaks.
I think that the best thing to do is change the documentation so instead of saying integer or non-integer, we say exact or non-exact. That allows fractional spaces; they just have to be exact fractions, which Scheme (and hence LilyPond) can handle.
Sounds like we're agreed just a doc change is required at this stage.