Scale degrees in VHV

[craigsapp]

This discussion topic can be used to discuss scale degree representations in **deg and **degree exclusive interpretations as well as rendering them in music notation with VHV. See the current documentation for scale degrees in the VHV documetation page for scale degrees.

Earlier implementation discussion can be found at this discussion page: rism-digital/verovio#3166

[craigsapp]

Here is discussion in the original thread about adding the function of a part to the scale degree spine for analysis purpose, and perhaps for display purposes as well: rism-digital/verovio#3166 (reply in thread)

In my scripts I currently hardwire the spine that I want to extract for such things. So having a descriptive *bass interpretation sounds good. At least for something like Bach chorales. With orchestral scores or even renaissance music with voice interchanges the *bass spine would not always be the lowest note (although Bassstufen probably don't have to be always the lowest notes). But as you can simply not use *bass when it's inappropriate I think this will be a good enhancement.

The same applies for "Lage" / "Diskantlage". It would be nice to have it as you can still not use it if inappropriate. Not sure what the best English translation would be. Probably *discant. With music like Bach chorales or in renaissance *cf (cantus firmus) could be interesting.

[WolfgangDrescher]

Should *dir really be enabled by default? I mean it's not a problem: if you do not encode them in a **deg spine they will not be displayed. In any case the new humlib deg filter should have a flag to be able to add melodic approach and departure information to **deg data records or ignore them.

[craigsapp]

If there is explicit data in the token, then it seems easier to assume that it should be shown.

In the VHV version of deg, I am planning on having the default output **deg spines not include melodic contours, and you have to actively request them. So perhaps deg -a to include melodic approaches, and deg -d to include melodic departures. An additional option --xdir could be added to insert *Xdir interpretations at the start of each output **deg spine.

[WolfgangDrescher]

Okay, this sounds good. You convinced me that if melodic contours are encoded they should be displayed. Having humlib deg not to encode it by default is the better idea.

[WolfgangDrescher]

Is there anything we haven't considered yet with *minnat or *minhar when using church modes? I don't think so and as long as we use e.g. "natural" dorian as basis everything should be fine. But I have not tested this and I'm not aware if there is something like e.g. "harmonic" dorian in the original humdrum codebase.

Additionally, how should scale degrees behave when using plagal modes such as hypodorian? I think for d-hypodorian the d should still remain scale degree 1. Correct me if I'm wrong.

---

Btw. we talked about plagal modes in WolfgangDrescher/lassus-geistliche-psalmen#6 (comment). Is it standardized by now how to encode plagal and authentic ambitus? It would be important to be able to encode the ambitus as plagal or authentic separated to the general key label of something like *d:dor.

Check this example here: https://www.digitale-sammlungen.de/de/view/bsb00075346?page=91 . The ambitus of the tenor is from c' to c'' while the mode of the whole piece would be *a:aeo. But the cantus has a perfect plagal ambitus from e' to e'' and the bassus is also almost plagal but exceed the plagal ambitus by 2 notes from d to f'. A typical ambitus constellation would for this would be cantus: plagal – tenor: authentic – bassus: plagal but the tenor from c' to c'' does not really fit as an authentic ambitus.

This is why I suggest to have something like this: *d:dor (for general dorian), *d:hdor (hypo dorian; if the ambitus is clearly plagal), *d:ador (authentic dorian; if the ambitus is clearly authentic). Or maybe it's better to always encode d:dor but additionally encode something like *plagal, *authentic, *none (none is probably a bad idea as the keyword for this interpretations does not relate only to the ambitus). Or even *ambitus=plagal, *ambitus=authentic, *ambitus=none. Or maybe as local comments instead of new interpretations. What do you think would be the best solution for this?

[craigsapp]

Is it standardized by now how to encode plagal and authentic ambitus?

No, but that would be good to do. *d:ador seems good. It would be nice to postfix such information: *d:dora so that similarity to *d:dor. But also it might be good to make it more distinct such as *d:dorA and *d:dorH or *d:dor-a and *d:dor-h.

But splitting such information into a separate interpretation as you mention might be better since this information is not about pitch classes but ranges of the notes with respect to the tonic (final note).

*amb:a, *amb:h for example. It might be useful to indicate the reference pitch (so also the octave of the tonic). Also there is usually a reciting tone associated with various modes in the older system (does your later polyphonic music also use the same reciting tone, which I think not). It might be useful to either specify this reciting tone, or enable marking it in some way in **deg data, which are shown as whole notes in this chart:

from https://en.wikipedia.org/wiki/Gregorian_mode

There are also "mediants" and "participants" which could be labeled.

How would these related to scale degree analysis? I can imagine that the numbers would more absolute rather than pitch-class equivalent. For example in a hypo mode, the note below the final would be -1 rather than 7, and notes higher than an octave above the tonic would not be wrapped to scale degrees in the range 1–7.

Are you working with music that uses these modes (i.e., how strictly are they following this system?) They are not overly useful for polyphonic music (especially over time) and originate with monophonic chant.

[WolfgangDrescher]

*amb:a, *amb:h for example.

Okay this sounds good. I can use this right away without any implementation needed in humlib, right?

Probably it will also be a good idea to add something like *amb,:u for an unclear ambitus. And/or something like *amb:al and *amb:pl for authentic like and plagal like if the modes looks like authentic but it does not quite fit perfectly.

Do you want me to make a PR to document this in vhv-documentation, or is this too specific?

It might be useful to indicate the reference pitch (so also the octave of the tonic).

How do you mean this? That we can pass the finalis of the mode directly within the *amb interpretation?

How would these related to scale degree analysis?

They are not. I was just thinking about the numbers of gregorian modes and this question about the ambitus came to my mind. Should have opened a new discussion.

and notes higher than an octave above the tonic would not be wrapped to scale degrees in the range 1–7.

Usually the ambitus is not strictly bound to 1-8 and exceeds the octave. See e.g. this chart:

(Johannes Menke: Kontrapunkt 1: Die Musik der Renaissance)

Are you working with music that uses these modes (i.e., how strictly are they following this system?) They are not overly useful for polyphonic music (especially over time) and originate with monophonic chant.

In my case (https://github.com/WolfgangDrescher/lassus-geistliche-psalmen) the ambitus is not really strictly following a schema. Sometimes it's more more than an octave, sometimes it's less. That's why I want to calculate by how much the expected plagal or authentic ambitus is exceeded.

[craigsapp]

Okay this sounds good. I can use this right away without any implementation needed in humlib, right?

Yes

Do you want me to make a PR to document this in vhv-documentation, or is this too specific?

Yes, that would be good so that people will use the same system and then everyone's data could be shared with a common system of describing ranges. Ideally you would write a tool called amb (or ambitus) which would insert *amb: interpretations into the score, and then document the syntax for description of ranges on the documentation page for that tool. The functionality would be similar to the prange tool, but in this case labeling the input score rather than extracting data for further analyses.

There could also be more markup added, such as encoding the highest and lowest pitch for each staff in a score, or something like +2 to mean that there are two steps above the standard range (for things like authentic-like), and -2 for an additional two scale degrees below the standard range: amb:la-1+2.

How do you mean this? That we can pass the finalis of the mode directly within the *amb interpretation?

For music in authentic or hypo, the 1–7 scale degrees are not as interesting as there positions including octaves. So in C major, with the tonic note (finalis) being C4, it is probably better to use ~7 for B3 rather than just 7 (which could be B3 or B4 or B5, etc.). Or B3 could be ~1 since it is one scale degree lower than the C4 reference note. B4 would be 7, B5 would be 14 and B2 would be ~8 and C3 would be ~7 (so a bit confusing since C5 would be 8).

They are not. I was just thinking about the numbers of gregorian modes and this question about the ambitus came to my mind. Should have opened a new discussion.

That is good in that we can avoid thinking about it for deg and implement another tool such as chantdeg or some other name to deal with this sort of system of recording the scale degrees relative to the tonic note of the range.

Usually the ambitus is not strictly bound to 1-8 and exceeds the octave. See e.g. this chart:

Yes, that is related to my question about how to indicate the scale degrees outside of an octave for such cases, where it would be interesting to know which octave the scale degree is in. This is similar to the --octave option, but the octave information only implies where it is in the range, which would require further analysis to label in a more absolute way instead of a pitch-class way.

That's why I want to calculate by how much the expected plagal or authentic ambitus is exceeded.

That would be something useful to add and what the discussion is about. Another possibility is that there could be an option to give relative octaves: The default octave would be implied as "0", then there could be an octave modifier when it is not in the standard octave of the authentic mode. For example B3 in C major where the reference note is C4 would be labeled as 7/-1 since it is the 7th scale degree in the octave below the reference octave. C5 would be 1/1 for the first scale degree, but one octave higher.

[WolfgangDrescher]

Should accidental display be shown by default before the scale degree and arrow display of the same information after? If so, then *accrev could be invented to reverse the accidental display: move the accidental after the degree or move the arrow before the degree.

I asked my colleagues in Freiburg and they all agreed with me: accidentals should be in front the the scale degree number and arrows should be after the number. So implementing this and introduction something like *accrev sounds like a good idea.

[craigsapp]

A related question that would be good to clarify is: is the accidental relative or absolute. In other words, in the key of D major, should the lower third scale degree (3-) be displayed as flat-3 (flatted by one semitone relative to the expected F# for 3), or as natural-3 (relative to the pitch class F-natural).

For arrows it is clear that it should be relative so "3↓". Also, would there be two different styles for accidentals to select from: "♭3" and "♮3"? To me the flat (relative) version makes more sense: The scale degree is a flat third.

[WolfgangDrescher]

A related question that would be good to clarify is: is the accidental relative or absolute. In other words, in the key of D major, should the lower third scale degree (3-) be displayed as flat-3 (flatted by one semitone relative to the expected F# for 3), or as natural-3 (relative to the pitch class F-natural).

Good question. I think with Bassstufen it should be relative. So the f in D major should be displayed as natural-3. But there may be exceptions as the #4 while being in a key designation with flat accidentals, similar to 17th century notation accidentals that we already discussed in rism-digital/verovio#3166 (reply in thread). So maybe it's a good idea to make this configurable?

[craigsapp]

Thinking about this more, in my opinion the accidentals should be displayed relative to the mode's default positions and not in absolute pitch mode, since they are functional labels.

Good question. I think with Bassstufen it should be relative. So the f in D major should be displayed as natural-3.

I think you are reversing the absolute/relative terms as I am thinking of them. I am thinking of absolute being what the accidental of the pitch class. Calculating the accidental to display in this case would be complicated, but not overly so. For example as above, an F in D major would be displayed as a natural-3. To calculate this I would have to look up the normal position of the 6th scale degree in D major. It is F#, so if the F is not sharp, I would display the sounding (absolute) accidental for the 3rd scale degree, which would be natural. There is also a bit of confusing about displaying the D major scale degrees in a key signature other than one with two sharps. If the music were in D major, but the key signature had one flat, then what should the accidental be? I presume it would still be natural-3.

Relative for me means that the accidentals would be the same in all key designations and key signatures. I.e., the accidental is relative to the default chromatic positions of the scale degrees, so an F note in D major would be one semitone lower, meaning a flat-3 because it is a flatted F-sharp.

I have been moving recently and do not have all of my books out. The music theory books I have, rarely give scale degrees (they only give chords). I will have to look at some more to see if there is a standard convention.

So perhaps "relative" mode as I define it should be the default (and is identical to the chromatic alterations markers in the **deg data. In any case, maybe better terms than "absoute" and "relative" could be avoided in favor of some other terms.