View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001568||OpenMPT||User Interface||public||2022-02-15 04:12||2022-03-15 09:20|
|Reporter||chocosaurus||Assigned To||Saga Musix|
|Product Version||OpenMPT 1.30.02.00 / libopenmpt 0.6.1 (upgrade first)|
|Target Version||OpenMPT 1.30.03.00 / libopenmpt 0.6.2 (upgrade first)||Fixed in Version||OpenMPT 1.30.03.00 / libopenmpt 0.6.2 (upgrade first)|
|Summary||0001568: Base Octave does not honor group size of custom tunings|
This is a sort of companion issue to
The "Previous Octave" and "Next Octave" keys (NUM DIVIDE and NUMMULT for me in the mp2-IT hybrid bindings) change the current base note up or down by 12 steps, regardless of the group size of the current instrument's tuning.
For example in 19TET this is an augmented fifth and takes me through the sequence e.g. D#2, Bb3, F#3, Db4, A-5, E#5, C-6, G#6.
What should happen instead is that the base note moves up/down by whatever the group size of the current instrument's tuning is (in the case of the attached file, 19 steps).
|Steps To Reproduce|
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||Yes|
|Tested code revision (in case you know it)|
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.
tunings.zip (1,314 bytes)
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 commonly I would expect drum instrument to not use custom tunings, so mixing tunings is probably not that uncommon.
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:
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.
OpenMPT Crash Files.zip (180,768 bytes)
19edo.zip (289 bytes)
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.
|2022-02-15 04:12||chocosaurus||New Issue|
|2022-02-15 07:04||StarWolf3000||Note Added: 0005083|
|2022-02-15 08:12||Saga Musix||Note Added: 0005084|
|2022-02-15 09:46||chocosaurus||Note Added: 0005085|
|2022-02-15 09:46||chocosaurus||File Added: tunings.zip|
|2022-02-15 09:54||chocosaurus||Note Added: 0005086|
|2022-02-15 14:01||Saga Musix||Note Added: 0005087|
|2022-02-15 20:30||Saga Musix||Note Added: 0005090|
|2022-02-18 22:21||Saga Musix||Assigned To||=> Saga Musix|
|2022-02-18 22:21||Saga Musix||Status||new => assigned|
|2022-02-18 22:31||Saga Musix||Status||assigned => feedback|
|2022-02-18 22:31||Saga Musix||Note Added: 0005101|
|2022-02-18 22:37||Saga Musix||Note Edited: 0005101|
|2022-02-18 22:46||Saga Musix||Note Added: 0005102|
|2022-02-18 22:50||Saga Musix||Summary||Previous Octave and Next Octave keys move by 12 steps in non-12-note tunings => Base Octave does not honor group size of custom tunings|
|2022-02-19 06:39||chocosaurus||Note Added: 0005105|
|2022-02-19 06:39||chocosaurus||File Added: OpenMPT Crash Files.zip|
|2022-02-19 06:39||chocosaurus||File Added: 19edo.zip|
|2022-02-19 06:39||chocosaurus||Status||feedback => assigned|
|2022-02-19 11:39||Saga Musix||Note Added: 0005108|
|2022-02-19 12:47||Saga Musix||Note Added: 0005109|
|2022-02-19 12:47||Saga Musix||Status||assigned => feedback|
|2022-02-20 05:09||chocosaurus||Note Added: 0005111|
|2022-02-20 05:09||chocosaurus||Status||feedback => assigned|
|2022-02-20 11:09||Saga Musix||Note Added: 0005112|
|2022-02-20 11:09||Saga Musix||Status||assigned => resolved|
|2022-02-20 11:09||Saga Musix||Resolution||open => fixed|
|2022-02-20 11:09||Saga Musix||Fixed in Version||=> OpenMPT 1.30.03.00 / libopenmpt 0.6.2 (upgrade first)|
|2022-02-20 11:09||Saga Musix||Target Version||=> OpenMPT 1.30.03.00 / libopenmpt 0.6.2 (upgrade first)|