Slur-fingering issue

I have the Engraving Option set to position fingering inside of slurs. But when I do, I get this:

Slur and fingering

Yet I read in the documentation: “By default, fingerings are positioned inside the arcs of slurs, but outside the start/end of slurs.”

The only way I can get this result for the example is to set the option to place all fingering outside of slurs or engage the “Avoid collisions” toggle in the Engrave Mode Slur Properties for each one. But I don’t want most fingering placed outside of slurs, and that is what happens if I try to add fingering inside the slur in the example:
Slur and fingering 2

I want the default setting: “By default, fingerings are positioned inside the arcs of slurs, *but outside the start/end of slurs.”

What am I doing wrong?

1 Like

I think you assigned the 4 on the F instead of the D, that’s why Dorico puts it inside the slur.

1 Like

Good guess, but no cigar. The 4 is assigned to the D.

Can you post just this example as Dorico file?

Here my version of your example. If you reset all to Factory settings, it should behave as expected.

fingering vs slur.dorico (892.5 KB)

Is what you just posted the Dorico default? The numbers are so far away from the notes.

This is what I get as default…
f
(And I concur with @Christian_R’s observation about the fingering needing to be the D rather than the F)

1 Like

But the 4 IS assigned to the D, not the F.

Yes this was default positioning. In my example I wrote every fingering for the upper voice, so it takes more space. You can easily adjust the distances as desired in Engrave/Fingering/position and also save that as your default. @Janus example shows the defaults without the other fingerings. (I can confirm that mine looks exactly as Janus, after deleting the 2,3,1,5, fingering in the middle).
@John_Ruggero if you can post your Dorico file we can have a look and help further if you need.

OK, There is some inconsistent behaviour.

I think Dorico might get confused by the flip state of the quavers in the 1st bar when applying a change to the engraving options.

Interesting, could you post an example of the found inconsistency?
I noticed only that if I flip the three eight notes upbeat, Dorico puts the 5 neatly near the notehead.

The 5 in that last example is too close to the notehead

Dorico seems to handling the slur and fingering position correctly in single-voice writing, but I am seeing other strange things in multi-voice writing, as illustrated in the lower voice in the following example:

I am using Maestro finger numbers and I have my own settings, which I wouldn’t want to change because they are giving me the results desired, aside from the current issue.

Yes indeed, the 3 should be outside the slur…
I am looking at all the options (for fingering and slurs in engrave options, and all the possible overrides in the property panel in engrave mode): and the complexity of interactions is immense (also because of the use of other different personalized options as font, spacing, density of the stave, stem directions, etc…).
Dorico offers nevertheless all possibilities for manual customization, but I agree that maybe due to the enormous complexity of all iterations there can be some inconsistencies with the default settings, if you need all automatic happening.
Very curious to hear other points of view about this subject. (with examples and cut-out Dorico files)

John, if you’re able to cut down your project to just a handful of affected bars and attach it here, I’d be happy to take a look. My guess is that the interaction of the very different bounding rectangles for those glyphs in Maestro versus the corresponding ones in Bravura, plus the subtleties of the slur routing code, are combining to produce an undesirable effect, but as Christian rightly says, the specific combination of settings and rhythmic spacing is probably responsible.

1 Like

That is very good of you, Daniel. Thank you very much. Here is an example that shows the problems:

Misbehaving Slur Example .dorico (454.3 KB)

The slur is misplaced on the last note of the slur in the upper voice and the first note of the slur in the lower voice. When only one voice is present, the slurs are correct. As I mentioned, when I activate Avoid collisions (but don’t check the box) in the Slur Properties for each selected slur, the slur ends move to the correct sides of the finger numbers.

I am also encountering a misplacement of the 1 fingering when starting or ending a beamed group on the beam side. The other numbers are placed normally:

Fingering

My X offsets in Music Symbol editor vary a bit to center the Maestro finger numbers, but there is no variation in the Y offsets that I see to account for this.

The more I look at this the more I think that the original issue has little to do with my settings and everything to do with stem direction, as mentioned earlier by Janus and Christian_R.

If the last note of a normally down-stemed slurred group has an upstem (the other notes in the group may have stems going in either direction) when the slur is on the stem side and fingerings are used, the slur is incorrectly placed. And conversely for normally up-stemmed groups:

So if two voices are used on one staff, this will affect most of the slurred groups. since stem direction is mostly reversed in that case.

I was able to “debug” the issue with the misplaced 1 finger number, two posts back. This was a problem with the Maestro glyph. For some reason, the Maestro "1 "glyph behaves differently from the other number glyphs and required Bravura invisible padding around it to behave correctly like Maestro numbers 2-5, which do not need padding

However, the main issue remains, even when a Bravura finger number is substituted for the Maestro. The slurs are pushed out of position by the finger numbers when they are on the stem side.

Bravura

In case it has a bearing on this, I just encountered the following curiosity. When an upper slur is added, the lower slur suddenly behaves as it should:

Without 2nd slur

With 2nd slur

@dspreadbury

I’m sorry to bother you with this, Daniel, but did you ever have a chance to look at my example? This is comes up constantly and requires a lot of extra work to fix.