Notating 240 < 12n < 312 EDOs

[רועיסיני]

Just out of curiosity, how would one notate EDOs that are small enough so that 12edo's fifth is still the best fifth they have, suggesting a 12EDO-Relative notation, but have too many steps to the semitone for the Trojan set to be able to distinguish between all of them, namely 252edo, 264edo, 276edo, 288edo and 300edo?
Thanks!

[Dave Keenan]

Just out of curiosity, how would one notate EDOs that are small enough so that 12edo's fifth is still the best fifth they have, suggesting a 12EDO-Relative notation, but have too many steps to the semitone for the Trojan set to be able to distinguish between all of them, namely 252edo, 264edo, 276edo, 288edo and 300edo?
Thanks!

I would apply the Trojan capture-zone boundaries, and where two adjacent degrees end up with the same symbol, I'd give that symbol to the degree that is closest to that symbol's default tone-fraction, and add a schisma accent (up or down as the case may be) to the symbol for the other degree.

The zone boundaries and defaults can be found here: https://sagittal.org/sag_12r.par

You may also be interested in:
https://sagittal.org/sag_et.par
https://sagittal.org/sag_ji1.par
https://sagittal.org/sag_ji2.par
https://sagittal.org/sag_ji3.par
https://sagittal.org/sag_ji4.par

These files are used by Scala when doing Sagittal notation.

[רועיסיני]

Thanks! That makes sense.
Are the capture-zone boundaries and the default tone-fraction the same as the symbl boundary and the common tone fraction defined here? If so, there is one issue in 264edo where both the 5 step interval and the 6 step interval fall inside the capture zone for and are equally close to it. Which one of them should be chosen then? I think I'd choose 6 steps for compatibility with 132edo (like 252 turned out to be compatible with 36, 288 with 144, and therefore also with 24, 36, 48 and 72, and 300 with 60), and it is also the choice that is consistent with flag arithmetic - we were forced to give the value of 3\264 and the value of 9\264 because these are the only edo-steps that fall in these commas' capture zones, and therefore it's better for to get the value of 6\264. What do you think?

[Dave Keenan]

Thanks! That makes sense.
Are the capture-zone boundaries and the default tone-fraction the same as the symbl boundary and the common tone fraction defined here?

Yes, they are. Although I should have said "semitone fraction" rather than "tone fraction".

If so, there is one issue in 264edo where both the 5 step interval and the 6 step interval fall inside the capture zone for and are equally close to it. Which one of them should be chosen then? I think I'd choose 6 steps for compatibility with 132edo (like 252 turned out to be compatible with 36, 288 with 144, and therefore also with 24, 36, 48 and 72, and 300 with 60), and it is also the choice that is consistent with flag arithmetic - we were forced to give the value of 3\264 and the value of 9\264 because these are the only edo-steps that fall in these commas' capture zones, and therefore it's better for to get the value of 6\264. What do you think?

Yes. That's good thinking. I had forgotten that it is essential to preserve the notation of any subsets which are themselves 12n-edos. That should even override being nearest to the common/default semitone-fraction, if there was a conflict. But I understand you to be saying that there is no conflict between these two criteria, and this tie between 5\264 and 6\264 is the nearest thing to a conflict. And the tie is broken by considering the 132edo subset.

It's good that it also gives consistent flag arithmetic, although that would be a lesser consideration than preserving 12n subsets. I note that flag arithmetic is already broken in the cases of 216edo for and 228edo for  .

But we still need the nearest-to-default criterion for those cases that cannot be decided by 12n subsets or flag-and-accent arithmetic. Please spell out the symbol sequences that you came up with.

[Dave Keenan]

Oops! I just noticed that https://sagittal.org/sag_12r.par conflicts with viewtopic.php?p=858#p858 regarding the default semitone fractions for and  .

The latest and therefore definitive version is actually here:
https://github.com/Sagittal/sagittal-ma ... ag_12r.par

It updates the short-ASCII characters and the comma interpretations of the symbols and that are used for the purpose of the Trojan notation. And, as of a few minutes ago, it corrects a typo in the semitone fraction for  .

All three agree on the symbols and their boundaries. I will ensure their other columns agree with the github version soon.

[רועיסיני]

I had forgotten that it is essential to preserve the notation of any subsets which are themselves 12n-edos.

This can't be satisfied fully, unfortunately, because 1\36 and 2\84 both use (and both edos are divisors of 252edo), and 1\72 and 1\96 both use (and both are divisors of 288edo). However, using your rule of "closest to default semitone-fraction" each time there is a conflict (in the edos in question) between two intervals from which one is from a smaller edo and the other is not, the one present in the other edo is chosen (or there is a tie), and each of these edos has only one edo with which consistency is violated (252edo has 84edo and 288edo has 96edo).

Please spell out the symbol sequences that you came up with.

Sure! I haven't written them down until now but I think this should be correct.
252edo:

               ( and  are skipped)
1 2 3 4 5 6 7 8 9 10 11 12

264edo:

                ( is skipped)
 1 2 3 4 5 6 7 8 9 10 11 12

276edo:

                ( and  are skipped)
 1 2 3 4 5 6 7 8 9 10 11 12 13

288edo:

                  ( is skipped)
 1 2 3 4 5 6 7 8 9 10 11 12 13

300edo:

                  ( and  are skipped)
 1 2 3 4 5 6 7 8 9 10 11 12 13 14

[Edit November 9th 2024: Flipped some symbol that was mistakenly typed as . I don't remember what my edit on September 10th was but I'm pretty sure it was something similarly inconsequential.]

[רועיסיני]

Actually, why is the boundary between and 3/25-ϵ and not 3/25+ϵ? Reversing that will remove an accent from 300edo's symbol sequence, and raising it above 1/8 will do so to 288edo as well and will restore its consistency with 96edo, with the price of changing the latter's symbol sequence (as well as 192edo's).

[Dave Keenan]

Thanks for explaining how they can't always be consistent with all 12n subsets. I'm glad the closest-to-default rule results in consistency with the smaller subset in both cases.

Thanks for those sequences. Another option, that would reduce the cognitive load, but would only work for even n, i.e. 264 and 288, is to notate the even degrees as for 132 and 144, and notate the odd degrees by adding upward schisma accents to those — a binary notation. 1 degree would be notated with a schisma accent beside a bare shaft  .

That idea could be extended to 252, notating it as 84 with both up and down accents — a trinary notation. Have you seen this thread? viewtopic.php?f=13&t=408

After some research, I find that the boundary between and was put at 3/25-ϵ and not 3/25+ϵ precisely to avoid assigning to 3\300. That's because is the 19/5-comma symbol and its best approximation in 300edo is 2 degrees, not 3. Its prime count vector is [-13 7 -1 0 0 0 0 1⟩. Its size relative to 700 ¢ fifths is 11.199 ¢.

However, we assigned to degrees of 228 and 240 that were not its best approximation, so why not raise the upper bound of its capture zone that little bit further to also allow 3\300? The answer is that this was the only thing preventing an accent-free notation for all 12n-edos up to n=20, whereas n>20 had more problems than that.

But you should feel free to use for 3\300 if you prefer it to  . Of course the blatant size reversal between and is another reason to minimise the use of  .

We certainly wouldn't want to change 96edo to use in place of as is a far more common symbol due to being 5-limit as opposed to 19-limit, and in the Spartan set as opposed to merely Trojan. In fact, is in what's called the Starter set (or 72edo/11-limit JI set)  .

I should mention that there was once a suggestion that since 240edo uses all the symbols in the Trojan set exactly once, the capture zone boundaries might be placed at odd half-multiples of 5 cents, i.e. 2.5 ¢, 7.5 ¢, 12.5  ¢, ... but this was rejected because, in 72edo and its multiples, it would have replaced (7-comma) with (55-comma) which is laterally-confusable with   .

[Dave Keenan]

I notice you struggling with the perennial problem of aligning the symbols with their degree numbers on the line below. You've found that the [pre] tag helps by giving us fixed width digits and spaces, but the Sagittal "smilies" (small images rather than characters in a font) aren't monospaced, so everything still gets out of sync. And when displayed in different browsers or on different operating systems, the relationship between the size of a space and the size of the sagittals can't be guaranteed.

You may also have discovered that tab characters can be used to improve the situation. However, there is no way to type a tab character into the forum's post editor. But you can paste them in. And once one is pasted, you can copy and paste it elsewhere as required. Or you can compose the entire table in a text editor that allows you to type tab characters, and paste the whole table into the forum editor when it's done.

Tabs default to every 8th position. This is too far apart for these symbol sequences, but you can change the tab size in the [pre] tag, e.g. by using [pre=4]. I had actually forgotten about that tab-size option.

Another option is to use the table tags described here: viewtopic.php?f=15&t=498
They are quite verbose, but some people may find them easier than copying and pasting tabs, and they have features like allowing you to center items above one another.

[רועיסיני]

Thanks for explaining how they can't always be consistent with all 12n subsets. I'm glad the closest-to-default rule results in consistency with the smaller subset in both cases.

It helps that 72edo (and therefore also its subset 36edo) is used to define the default semitone fractions of the commas in question.

Another option, that would reduce the cognitive load, but would only work for even n, i.e. 264 and 288, is to notate the even degrees as for 132 and 144, and notate the odd degrees by adding upward schisma accents to those — a binary notation. 1 degree would be notated with a schisma accent beside a bare shaft  .

That idea could be extended to 252, notating it as 84 with both up and down accents — a trinary notation. Have you seen this thread? viewtopic.php?f=13&t=408

Yes, I've read it because I thought that an answer for this question may be there, but I wondered if there was another solution. Also, this idea would not work for 276edo and 300edo, so even if I were satisfied with this solution there would still be a problem.

After some research, I find that the boundary between and was put at 3/25-ϵ and not 3/25+ϵ precisely to avoid assigning to 3\300. That's because is the 19/5-comma symbol and its best approximation in 300edo is 2 degrees, not 3. Its prime count vector is [-13 7 -1 0 0 0 0 1⟩. Its size relative to 700 ¢ fifths is 11.199 ¢.

However, we assigned to degrees of 228 and 240 that were not its best approximation, so why not raise the upper bound of its capture zone that little bit further to also allow 3\300? The answer is that this was the only thing preventing an accent-free notation for all 12n-edos up to n=20, whereas n>20 had more problems than that.

But you should feel free to use for 3\300 if you prefer it to  . Of course the blatant size reversal between and is another reason to minimise the use of  .

We certainly wouldn't want to change 96edo to use in place of as is a far more common symbol due to being 5-limit as opposed to 19-limit, and in the Spartan set as opposed to merely Trojan. In fact, is in what's called the Starter set (or 72edo/11-limit JI set)  .

Thanks for the information! I was just curious why you did that, but of course you have already thought about this and weighed the reasons for both sides.

Tabs default to every 8th position. This is too far apart for these symbol sequences, but you can change the tab size in the [pre] tag, e.g. by using [pre=4]. I had actually forgotten about that tab-size option.

I read some discussions in the forum where pasting tabs was mentioned, but I don't like mixing spaces with tabs so I didn't do that. I thought using [pre] solved the problem of alignment completely, and it was pretty consistent between my laptop and my phone, but I guess there are other computers for which it doesn't work. anyway, if I need to write more symbol sequences and the like in this forum I hope I'll remember the [pre=4] trick with the tabs, thanks!