Glissando entry/engraving and playback issues

Currently, there are a number of issues with how glissandi are handled in Dorico.

Regarding entry/engraving:

If glissandi are created by typing gliss the ornaments popover, Dorico will always input a straight glissando line regardless of the Engraving Options>Design>“Glissando line appearance” setting as it toggles the Properties Panel>Glissando Lines>“Glissando Style” on and defaults to a straight line, effectively overriding the global Engraving Option.

Typing glisswavy inputs a wiggly glissando line in the same manner, which is a good feature to have to force a wiggly line if overriding the default is desired, but it should be accompanyied by a similar indication (eg. glissstraight) to force a straight line when “wiggly” is the default.


Regarding playback:

Aside from echoing the request for specifying the type of glissando playback (Black Notes, White Notes, Chromatic Notes, Continuous and Instrument Specific options eg. Harp pedals), I’d like to say that currenly, the most opaque aspect of glissando playback is the Delayed playback feature.

First, the Properties Panel>Glissando Lines>“Delay” setting is virtually impossible to use correctly without looking at the manual, as there is no indication as to what the number means within the program.

Displaying the units next to the value would go a long way to fix this, however, I think the Dorico team should reconsider their current choice of unit (fractions of a quarter note) for this setting.

For example, if I want a glissando to start on the last semiquaver of a note that’s a dotted minim in length, I currently have to convert to “international” rhythm names (1/16 and dotted 1/2 notes, respectively) work out that I want the gliss to start on the 11th 1/16 of the dotted 1/2 (11/16) then arbitrarily multiply that by four to get the value that Dorico expects (11/4 or 2[3/4]). This only gets more complicated if tuplets are involved or when working in compound/irregular time signatures.

The simplest fix would seem to be to have Dorico change to using “fractions of a whole note” for at least the user facing units. Down the line, it’d also be nice to be able to specify a relative start point (eg. if I wanted the gliss to start 3/4 of the way through a dotted half note, inputing 1/2 would start the gliss on the ninth 16th of the note).

Second, the Properties Panel>Glissando Lines>“Delayed Start” toggle, is quite confusing.

Toggling it “on” defaults to starting the playback halfway through the note’s duration, which is a fairly sensible default for notes that last less than a second, but comically bad for notes much longer than that given the chromatic playback. As the “Delayed Start” toggle defaults to starting playback of the gliss halfway through the note’s duration, the current default “Delay” value (0) implys that a positive value will delay the start by an unspecified amount after the halfway point and a negative value will start the gliss somewhere between the start of the note and the halfway point (I’d intuit this to be on a scale of -1 [no delay] to 1 [effectively no gliss]).

On the flip-side, I’ve frequently found myself trying a number of different “Delay” values and wondering why none of them have any effect only to realise that the “Delayed Start” toggle is still set to “off”.

The obvious solutions would either be to combine these into one property (like the Properties Panel>Notes and Rests>“Playback start offset” property) or hide the “Delay” property until the “Delayed Start” property is toggled “on” (like the Properties Panel>Harmonics>“Type” property. In both cases the default “Delay” value ought to relate to the default playback behaviour.

I’ve never used the delay feature; thank you for calling attention to it. But the flip side of this is how a live instrumentalist would know how long to delay without seeing some other visualization of the timing. I customarily use a note tied onto the end of a held note to indicate where the gliss should start.

That’s too much to type for me, and I typically want wavy, so I added the following to the kWriteMode context of my user keycommands file:

Now Shift+W simply inputs a wavy gliss on my system.

1 Like

That’s indeed one workaround.

The popover tokens for glisses would benefit from being reworked as well.

Perhaps:

  • gl, gli and/or glis would be handy for creating a gliss line that respects the Engraving Option
  • gliss, glissstr and/or glissstraight would work for forcing a straight gliss line
  • glissw and/or glisswavy would work for forcing a wavy gliss line

On that subject, the terminology around what a ~~~ line is called ought to be standardised across Dorico (ie. is that a “Wiggly Line” or a “Wavy Line”?).

Live musicians have the benefit of being able to coordinate verbally or with gestures as to when to start a gliss whereas Dorico (and other software) cannot.

The default playback for a whole note G4 glissing to a note an A4 above is rendered as a G4 half note, a G#4 half note and then the A. If the destination is changed to a B4, then it plays four quarter notes (G4, G#4, A4, A#4) before landing on the B4, or a G4 half note followed by 3 quarter note triplets (G#4, A4, A#4) with “Delayed Start” toggled “on”.

I can’t say that any live performer would choose to play a gliss either of these ways except at very fast tempi (eg. a bar of 4/4 that’s fast enough to be conducted/felt “in 1”).

The notes are so long for small glisses, that I’ve nearly torn my hair out trying to track down why a chord that looks correct on the page has clashing or wrong harmonies, or similarly trying to find where the errant rhymic patterns are coming from, only to find it was one of these short glisses.

Thanks for the feedback. The fact that you always get a property override for a glissando has been pointed out before, and it’s something we intend to change in future. We’ll think about your suggestions for how to improve the Delay property.

Thanks.

Another thing that I’ve discovered is that the delay is calculated from the start of the last note in a tie chain, which seems like a sensible default (though I can think of situations where calculating from the start of the tie chain would be more appropriate), but this behaviour is not documented anywhere as far as I’m aware.

It’s documented here:

1 Like