Just intonation and non-western systems

[bmcfee]

Forking this issue off from a side discussion in #1402. Now that we have a pretty stable implementation of VQT, just intonation interval construction, and translation of these intervals into western notation (via FJS), we should circle back and fill in the implementation for Indian notation systems (and others that we might want to support going forward).

Tagging @kaustuvkanti @sertansenturk @vrangasayee @hideodaikoku @hskaushik for any insight they might have here.

Carnatic notation

Back in #641 we made an early decision to lock down to an ET grid and treat svara the same way we do pitch classes in western notation. That is, Ri1 and Ri2 were treated as different spellings of the same pitch class dependent on the raga, just like C# and Db would be enharmonically equivalent and choice between the two is governed by key.

However, if we adopt the 22 sruti scheme, we now have the option to treat this a bit more carefully, since it separates Ri1 = 32/31, Ri2=16/15, etc. This is similar to how we can now separate C# from Db in a JI system.

It would be easy enough to add intervals='sruti22' as an option to VQT, equivalent to:

intervals = [1, 32/31, 16/15, 10/9, 9/8, 32/27, 6/5, 5/4, 81/64, 4/3, 27/20, 45/32, 64/45, 3/2, 128/81, 8/5, 5/3, 26/16, 16/9, 9/5, 15/8, 31/16]

This is not something easily generated by the crystal algorithm, but it seems to be well-enough established that we can just hard-code it.
This would give us a 22-bin-per-octave representation that would be (i think?) universal at least for the melakarta system.

It does lead to some interesting API questions though. A few thoughts:

1. We could think of the full sruti22 set as akin to a "chromatic" base representation. Note that many of the intervals are very close to each other, which will wreck the time resolution of the VQT (ie we'll need very wide filters to distinguish them). If a user knows which raga they're working with though, we could provide a more "diatonic" interval set based just on those in-raga intervals. These could be keyed on raga name or number, just like we do for svara spelling already, eg intervals='mela22' or intervals='kanakangi' would make a 7-bin interval set. Would this be useful?
2. If we do the above, it seems like not a huge jump to do similar things for western notation. Eg, intervals='major', intervals='dorian', etc. These again would be hard-coded to a fixed set of 7 intervals per octave.

Would these be useful? One potentially non-obvious implication is that it would smear together out-of-key notes, rather than omit them. Maybe that's okay?

3. Separating out these svara classes does raise some questions about note spelling, that will run us into similar territory to the SPN vs FJS conversions earlier in-thread. I imagine that what should happen here is a separate conversion function intervals_to_svara which would drive hz_to_svara just as hz_to_fjs above.

This would be easy enough to implement, but we'll need to be a little careful in how this gets wired up to axis decorations. We currently use mela_to_degrees to pluck out a subset of 12 to decorate. I expect that we might want to expand this to have an option of selecting from 22 instead of 12, but maybe there's a simpler path forward that I'm not seeing just yet.

Hindustani notation

I imagine that most of the above observations for Carnatic would generally apply to Hindustani as well (with appropriate modifications), though I'm less familiar with the details there. Any help thinking this through would be much appreciated!

Makam

Way out of my element here 😅 but I think it would be within reach. Is there a good reference we can rely on for interval sets and notation here?

Originally posted by @bmcfee in #1402 (comment)

[bmcfee]

And followup comment:

In #641 we made a conscious decision to simplify things to a 12TET base, following this comment from @kaustuvkanti : #641 (comment) - essentially, the svara are treated unambiguously for Hindustani notation, and as enharmonics determined by the provided melakarta raga for Carnatic. (This too is a limitation, but seems to be a reasonably one.) This actually is an approximation, as svara that map to the same 12TET interval (eg R2 and G1) derive from different ratios in the 22 sruti scheme.

It's now possible to construct a VQT using exactly the sruti22 interval set - it might make sense to pack that as a predefined collection. If we do that, we could then extend the unit converters (or implement new ones) to notate Svara without quantizing through a 12tet grid.

I guess this would end up implementing a function like mela_to_sruti, which converts a mela string / number specification to a subset of the 22 intervals, analogous to how key_to_degrees takes a key specification (eg Eb:maj) and returns a subset of pitch class indices. We could then have sruti_to_svara (? I'm not sure that's a coherent name) that would translate an interval index to notation. This would serve as an alternative to mela_to_svara. I'm not sure yet how this would thread through the rest of the API, but I wanted to get opinions before marching down this path.

Originally posted by @bmcfee in #1402 (comment)

[sammlapp]

Hey @bmcfee, I randomly happened upon this thread and am fascinated/excited that you're heading in this direction. I'm by no means an expert on Maqamat, but have a couple of thoughts on that front:

• from my understanding, the intervals used in maqam-based music are not considered to be flexible and non-discrete, rather than a discrete set of notes fixed at harmonic ratios
• maqamworld is the best online source for audio recording examples of maqamat and jins (half-scales of 3-5 notes analogous to tetrachords in Western music)
• Maqamworld's definition of a maqam reveals that maqamat are not just collections of intervals: "a set of notes with traditions that define relationships between them, habitual patterns, and their melodic development.” They also mention that the tuning of so called "quarter tones" in maqamat, and of maqamat in general, is not equal tempered, and is learned by ear
• Note that maqamat (plural of maqam) have different constituents when ascending vs descending (like the "melodic minor" scale of Western classical music theory)
• Quantitative analysis from my undergraduate thesis research supported these ideas. I found highly variable, even continuous, intonation in Arabic music performances vs much more discretized intonation in Western music performances (see Fig 9.2)

On a completely different note but also mentioned in my thesis, I've read that Chinese music traditionally draws from a 12-note "chromatic scale" built from consecutive perfect fifths (3:2, etc), an interesting variant of "just intonation" (maybe also called Pythagorean tuning?). Reference is Joseph Needheam, Wang Ling, and Lu Gwei-Djen. Science and civilisation in China. Physics and physical technology, 4:563, 1971. ISSN 0717-6163. doi: 10.1007/s13398- 014-0173-7.2. P 175

[bmcfee]

• nderstanding, the intervals used in maqam-based music are not considered to be flexible and non-discrete, rather than a discrete set of notes fixed at harmonic ratios

Sure, but isn't this generally consistent within a single performance? That's all we really need here. If intonation varies within a performance, I don't think there's anything coherent we can do short of a time-varying analysis.

• They also mention that the tuning of so called "quarter tones" in maqamat, and of maqamat in general, is not equal tempered, and is learned by ear

Yeah, that's exactly the point I'm getting at. We now have functionality that supports chroma-like representations for arbitrary interval sets (assuming octave equivalence though, because how would chroma work without it?) - and not just equal temperament. The point of this issue is to discuss functionality we can build out on top of it to make it a little easier to use for certain music traditions, eg by including pre-computed interval sets, notation converters, etc.

I've read that Chinese music traditionally draws from a 12-note "chromatic scale" built from consecutive perfect fifths (3:2, etc), an interesting variant of "just intonation" (maybe also called Pythagorean tuning?).

Right, we already support this. intonation='pythagorean' allows only intervals of the form 3^n / 2^m. This differs from 3-limit just intonation, which also supports reciprocals (perfect fourths) of the form 2^n / 3^m.

[sammlapp]

Oh cool. I think Maqam intonation varies within a performance, but I’m not sure to what extent. I agree it would be really cool to support these types of tuning systems, didn’t mean to vote against the idea or anything. It will be interesting to see what kinds of tools you develop!