→ SoFLS → + = 14.730¢ + -0.833¢ = 13.898¢
The secondary comma zone of a symbol is defined as the capture zone at the precision level at which the symbol is introduced. Since is introduced at the Extreme precision level, and its capture zone at that level is from 13.420¢ to 13.842¢, its secondary comma zone is 13.420¢ to 13.842¢. So the problem is that 's SoLFS is outside that zone — just barely, but outside nonetheless.
The purpose of respecting OoBSoLFS exceptions is to ensure that the symbols used to represent swaths of pitch space do not stray too far from where one would expect they'd be given the primary commas of their key sub-symbols. This 28th mina's situation was one of only 2 spots where such an issue was identified.
So what are our options for resolving this exception?
1. Shift the boundary
This was my original proposition.
Moving the boundary up by half a mina means moving it from the 28.5th mina to the 29th mina. We usually prefer to keep the boundaries on the half-minas, so moving it onto a whole mina may be the least desirable place to move it (simple though it was for me to propose that at the time, given that I was focusing on other issues).cmloegcmluin wrote: ↑Fri May 15, 2020 3:59 pm We can't move the upper bound of any higher than 14.191¢, because the next symbol up, , has a default value of 14.191¢ coming from its primary comma, the 245C. Its sum-of-flags value is 14.307¢ (14.730¢ - 0.423¢), even higher, so we don't need to worry about it. In other words, we need to land it somewhere between 13.897¢ and 14.191¢. It looks like if you move it up by half a mina you get 14.123¢. Good enough?
Perhaps it would be slightly better if we moved the boundary to halfway in between the two commas? This is another desirable technique. Locally, of course, it's a quite fair way to distribute the space (well, perhaps it would be more fair to weight the allocation by popularity, but I digress) but it was decided not to do this everywhere in the JI Precision Level notations because a rigid equal-division based parceling of pitch space ameliorated some of the struggle with comma selection, which gets increasingly challenging and arbitrary-feeling:
It may not be too crazy to suggest that in at least this one position we may need to use comma-midpoint bounds not within one mina, but across two minas.George Secor, 2-Oct-2007 in email wrote:As I stated above, the problem is that we must then be very careful in
our choice of primary commas, because it's going to affect the location
of the symbol boundaries. The more symbols in the notation, the more
complicated (unpopular, obscure) the commas eligible for the
definitions. The more complicated the commas eligible for the
definitions, the less clear it is which of those eligible commas should
be chosen. Mina boundaries solve that problem by making boundaries
independent of comma choices (except where minas are split).
If minas are split, then they're split in order to notate some worthy
comma (which by definition excludes highly unpopular or complex commas)
from a more popular comma with the same mina boundaries. It's a simple
matter to put the sub-mina boundary halfway between these two commas,
assuming that there are suitable symbols available.
This would result in the boundary being placed at:
( + ) / 2 = (13.795¢ + 14.191¢) / 2 = 13.993¢
which indeed is high enough that 's SoLFS at 13.898¢ is in bounds, while not going so far as to surpass 14.308 or 14.191¢, 's SoLFS and primary comma, respectively.
2. Change the symbol — more complex spelling of 2-mina adjustment
As mentioned, the SoLFS for is only barely out of bounds, too big by about 0.05 cents. It's so barely out of bounds, in fact, that the next symbol down, following Sagittal's accenting conventions, is too small! Which is unsurprising, since is used as the symbol for the next mina down.
I suspected that this extremely unfortunate happening could be explained by a feature of the SoLFS calculation, that 's SoLFS would be calculated as + , i.e. that it would be relative to whatever comma represented, which might be just different enough from the comma that + represented to account for the OoBSoLFS exception. However, this suspicion was allayed when I determined that + exactly equals . So that's not the problem.
It really is just a most unfortunate alignment of the 233-EDA grid with the commas in this one spot. to jumps from 13.199¢ to 13.898¢, a 0.699¢ wide gap, which straddles all the way across that 13.842¢ - 13.420¢ = 0.422¢ zone. This swath of Extreme precision JI just happens to fall entirely in the gaps between Sagittal's accents' primary comma intervals.
Now it's important to point out that four 's do not exactly make one . Actually it's closer to five to a , despite them getting mapped to the 1st and 4th minas. Sagittal typically spells a 2-mina deviation with , rather than , obviously because the former is one mark on the page simpler (and the same is true of their inverses). But the difference in actual value between and is just enough that it would resolve the OoBSoLFS exception in this position.
To be clear, if we represented the 7/125C at the 28th mina with instead of with , we get
→ SoFLS → + = 12.777¢ + 0.833¢ = 13.609¢
which is inside the 13.420¢ to 13.842¢ bounds.
This is a possibility, but I do not recommend it, because I dislike exceptions.
3. Change the symbol — change of core
Currently, no symbol has accents totaling greater than 5 minas deviation from the core. Only one core other than is within this 5-mina range of the 28th mina and thus could be used as an alternate base for its symbol, and that core is . The core comes within 1 mina, mais ceci n'est pas une cigar. (Also it couldn't work without a DAFLL exception).
The problem I have with replacing with is that it compounds another problem I see right in this vicinity. Here is the problem:
There is only one spot in the entire Very High precision level where one cannot drop accents for a lower level, whether that lower level be High or Medium, and that is with (covering the same pitch space as the 26th and 27th minas in the Extreme precision level). In the High precision level, this area is covered by ; in the Medium precision level, this area is covered by . This is something I would like to see changed, if at all possible. I expect, given the thoroughness and methodical nature of the crafting of the precision level notations as they are now, there was quite a bit of struggle in this territory, and good reason to prefer this outcome, but I don't know what that was and I can't suss it out myself.
And the way replacing with compounds that problem is this: it would introduce a second example of this very DAFLL exception, its mirror image in fact. Now an accented would overhang in lower levels, just as an accented overhangs in lower levels. Thus, the problem would be rendered nigh unsolvable, because moving the boundary between and in lower levels, in either direction, would not solve it.
What we could do to solve this problem, then, is change the core for not only the 28th mina from to , but also the core from to for the 27th and 26th minas too.
→
→
→
We have in our notation, but not . This would be the first such example of including a -notated core without its -notated core. Besides, the point of this exercise is avoiding DAFLL exceptions, so we'd also be replacing in the Very High precision level with anyway. So we must replace yet a fourth -core symbol with a -core symbol: → . This solution also involves extending the boundary between and in the High precision level.
What's sad about this is that we lose some exactness in the element arithmetic. As mentioned previously, has the exact same value as + , which is a desirable property for a symbol to have; the core is the 17C, 14.730¢, while the accented symbol is the 17/5C, 12.777¢, exactly one 5s (schisma) away. If we keep all the commas as they are now, the element arithmetic would no longer be exact.
But what's the real bummer here is that we get an OoBSoLFS exception taking this approach too! + = 12.064¢ + 0.833¢ = 12.897¢ which is outside the 12.999¢ to 13.420¢ secondary comma zone for the 27th mina. So we'd have to apply the type of solution proposed in solution 1 here to resolve that.
So this is strictly more complex of a change than solution 1. I like how it fixes the single DAFLL exception in the Very High precision level, but I recognize it's a big change.
4. Accept the problem
A perfectly reasonable solution: accept that one tiny OoBSoLFS exception exists in the Extreme precision level notation.
...And set the stage for acceptance of many such OoBSoLFS exceptions in the Insane precision level.
So, in conclusion, I can only recommend solution 1 or 3. I don't recommend solutions 2 or 4. I am open to further solutions. If anyone would like visualizations of this discussion made akin to the ones I used in the topics for the 75th and 140th minas, please let me know.