Fix breakpoint note names

[probonopd]

#534

Not 100% sure whether this is the correct fix in uimenu.cpp/.h:

const char CUIMenu::s_NoteName[112][5] =
{
	"A-1", "A#-1", "B-1", "C-1", "C#-1", "D-1", "D#-1", "E-1", "F-1", "F#-1", "G-1", "G#-1",
	"A1", "A#1", "B1", "C1", "C#1", "D1", "D#1", "E1", "F1", "F#1",	"G1", "G#1",
	...

Only one way to find out... try it out...

[probonopd]

Build for testing:
MiniDexed_2023-08-14-7bee60e

Does it work as expected @Banana71?
Can you follow my logic @diyelectromusic?

[diyelectromusic]

I must admit I have no idea what this feature is about and quite what the issue is, but if the original scaling is A-1 to C8, but MiniDexed is currently showing A1 to C9, then shouldn't the number of entries remain the same? But in adding a lower octave should we be removing the highest (C#8-C9) octave too?

As I say, I don't really know what the feature is, but any talk of scaling that adds 12 new divisions sounds like the amount per division will now be different...

Also the same note table is used in ToTransposeNote so that might need some adjusting too? Again I'm not quite clear what either of these has to achieve to know for sure.

Kevin

[Banana71]

I haven't tested the version yet but... C3 is 60 decimal
Dexed shows me the following values for the breakpoints:
I have taken the following values from Dexed and put them into the format.

const char CUIMenu::s_NoteName[112][5] =
{
"A-1", "A#-1", "B-1", "C0", "C#0", "D0", "D#0", "E0", "F0", "F#0", "G0", "G#0",
"A0", "A#0", "B0", "C1", "C#1", "D1", "D#1", "E1", "F1", "F#1", "G1", "G#1",
"A1", "A#1", "B1", "C2", "C#2", "D2", "D#2", "E2", "F2", "F#2", "G2", "G#2",
"A2", "A#2", "B2", "C3", "C#3", "D3", "D#3", "E3", "F3", "F#3", "G3", "G#3",
"A3", "A#3", "B3", "C4", "C#4", "D4", "D#4", "E4", "F4", "F#4", "G4", "G#4",
"A4", "A#4", "B4", "C5", "C#5", "D5", "D#5", "E5", "F5", "F#5", "G5", "G#5",
"A5", "A#5", "B5", "C6", "C#6", "D6", "D#6", "E6", "F6", "F#6", "G6", "G#6",
"A6", "A#6", "B6", "C7", "C#7", "D7", "D#7", "E7", "F7", "F#7", "G7", "G#7",
"A7", "A#7", "B7", "C8"
};
static const unsigned NoteC3 = 60; // C3 corresponds to the number 60 in decimal or 3c in HEX

This is from your code:
const char CUIMenu::s_NoteName[112][5] =
{
**"A-1", "A#-1", "B-1", "C-1", "C#-1", "D-1", "D#-1", "E-1", "F-1", "F#-1", "G-1", "G#-1",
"A1", "A#1", "B1", "C1", "C#1", "D1", "D#1", "E1", "F1", "F#1", "G1", "G#1",
"A2", "A#2", "B2", "C2", "C#2", "D2", "D#2", "E2", "F2", "F#2", "G2", "G#2",
"A3", "A#3", "B3", "C3", "C#3", "D3", "D#3", "E3", "F3", "F#3", "G3", "G#3",
"A4", "A#4", "B4", "C4", "C#4", "D4", "D#4", "E4", "F4", "F#4", "G4", "G#4",
"A5", "A#5", "B5", "C5", "C#5", "D5", "D#5", "E5", "F5", "F#5", "G5", "G#5",
"A6", "A#6", "B6", "C6", "C#6", "D6", "D#6", "E6", "F6", "F#6", "G6", "G#6",
"A7", "A#7", "B7", "C7", "C#7", "D7", "D#7", "E7", "F7", "F#7", "G7", "G#7",
"A8", "A#8", "B8", "C8", "C#8", "D8", "D#8", "E8", "F8", "F#8", "G8", "G#8",
"A9", "A#9", "B9", "C9"**
};
static const unsigned NoteC3 = 39;

[probonopd]

I set static const unsigned NoteC3 = 51; because C3 is the 51th element of the array (counting from 0), is my logic wrong?

[diyelectromusic]

Hang on... in Musical terms, notes go A1, A#1, B1, C2, C#2... not A2, A#2, B2, C2... :)

That whole table is wrong surely!

Kevin

[probonopd]

Right, now that you are saying it... the table Banana71 posted from Dexed is correct though?

[diyelectromusic]

Right, now that you are saying it... the table you posted from Dexed is correct though?

@Banana71 posted it, but that has 112 entries. As I say, Dexed only supports 0..99 so I'm not quite sure what is happening still...

Oh wait, that says [112] but counting I think it is [100] so that should be right?

[diyelectromusic]

Ok, so for ToTransposeNote the UI limits it to the range 0 to 48 here: https://github.com/probonopd/MiniDexed/blob/main/src/uimenu.cpp#L279C13-L279C28

But the manual states:

So that is why NoteC3 must be set to the index of middle C, so that the line https://github.com/probonopd/MiniDexed/blob/main/src/uimenu.cpp#L1066

Can scale the value to fit the note table.

Update: And just checking the operation of the transpose menu in the current build, yes that is wrong too atm! This should fix that too.

Kevin

[probonopd]

Build for testing: MiniDexed_2023-08-14-48d7112

[diyelectromusic]

Menus all seem to work and from what I can hear the transpose function is working for +/- 2 octaves (C1-C3-C5).

Not really understanding what the Keyboard Scaling breakpoint does, I can't test that (although I can see the menus are doing what we want them to).

Note: Tested in a Pi3 with SSD1306 display.

Kevin

[probonopd]

@diyelectromusic thanks for testing. I don't entirely understand Keyboard Scaling breakpoint either, so...
@Banana71 since you brought it up, can you confirm that we have the correct octaves now?

[Banana71]

Thank you very much for your patience, the breakpoint is now displayed correctly. @probonopd and @diyelectromusic🎉🖖🏼

As I say, I don't really know what the feature is

Keyboard Level Scaling controls the volume of each operator. The volume of the operators is influenced starting from the breakpoint. Together with velocity, very complex sounds are possible.

A layered single sound can be heard in the sound sample. The high notes have hardly any overtones. In the middle range, the bells come through and the bass range sounds distorted depending on the velocity.

KeyScaling.mp4

[probonopd]

Thanks for your testing and explanations @Banana71.

the breakpoint is now displayed correctly

Great to know. Hopefully this doesn't break anything else.
Merging.