Dave Keenan wrote: ↑
Wed Sep 02, 2020 4:18 pm
More realistically, the dot might be used for either 1/2-tina or 1/3-tina. We don't need to specify.
Elsewhere I had suggested that for purposes of playback, it would alter pitch by nothing (AKA its primary comma would be unison). But I suppose it could be a 1/3-tina.
I see that you really still want a default size for the dot in your software, even if we don't specify it in the SMuFL documentation.
I remind us of @Ash9903b4's post here:
Ash's suggestions are more like 1/2-tina or 1/4-tina, not 1/3-tina, so I say default to 1/2-tina. There's the precedent of dotted notes (duration) that might lead people to expect it to correspond to 1/2 a tina, and that was the original definition.
The web calculator for Sagittal should have some playback at some point, but I was really just thinking about this doc
and wanting to having an answer for developers of music notation software.
^ Thanks for demonstrating that [
hr] for me! I'll stop using my ugly ol' ------ trick.
This whole thread is pretty much indulgent puzzle-solving fun on our part.
Welp. I was supposed to get started on this other project today, but tried as I might to stop indulging in this puzzle, I couldn't help myself...
To the delight of many Node developers across the internet, this particular fail condition gives one very little to work off of. However, thanks to my newly acquiring skills of profiling Node (thanks again, Dave), I was able to figure out where my script was crashing!
It was spending most of its time computing monzos from prime exponent extremas. Yes, I know that's a double plural: "extremas" in my app are like monzos except each term is a pair of extrema (a min and a max) between which that term must lie (inclusively, on both ends). Given a maximum N2D3P9, such an "extremas" is just what the code needs; it's essentially the structure Dave first presented here
for max N2D3P9 = 136). It then checks each possible monzo given said extremas — which in other words is every monzo which has any hope of its N2D3P9 being less than the max — and if its N2D3P9 is found indeed to be within the max, then that monzo makes it into the output table (where it gets ranked, converted to a ratio, matched up with notating Sagittal symbols, etc.)
Another problem this turned up was that some monzo-from-extremas work was happening over and over wastefully, in a different corner of the code: whenever it tries to find the max exponent for a denominator prime, it has to know what the max numerator can be for the given max N2D3P9. Each denominator prime was calculating it all over again. I plan to change it to memoize whatever it finds. Potentially I could even find the breaking points between each max numerator based on the max N2D3P9 and hardcode that, but again, that can be taken care of whenever I get to it. For now, for 307, btw, the max numerator is 21875, 55
No, I still haven't done the work to hardcode the sorted N2P's and N2's
. That would help performance too, but apparently wasn't the bottleneck to finding our lovely metacommas*. It still took a while for it to check the N2D3P9 for the tens of millions of possible monzos (unfortunately I didn't get an exact number).
So I was finally able to get it to spit out the ranked list of top 307 ratios. Since that's such a bulky table, I'm actually going to share it in another post, and actually probably just back on the N2D3P9 thread (update: here
I found that what we really wanted from this new script was for it to give a list of commas, sorted by increasing size in cents, grouped by which tina it'd be assigned to (as we were structuring our tables earlier in this thread).
And then for each of these tina comma candidates, which of the not-yet-exactly-notated commas it would enable Sagittal to exactly notate given the commas it already has.
And since each tina comma candidate could potentially enable notation of multiple not-yet-exactly-notated commas, and each not-yet-exactly-notated comma might be able to be exactly notated by more than one tina comma candidate, we needed the table to have a column for each not-yet-exactly-notated comma, so we'd in the end have a grid of all the possibilities, so we could choose the metacommas most efficiently.
And that I should sort the columns by decreasing popularity, so we can optimize for ones closer to the left.
And rather than a simple "x" in the cells where there is a match, use the cell to display the existing comma in Sagittal which when combined with this metacomma gets you the
Said table, it turns out, it just over the max allotted character count per post on the forum. I might be able to fiddle with the forum settings, but that limit is probably there for a reason. So I'll start the table on the next post, splitting it up by tina, and spread it across two posts.
Dave Keenan wrote: ↑
Thu Sep 03, 2020 10:09 am
So we don't need to go any further in N2D3P9, but I'd be glad if you would write a script to check these results.
Should be a simple matter to verify using the tables I'm about to drop.
Next thing I'd like to do is cross-reference these with the tables we were working with before with some yellow hiliting and see how in tune they are with each other.
*I keep meaning to ask about this. I have a vague memory of reading somewhere at some point that if a comma is defined as a small interval between between two pitches, then a [????] is a small interval between two commas. I can't figure out what I'm thinking of, or even if it was on Tonalsoft or the Xen wiki or XPSC or Untwelve camp materials or what. Does that ring any bells for you? I want to say that whatever those ????s are, they were one of the commatic interval terms Sagittal uses as a name for one of the size categories in its systematic comma naming scheme, in which case the collision would prevent us from getting much mileage out of the term in this context. Besides, I rather like "metacomma"!