-
Notifications
You must be signed in to change notification settings - Fork 971
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Just intonation and non-western systems #1723
Comments
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) |
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:
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 |
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.
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.
Right, we already support this. |
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! |
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: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:
intervals='mela22'
orintervals='kanakangi'
would make a 7-bin interval set. Would this be useful?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?
intervals_to_svara
which would drivehz_to_svara
just ashz_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)
The text was updated successfully, but these errors were encountered: