Support unmapped note as tuning center

[baconpaul]

An unmapped note as tuning center has an option to interpolate the tuning to that note even though it is unmapped.

[baconpaul]

@davispolito feedback over here if possible thanks!

[davispolito]

Hi! this is great! Thanks for the code cleanup! The error I mentioned about where the P4 leap happens is still occurring though

58: 226.446
59: 239.912
60: 220
61: 339.286

that leap should be between 58 and 59 such that 59 is somewhere around 326 Hz. When I looked into y'alls code I thought it might be something from the rounds that caused this issue but I didn't try to figure it out too hard as I was pulled away to some other stuff. I can get back into it, but if you know what could be going on lemme know!

[baconpaul]

Can you let me know exactly which mapping file you use? So maybe help me understand what you think is wrong

If I use 12-intune and mapping-whitekeys-from-59-a440.scl

The root note is 59, and that's mapped to scale 0. The tuning note is 69 and it is interpolated The neighbors of note 69 are notes 9 and 11 in the scale You are in 12TET So you expect note 59 to have frequency 440 * pow(2, -10/12) = 246.94

if I then modify commands/showcommand.cpp to add true when the tuning is created and run it I see

  56, 207.6523430706, 25.3984161319, 4.6666666269
  57  [unmapped]
  58, 233.0818743392, 28.5087581953, 4.8333332936
  59, 246.9416438265, 30.2039771739, 4.9166666269
  60  [unmapped]
  61, 277.1826233424, 33.9028180857, 5.0833332936
  62  [unmapped]
  63, 311.1269751527, 38.0546266319, 5.2499999603
  64, 329.6275478339, 40.3174724862, 5.3333332936
  65  [unmapped]
  66, 369.9944125208, 45.2548327495, 5.4999999603
  67  [unmapped]
  68, 415.3046861411, 50.7968322639, 5.6666666269
  69  [unmapped]
  70, 466.1637486785, 57.0175163905, 5.8333332936

which looks spot on to me. The neighbors are a half step away from 440 and the note 59 is mapped properly

./ignore/build/showmapping tests/data/12-intune.scl tests/data/mapping-whitekeys-from-59-a440.kbm was the command

So it really seems like this works as desired, no?

[baconpaul]

Oh or is your concern that the root note is mapped to the end of the prior scale not the start of the current with non direct mappings?

[davispolito]

apologies, I had mentioned it in the original post but the file "mapping-whitekeysalt-from-59-a440.kbm" which a different mapping scheme than the other file.

[baconpaul]

Ahh right. So in that case note 69 is between tones 5 and 6. So note 59 at scale 0 should be tuned to 440 pow(2,-5.5/12) = 320.23 and note 61 at scale 1 should be tuned to 440 pow(2, -4.5/12) = 339.28 and instead what I'm seeing is note 61 at 339.28 (correctly) and 59 at 239. That 239 is 440 * pow(2, (-5.5 - 5)/12) because we are mapping note 59 to the end of the prior scale (tone 7, which is a fifth down) rather than the start of the current scale.

I see now.

[baconpaul]

Ahh yes but that KBM file has the scale degree as 7 which is what is causing the problem.

If I set the scale degree to the scale degree of the scale (namely set it to 12) I get the right answer.

I am not entirely sure the tuning library is wrong here; the definition of an octave distance is not an actual frequency doubling. What I'm going to do is

1: Correct the KBM 2: Update the test to test note 59 3: Merge and 4: If needs be we can create another issue for what to do if the octave mapping isn't an octave and which side to pick for the root note (you gotta pick one).

That is, unless I can figure out why root note is picking top of mapping rather than bottom, in which case I will copy the file to the correct one and test both cases.

Stay tuned.

[baconpaul]

Yeah OK so I looked at this, and what you are seeing is exactly the problem of not having your scale octave actually be an octave in your kbm. I don't think we are wrong (but it is ambiguous).

The octave degree means that the frequency of note transposed by keys is twice the frequency of note. We use that constraint to determine which scale tone to look up. If you break that constraint then that transformation fails, which is what you see here. Since there is no note "0" in an SCL file (only a note "octave") we end up taking mappings to note 0 and saying it is a ratio up from the octave below. Voila.

So I fixed the mapping file to have an octave length that matches an octave and pushed. If CI passes I'll merge it also, since your change is great and useful!

[davispolito]

awesome! I think this is definitely a fair assessment of the problem!

[baconpaul]

Great - so I think all the issues you hit are now resolved right? Good stuff! Lemme know if you end up deploying. (If you want to. There’s zero obligation of course but we do like to learn about usages)

[davispolito]

We are planning to use it in the next release (hopefully this month). Y'all had pointed us to your script for code signing on Mac, but I am quite unsure how to use it. Any chance you could help us out there?

[baconpaul]

Sure but can we do that over DM or email perhaps? Hop on our discord and DM me if that's OK?

[davispolito]

sure!

[davispolito]

where exactly is the discord link?

[baconpaul]

https://discord.gg/6MRkcXQY