Hi, I'm Nick. In the discord chat I go by theHDM. I thought about a
few of these microtonal things re: coding and I believe the correct
way to implement the MIDI for microtonal control is:
1) the note numbers you need are fractions, not integers. for example,
41-edo, if you start at note 69 = A⁴, the scale from A to A is 69, 69
+ 12/41, 69 + 24/41, 69 + 36/41, 70 + 7/41, ... 80 + 17/41, 80 +
29/41, 81. say this array is Y.
2) when the user selects a microtonal layout, send a BULK TUNING DUMP
message in MIDI that instructs the synth to tune note X in the layout
as note Y in the microtonal system.
3) the layout array becomes the value of the mapped notes X.
Will give a shot at writing some .ino code in the next month or so as
I have time, so we can test out and refine.
--
-n.
On Fri Feb 16, 2024 at 1:26 PM EST, Nicholas Fox wrote:
> 1) the note numbers you need are fractions, not integers. for example,> 41-edo, if you start at note 69 = A⁴, the scale from A to A is 69, 69> + 12/41, 69 + 24/41, 69 + 36/41, 70 + 7/41, ... 80 + 17/41, 80 +> 29/41, 81. say this array is Y.
Thanks for the math! Using MTS' bulk tuning dump for microtonal support is the plan, we just need to do it!
> Will give a shot at writing some .ino code in the next month or so as> I have time, so we can test out and refine.
I think maybe a good first step is to make a script to generate the dump, as bytes, like
{69,0x0,0x0,69,high_bits_12o41,low_bits12o41,69,high_bits_24o41,low_bits_24o41,...
(and we'll hard-code it to match the pitches the buzzer makes)
On Thu Feb 22, 2024 at 9:56 AM EST, Nicholas Fox wrote:
> Hi Zach,>> Can you confirm if this is the correct ModelNumber 2 layout?> //> 1 2 3 4 5 6 7 8 9> 10 11 12 13 14 15 16 17 18 19> 21 ......................................... 29> 30 ............................................... 39> 41 ......................................... 49> 50 ............................................... 59> 0 61 ......................................... 69> 20 70 ............................................... 79> 40 81 ......................................... 89> 60 90 ............................................... 99> 80 101 ......................................... 109> 100 110 ............................................... 119> 120 121 ......................................... 129> 130 ......... ......................................139
Yeah, that looks right.
On version 1 (only 5 of these exist), the LED matrix started from the wrong corner (top right when holding the device in vertical orientation).
We compensated for that by changing the columns so the button matrix was the same as the LED matrix,
and we added the macro ROW_FLIP (so layouts defined in the code are still defined in a sane way in vertical orientation).
I ported the qmk to support the keyboard, so the following is the pretty output of `qmk info -m -kb hexboard/1_1`.
https://github.com/qmk/qmk_firmware/pull/22493
Matrix for "LAYOUT_landscape":
┌──┐ ┌──┐ ┌──┐
│AA│ │6A│ │2A│
┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐
│CA│ │8A│ │4A│ │0A│
└──┘ └──┘ └──┘ └──┘
┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
│DA│┌──┐│BA│┌──┐│9A│┌──┐│7A│┌──┐│5A│┌──┐│3A│┌──┐│1A│┌──┐
└──┘│CB│└──┘│AB│└──┘│8B│└──┘│6B│└──┘│4B│└──┘│2B│└──┘│0B│
┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘
│DB│┌──┐│BB│┌──┐│9B│┌──┐│7B│┌──┐│5B│┌──┐│3B│┌──┐│1B│┌──┐
└──┘│CC│└──┘│AC│└──┘│8C│└──┘│6C│└──┘│4C│└──┘│2C│└──┘│0C│
┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘
│DC│┌──┐│BC│┌──┐│9C│┌──┐│7C│┌──┐│5C│┌──┐│3C│┌──┐│1C│┌──┐
└──┘│CD│└──┘│AD│└──┘│8D│└──┘│6D│└──┘│4D│└──┘│2D│└──┘│0D│
┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘
│DD│┌──┐│BD│┌──┐│9D│┌──┐│7D│┌──┐│5D│┌──┐│3D│┌──┐│1D│┌──┐
└──┘│CE│└──┘│AE│└──┘│8E│└──┘│6E│└──┘│4E│└──┘│2E│└──┘│0E│
┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘
│DE│┌──┐│BE│┌──┐│9E│┌──┐│7E│┌──┐│5E│┌──┐│3E│┌──┐│1E│┌──┐
└──┘│CF│└──┘│AF│└──┘│8F│└──┘│6F│└──┘│4F│└──┘│2F│└──┘│0F│
┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘
│DF│┌──┐│BF│┌──┐│9F│┌──┐│7F│┌──┐│5F│┌──┐│3F│┌──┐│1F│┌──┐
└──┘│CG│└──┘│AG│└──┘│8G│└──┘│6G│└──┘│4G│└──┘│2G│└──┘│0G│
┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘
│DG│┌──┐│BG│┌──┐│9G│┌──┐│7G│┌──┐│5G│┌──┐│3G│┌──┐│1G│┌──┐
└──┘│CH│└──┘│AH│└──┘│8H│└──┘│6H│└──┘│4H│└──┘│2H│└──┘│0H│
┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘
│DH│┌──┐│BH│┌──┐│9H│┌──┐│7H│┌──┐│5H│┌──┐│3H│┌──┐│1H│┌──┐
└──┘│CI│└──┘│AI│└──┘│8I│└──┘│6I│└──┘│4I│└──┘│2I│└──┘│0I│
┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘
│DI│┌──┐│BI│┌──┐│9I│┌──┐│7I│┌──┐│5I│┌──┐│3I│┌──┐│1I│┌──┐
└──┘│CJ│└──┘│AJ│└──┘│8J│└──┘│6J│└──┘│4J│└──┘│2J│└──┘│0J│
┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘┌──┐└──┘
│DJ│ │BJ│ │9J│ │7J│ │5J│ │3J│ │1J│
└──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘
Matrix for "LAYOUT_portrait":
┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│0B││0C││0D││0E││0F││0G││0H││0I││0J│
└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│1A││1B││1C││1D││1E││1F││1G││1H││1I││1J│
└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│2B││2C││2D││2E││2F││2G││2H││2I││2J│
└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│3A││3B││3C││3D││3E││3F││3G││3H││3I││3J│
└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│4B││4C││4D││4E││4F││4G││4H││4I││4J│
└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│5A││5B││5C││5D││5E││5F││5G││5H││5I││5J│
└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐ ┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│0A│ │6B││6C││6D││6E││6F││6G││6H││6I││6J│
└──┘ └──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐ ┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│2A│ │7A││7B││7C││7D││7E││7F││7G││7H││7I││7J│
└──┘ └──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐ ┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│4A│ │8B││8C││8D││8E││8F││8G││8H││8I││8J│
└──┘ └──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐ ┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│6A│ │9A││9B││9C││9D││9E││9F││9G││9H││9I││9J│
└──┘ └──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐ ┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│8A│ │AB││AC││AD││AE││AF││AG││AH││AI││AJ│
└──┘ └──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐ ┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│AA│ │BA││BB││BC││BD││BE││BF││BG││BH││BI││BJ│
└──┘ └──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐ ┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│CA│ │CB││CC││CD││CE││CF││CG││CH││CI││CJ│
└──┘ └──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐┌──┐
│DA││DB││DC││DD││DE││DF││DG││DH││DI││DJ│
└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘└──┘
>> I think maybe a good first step is to make a script to generate the dump, as bytes, like>> {69,0x0,0x0,69,high_bits_12o41,low_bits12o41,69,high_bits_24o41,low_bits_24o41,...
ight, i'll work on that
>> (and we'll hard-code it to match the pitches the buzzer makes)
a thought on this. we're using the built in tone generator which only
accepts pitches with integer frequency.
it would be easy to write our own tone function that accepts float variables.
then we would not have to store a table of pitches. we can generate
them to match the layout when the layout and tuning is updated.
>> 'tuning to a color' is currently complicated, as our 'key' and 'transpose' options conflict a little and weren't designed for microtonal needs (i.e. needs a good refactor).>> We're also thinking about changing 'layouts' to 'presets', e.g. "use this color scheme for that layout, with that number of tones"
actually this is related to the above. the vision i had was to allow
the following to be defined:
Tuning
* how many steps in an octave?
* what pitch class is the "key"? (i.e. how many steps away from A is the root?)
* what does A sound like? (i.e. is it 440 Hz? or something different?
or are you transposing up some amount?)
Layout
* on what hex do you place the root?
* how many steps up or down when you go across? or, if you want,
generalize what the interval is and let the tuning tell you how many
steps that equals
* how many steps up or down when you go down-left?
* assign a MIDI note from 0 to 127 to each hex
* if there are more than 128 unique pitch classes because the number
of steps doesn't create a wraparound on this board, then assign 5 keys
to be unused
Pitches
* given the layout and the tuning, what note should be played in MIDI
terms? (the MIDI note number plus/minus the number of cents off *
8192/100 or whatever)
* given a MIDI note number, how many Hz is that? how many processor
cycles do you alternate the buzzer off and on, given the F_CPU = 133
MHz?
Spelling
* given how many steps in an octave, how do you spell each note?
this would be for display purposes and for note coloring
Color Scheme
* given a layout and EDO, and a note spelling, how do you decide which
colors to assign?
perhaps these definitions would all be savable as presets and recalled
individually. this might require a routine to read/write directly to
disk to recall and preload these settings.
i think that if the calculations of all the above steps were done only
once every time a preset is loaded, and the pitches / midi bulk tuning
items, it shouldn't have any affect on performance.
On Fri, Feb 16, 2024 at 5:10 PM Zach DeCook <zachdecook@librem.one> wrote:
>> On Fri Feb 16, 2024 at 1:26 PM EST, Nicholas Fox wrote:> > 1) the note numbers you need are fractions, not integers. for example,> > 41-edo, if you start at note 69 = A⁴, the scale from A to A is 69, 69> > + 12/41, 69 + 24/41, 69 + 36/41, 70 + 7/41, ... 80 + 17/41, 80 +> > 29/41, 81. say this array is Y.>> Thanks for the math! Using MTS' bulk tuning dump for microtonal support is the plan, we just need to do it!>>> > Will give a shot at writing some .ino code in the next month or so as> > I have time, so we can test out and refine.>> I think maybe a good first step is to make a script to generate the dump, as bytes, like>> {69,0x0,0x0,69,high_bits_12o41,low_bits12o41,69,high_bits_24o41,low_bits_24o41,...>> (and we'll hard-code it to match the pitches the buzzer makes)
--
-n.