Note Names / Pitch Classes

[smoge]

@rdd

About degrees & alterations & equivalence, it’s all context sensitive, which is why degrees are such a nice model?

3b is the same “frequency” as 2s if there are two steps between 2 and 3 (c.f. diatonic major), but not if there is only one step (c.f. diatonic minor), where 3b is “the same as” 2, and 2s is “the same as” 3.

Also, for people who are finickity about such things, it can be nice to tune intervals slightly differently depending on context.

Anyways, one can map between all these representation as one likes, I just wanted to say something nice about the existing pitch model, which is quite flexible, and can be quite concise.

It’s actually very ingenious, and also flexible.

[prko]

A few weeks ago I uploaded SPN and PitchClassSet, but removed them because I found some problems. I fixed them and made a Quark library related to this thread. It seems to work with the examples given, but needs more work. SPN and PitchClassSet are in this Quark library.

GitHub - prko/Notator: musicXML File Writer for sclang

Detailed help documents are provided for each class, as well as a Notator score guide!

I would love to read your feedback! Thanks!

[semiquaver]

Thinking further, its true that the default Event prototype’s degree and root system is sufficient to transcribe common practice music but there are shortcomings.

(root:1, degree:0) doesn’t know if it is C# or Db!

This is because the roots are expressed in semitones - if the roots instead were also expressed in degrees the system would be complete: (root: 1s, degree:1) would be C# (root: 2b, degree: 1) would be Db. Obviously this makes no difference in audio terms but is important for notation.

[rdd]

Yes, you’d need to another key to say which spelling to use, perhaps called “spelling”?

It could have a sane default behaviour (i.e. answering ♭ for three in preference to ♯, ie. E♭ in preference to D♯.).

Ps. I’m not entirely sure re-specifing root in scale degrees would be a good idea?

It’d connect the “key” to the “scale”?

I.e. if you changed scale from major to minor with a root of “degree three”, you’d shift from E-major to E♭-minor, not to E-minor?

Pps. For notation there would probably need to be a whole lot of additional keys, i.e. “clef” &etc. &etc.

[smoge]

I’m not sure how it works with non-standard scales. My guess is that s and b were written with et12 modes in mind, and won’t work otherwise.

a = Scale.new((0..11), 24)
b = Scale.new((0..23), 24)
c = Scale.new((0,2..23), 24)
d = Scale.new((0,4..23), 24)
Pbind(\scale, a, \degree, Pseq([0, 1, 1s, 2, 2b, 1], 1), \dur, 0.25).play;
Pbind(\scale, b, \degree, Pseq([0, 1, 1s, 2, 2b, 1], 1), \dur, 0.25).play;
Pbind(\scale, c, \degree, Pseq([0, 1, 1s, 2, 2b, 1], 1), \dur, 0.25).play;
Pbind(\scale, d, \degree, Pseq([0, 1, 1s, 2, 2b, 1], 1), \dur, 0.25).play;

[rdd]

Yes, performDegreeToKey has an eccentricity, which you can easily edit locally.

It divides stepsPerOctave by twelve, but it’d be nicer if it divided twelve by stepsPerOctave, so:

var scl = Scale((0, 3 .. 21), 24);
[0, 0s, 1b, 1].collect { | each | each.degreeToKey(scl, 24) } == [0, 0.5, 1, 1.5]

C.f.:

https://github.com/supercollider/supercollider/blob/develop/SCClassLibrary/Common/Collections/Scale.sc#L91

and

https://github.com/supercollider/supercollider/blob/develop/SCClassLibrary/Common/Collections/SequenceableCollection.sc#L703

(It’s the same difference if stepsPerOctave is twelve…)

[prko]

This is an interesting and important discussion.
I think we should also think about chords.

For example, how could we notate Ger. 6 for major and minor?
The root of Ger. 6 should be considered from two different points of view:

• Function: The functional root is the non-sounding tone, namely the diminished fifth below the lowest tone.
• Step: the lower tone that forms the augmented sixth with the other tone of the chord.

However, at the moment I think the second view of the point is enough.

The following are my thoughts:

• For musicians:
  • for minor
    [6, 8, 10, 11s] or [-2, 1, 3, 4s]
  • for major
    • [6f, 8, 10f, 11s] or [-2f, 1, 3f, 4s]
    • [6f, 8, 9s, 11s] or [-2f, 1, 2s, 4s]
  • chromatic
    [9, 13, 16, 19] or [-5, 1, 4, 7]
• for supercollider users:
  • for minor
    [5, 7, 9, 10s] or [-3, 0, 2, 3s]
  • for major
    • [5f, 7, 9f, 10s] or [-3f, 0, 2f, 3s]
    • [5f, 7, 8s, 10s] or [-3f, 0, 1s, 3s]
  • chromatic
    [8, 12, 15, 18] or [-4, 0, 3, 6]

When building a secondary Ger. 6, which should be used? one for minor, one for major or one for chromatic?

The current convention of \root and \degree for pattern in SC is not so intuitive, I think…

Anyway, my idea of a PitchClassSet and SPN is documented and can be read online.:

• PitchClassSet in Notator Quark
• SPN in Notator Quark

To see some usages in short context:

• Notator in Notator Quark
• Score Guideline for Notator

If these links does not work, you could download the files from Notator/_Help (rendered HTML) at main · prko/Notator · GitHub

Otherwise, you can install that quark:

@prko

GitHub - prko/Notator: musicXML File Writer for SuperCollider with its own music notation, similar to LilyPond. When writing a musicXML file, it also converts the input code to standard sclang code for playback via scserver. It also supports Pitch Class Set and Scientific Pith Notation to get MIDI pitch numbers (MIDI notes) or frequencies from pitch names and vice versa.

[semiquaver]

@rdd

I.e. if you changed scale from major to minor with a root of “degree three”, you’d shift from E-major to E♭-minor, not to E-minor?

I think the idea would be that the root would be in degrees relative to C (just as now it is semitones relative to C) so no spelling key would be required. (root: 1s, degree: 1s) would be C## for example.

root might also allow Symbols, so one could write: (root: \c#, degree: 3) - e#. and [3, 1, 2, 3, 5, 4, 4, 6 , 5, 5].root(\Db, 3] perhaps.

to determine additional accidentals you would have to look at the semitones in the scale degree and compare to \major - so degree 4 in Scale(\lydian) would give an alteration value of +1 for example.

@rdd

It divides stepsPerOctave by twelve, but it’d be nicer if it divided twelve by stepsPerOctave, so:

I’ll have to look at this - is this not a bug?

[smoge]

If not a bug, we could say it has space for improvements or fine-tuning

[prko]

I would like to say something related to the topic of this thread with a slightly broader and extended perspective. It would involve some radical changes, but I am sure that this change is beneficial to make SuperCollider more accessible to newcomers and also more intuitive for existing users.

Since this summer I have been trying to get musicXML out of SuperCollider. It should of course be accompanied by the concepts of music-score-similar representation in sclang, interval, pitch and so on. However, I found some conflicts with the following existing classes in SuperCollider:

• Score
• Interval
• Pitch

I had no problems with these classes before I tried to implement musicXML export from the score-like representation in SuperCollider, but now it becomes a problem.

As a teacher, I should also consider that SC newbies expect an equivalent functionality to score in SuperCollider.

So it would be nice if Score could be renamed to ScoreOSC, because then ScoreSheet or ScoreMusic could be implemented as equivalent functionality as a score for musicians.

The same concept can be applied to other class names:

Interval could be renamed to IntervalInteger or IntegerRange, because then IntervalPitch may be introduced as the equivalent of interval in music theory.

If Pitch is renamed to PitchFollower, then PitchAbs and PitchRel could be provided in conjunction with PitchClassSet. The names PitchAbs and PitchRel are the slightly varied names of the classes which suggested @semiquaver.

In Quarks, there is a Note class which represents notes in ABC notation, and a PitchClass class which performs some specific functionality internally in CTK Quarks. When adding the concepts and functionalities mentioned in this post as Quarks, there may be some duplication or inconsistencies with the Note and PitchClass classes. Actually, my PitchClassSet is renamed from PitchClass to avoid such problems. This is why I think such things should be centrally organised. At the moment I am working with the class name Notator, but it would be ideal if the developers could think together and come to an agreement.

[semiquaver]

One detail : it does seem like the Interval class is rarely used - a quick grep of the class library and Quark repo only turned up a couple of lines. I see this notation (1, 3..9) much more often…