Edited to actually include the attachments...
Dave Keenan wrote: ↑
Fri May 22, 2020 10:28 am
Welcome, @volleo6144. It's great to have another brain on this.
volleo6144 wrote: ↑
Fri May 22, 2020 1:22 am
Dave Keenan wrote: ↑Thu May 21, 2020 5:08 am
I find that George's JI notation spreadsheet does not produce an error when asked to notate 25/77. It simply doesn't offer any notation with a 68.1 ¢ (no-mans-land) alteration. It only offers two possible spellings instead of the usual three.
What would the third spelling be? Looking in the calculator shows that it offers spellings for those nominals—and only those nominals—that are within two apotomes of the ratio (after all, you can't go much further than in pure-form), and G and A are the only nominals within that range—F is too low by 39858075:40370176, ~22¢, and B is too high by 1515591:1638400, ~135¢.
You are quite right that there should be no third spelling with C as 1/1. Thanks.
When I was first learning Sagittal, this was one of the first things I felt I needed to understand: why does this JI Notation Calculator give me only 2 suggestions sometimes? What's wrong about those pitches?
So nothing turned out to be "wrong" about certain of my pitches, and the count of pitches wasn't arbitrary either. Though the relationship between my pitches and the "apotomy topology" as I called it was unpredictable, as my pitches were all essentially 11-rough.
Indeed this is explained by whether a given stretch of the octave is within the 2-apotome range of three nominals or only two. If you're curious, I crunched the numbers (back then), and 827.784 out of the 1200 cents of the octave are in range of three nominals; the remaining 372.216 are only in range of two. So that means about 2/3 of the time (68.982% to be more precise) you'll get three suggestions.
Dave Keenan wrote: ↑
Wed May 20, 2020 1:30 pm
I haven't fully come to grips with it all yet, but I miss not having a PDF version I can zoom in on.
I'm sorry about that. I very much intended to attach the PDF version, but I wasn't able to get one to stick, no matter what trick I tried. It kept saying something like "9238h9f8ch is not a valid file" or something like that (my filename was definitely not whatever it was saying it was).
And I note that some of your 90° rotated precision-level labels, on the left and right margins, are wrong. And you're missing "Extreme Precision".
Fixed and updated in the new version here.
When I re-read the first post in this thread, I'm reminded that there was never any no-mans-land. The problem was that, in Promethean (high precision) George's JI Notation spreadsheet
instead of simply
(with D, A, E or B as 1/1).
I told Dave by email that I was behind on some work and would need to step away from the forum for a bit. I did indulge in reading the replies, though
I knew all of this and wished I had the time to jump in. But I see that y'all got there eventually on your own.
Yes, I confirm that there never were any dragons / never was any no-mans-land. From George's first version of the calculator, the problem was the suggestion of
instead of simply
The error messages I'm remembering must have been for other things entirely, and only in the very early versions of cmloegcmluin's upgrade of George's spreadsheet (to add the Bravura font and the pure (Revo) notation).
The errors @Dave Keenan
is remembering were from my very first version of the calculator spreadsheet. From an email Dave sent to me:
2. There seem to be way more "#N/A"s than there should be. For example, I enter a 1 as the exponent of 5, and I get mixed ASCII but no mixed unicode.
Ah, good catch. Fixed that specific cause. It was actually a cascading problem from my fix for the )\\!# issue. If you're curious, the problem was that isntead [sic] of correcting )\\!x to the mixed version )|\\# I corrected it to its pure version )|||\\, and there's no entry for a pure version of a sagittal in the Mixed Map.
So it was just a goof on my part. I mean that it was trying to look up ")|||\\" in a table of Evo (mixed) flavor to find its translation in Revo (pure), and of course it wouldn't find it because ")|||\\" is not a thing in Evo flavor. I could have been clearer about this in my previous posts. Sorry for introducing confusion.
I expect that George would have caught this as an error had he implemented Revo flavor in his sheet. I only came across this issue with the single-shaft upper bound in adding a layer to his functionality to translate Evo into Revo. That's because as Dave points out there is no pure symbol for
. So I never shared this explicitly before, but what happened before I added my quick'n'dirty fix, which I did before I ever even shared out my version of the sheet at all, it would give me an #N/A spreadsheet error for the 25/77L (which I note is [ 8 2 -1 -1 ⟩ in 3-monzo form). You can reproduce this error for yourself if you simply use my latest version of the calculator, enter the 25/77L (the default C nominal is fine), and then go over to the tab called "Key", scroll all the way to the bottom, and find the 4 exception cases I added to patch up this issue in the High Precision notation. If you delete those, and then go back to the UI tab, you will see the error that I saw before I ever released the sheet.
When you do that, in HP you have to come up with a purely-sagittal single-symbol apotome-complement for
i.e. a single symbol equivalent of
. When we look at figure 13 on page 24 of http://sagittal.org/sagittal.pdf
we see that this could only be
. Which is equivalent to extending the capture zone of
in HP further to the right than is shown here: http://sagittal.org/SagittalJI.gif
, but only in the case of HP. All the others would have variously-accented variants of (va)
in that region.
So this is essentially what I did with my quick'n'dirty fix -- extend the boundary of High Precision's
higher than in the other three levels.
That clinches it for me. If, even when we try the quick'n'dirty fix, we find we have to extend the capture zone for va
in at least one notation, then we should extend it in all notations. And by extending it to the L/SS boundary and simultaneously shifting the upperbound for va
(the largest single-shaft having a double-shaft complement) to the S/M boundary at all precision-levels, we don't have to shift the HP boundary for
as far as we otherwise would have.
I think what you've done here is found a much more objective way of asserting what I was trying to get at when I said:
cmloegcmluin wrote: ↑
Wed May 20, 2020 12:25 pm
And after some consideration, I think we should actually move the boundary at every precision level to lock onto the S|M + L|SS bound. I think this should be one of those handful of bounds that cuts straight through all four precision levels. The other two don't actually have anything to do with the comma size category boundaries (the first one is at 13.420¢ between and and the second one is at 18.760¢ between and while the comma size category boundaries are at 1.808, 4.500, 11.730, 33.382, 45.112, 56.842, and 68.573 cents). Nonetheless, I think this is an important enough one of these boundaries, given its more intimate connection to the anatomy of the apotome, that it deserves to have this much influence over the capture zone boundaries.
With your insight as buttress, I might go on to say it this way too: we must ensure that for each precision level a consistent boundary exists at the point of switchover from notating relative to one apotome to notating relative to the next apotome. This was not the case before; only the High Precision level deviated. We could correct the situation by moving only the High Precision's boundary to meet the others at around 139.5 minas. But the better approach is to move all four boundaries so that they meet at the S|M/L|SS size category bound, a logical place to meet, within which boundaries are mirrored perfectly about the half-apotome (thus no "distortion" occurs in boundaries in the Revo flavor w/r/t element arithmetic inside there).
I have added the Revo flavor to the diagram as well. I don't know why I didn't think it would be as helpful before. The whole "#N/A!" bit really draws attention to the important bit.
And the fact that the existing comma for the 93rd mina, 77/25M is actually SoCA for
makes it even better. The OoBSoE is not important. Yes, this one is good for release. Please fix the JI Notation Spreadsheet to use this, if you haven't already.
I've updated it to use SoLFS (that's sum-of-lower-fewer-symbols... something Dave and I are working on in another thread which we think best captures the intentions behind which secondary commas are necessary given the way symbols look... I'll share out details soon) instead of SoCA and SoE. As you can see there are no OoBSoLFS exceptions in this vicinity, before or after the change (even by their capture zones at the Extreme Precision
, which is unnecessary but nice-to-have; they only have to be within bounds of their secondary comma zones
You're right. The dragon is conceptually red and in the no-mans-land.
Well, the dragon doesn't represent the no-mans-land anymore, but it does represent the problem we've vanquished!
I know you already said to pull the trigger on the addition of this 140th mina across Sagittal resources, Dave, but since there was a bit more to say on the matter since, I just want a final confirmation.