I think you forgot to actually attach the files.

The problem with the base octave key is that it's global and not bound to any particular instrument. I guess we could change its behaviour when entering a note belonging to an instrument with custom tuning, but that would require some heavy refactoring. There's quite a few issues that would need to be solved here.

the files

Thank you for your response Saga Musix, I understand if it's not practical. Would it be easier/possible to expose the number of steps somewhere in the configuration (even if it's global)?

Most people won't be mix and matching different tunings within a single file, probably, so would not mind changing some setting from 12 to 19 as one-off. It's quite problematic at the moment as the entire keyboard layout changes entirely depending on the octave, so any sort of solution would be very appreciated.

Most people won't be mix and matching different tunings within a single file

Most commonly I would expect drum instrument to not use custom tunings, so mixing tunings is probably not that uncommon.

Would it be easier/possible to expose the number of steps somewhere in the configuration (even if it's global)?

I guess it would be a possible workaround but I'd first try to explore an option that would be a bit closer to the currently open module (i.e. depending on the currently chosen instrument).

One more thing to consider - custom tunings can have many more (or fewer) octaves than standard 12TET instruments. This means that the upper and lower limits of the base octave range would need to be extended - potentially only according to the currently loaded tunings (so the range would stay the same if a module only uses 12TET, but that in itself is also problematic because this control is shared between all loaded songs).

I think I have a somewhat workable solution, but there are some caveats - probably not too important to hold this feature back:

• The base octave edit field will still say 4, but for custom tunings it's centered around middle-C (i.e. base octave 5). That means that the lowest note on the keyboard may not actually be in octave 4 of your tuning. It's more important that the "home octave" (i.e. 5) stays centered on the keyboard and no actual key behaviour is changed, I think. So this is just a cosmetic issue we have to live with for now.
• The base octave range has not been extended. This means that it won't be possible to reach the lowest or highest notes of tunings with a group size less than 12, except for manual transposition after entering the note. Again this is probably not too critical.
• When there is no active instrument in the pattern editor, 12TET continues to be assumed, even if you may be overwriting an existing note with an instrument number of an instrument with a custom tuning. Doing this in any other way would open at least 5 cans of worms in particular related to the Keyboard Split feature and live recording.

This is implemented in r16962, which should be available from https://builds.openmpt.org/builds/ in a few hours and may be backported to OpenMPT 1.30 if no larger issues are found. Let me know how it works for you.

Slightly improved in r16963, removing one of those caveats: When there's no active instrument in the pattern editor, the instrument at the current edit cursor position is now used if there is one, but only if you are not in live record mode. Cans of worms regarding Keyboard Split still apply.

Hi Saga Musix

Thanks for the super fast fix and response. I installed r16964 and loaded a 19edo .tun file and the behaviour works as expected within the base octaves 2-8, but below octave 2 I can descend below the range of playable notes which causes the highest note (on the attached tuning file that's Bb8) to be entered, or sometimes a note with the notename "PCs" that causes OpenMPT to crash with the error- Unhandled C++ exception 'class std::out_of_range' occurred at address 0x00007ffcd4764f69: 'invalid bitset position'

I've uploaded the crash files and the .tun file, let me know if there is anything else I can provide.

Oops, the crash has been fixed in r16966. Next step would be to not just prevent the wrap-around of low notes to high notes, but also have a sensible lower limit on the lower octave offset.

r16967 should now also avoid the observed octave wrapping.

Perfect - thank you! r16967 is working for me with group sizes both <12 and >12.

Great! As of r16983 these changes have been backported to OpenMPT 1.30 for the next release.