Topic: Feature request: allow tuning to have different intervals out of order
Whenever I import in a .scl tuning, it always automatically puts the intervals in order if they're not in order.
For instance, if the .scl file has the intervals in this order:
5/4
3/2
15/8
240 cents
Then that means the .scl file is supposed to start with a root midi pitch, the next midi note up is a 5/4 major third above the root, the next midi note up is a 3/2 perfect fifth above the root, the next midi note up is a 15/8 major seventh above the root, and then the final note is 240 cents above the root. The crucial thing here is that because 240 cents is the last interval in the list, the list pattern restarts over with 240 cents as the new root for the next midi note up and so on.
One more example:
400 cents
800 cents
200 cents
So we're gonna call midi value 69 the root note for this context. Midi value 70 is 400 cents higher than 69. 71 is 800 cents higher than 69. 72 is 200 cents higher than 69. And then because 200 cents is the last value in the list, the list pattern starts over with 72 as the root note, and since 72 is 200 cents higher than 69, 72 is the new root note at 200 cents higher than 69, and 73 is 400 cents higher than 72 (aka 600 cents higher than 69), 74 is 800 cents higher than 72 (aka 1000 cents higher than 69), and 75 is 200 cents higher than 72 (aka 400 cents higher than 69).
The problem with Pianoteq is that when I import a .scl tuning file, Pianoteq automatically orders every interval in the tuning list if they're not in ascending order. This means that the example I listed above would be forcibly listed as:
200 cents
400 cents
800 cents
And so midi value 70 would be 200 cents higher than 69, 71 would be 400 cents higher than 69, and 72 would be 800 cents higher than 69, but because 800 is the last value in the list, 72 becomes the new root for the list pattern to start over again with 72 as the new root, and because 72 is 800 cents higher than midi 69 instead of 200 cents higher like it would be if the list was in a different order, the entire tuning is entirely different.
And so here therein lies the problem. Because Pianoteq automatically reorders the .scl file and I can't disable the reordering, it literally forcibly modifies and breaks the .scl tunings I import into it, so the .scl tuning file I imported into it sounds completely different from the Pianoteq reordering.
Even when I then import in a .kbm file (which serves the exact purpose of changing the order of the midi layout of the .scl file you imported), Pianoteq overrides the order specified in the .kbm file and still reorders the list incorrectly.
So I beg of Modartt to add the feature of allowing the automatic reordering of intervals in a .scl tuning to be optionally disabled so that tunings that fit the criteria I described don't break when you try to import them into Pianoteq. This has been a really frustrating problem because I can't seem to find any sort of plausible workaround to counter the fact that Pianoteq forcibly reorders the intervals even if reordering them is objectively wrong and breaks the pitches of different intervals in the tuning. Like Pianoteq reordering them doesn't just change the order the midi notes are in, but literally modifies the tuning itself so that it doesn't contain the same pitches as the .scl file.
P.S. while you're at it Modartt, please A) allow the optional option to not change the tuning when you change the instrument, since I really like being in a specific tuning and trying different instruments out in that same tuning, but it always forcibly resets to 12edo and string tension when it would be much more practical to have the toggle-able option to keep the tuning the same when changing the instrument. Also B) please look into glitches when inputting in specific numbers as divisions of the octave. If I remember correctly, typing in 13.5 (or maybe it was 11.5 or 12.5) doesn't result in that many divisions of the octave, but instead glitches Pianoteq and gives you some stupid wrong tuning instead that's most definitely not the same tuning as the number I inputted. The fact that Pianoteq glitches when you put in some decimal edos is an important bug that should be please looked into and fixed.
If any of you know of any other Pianoteq glitches that really ought to be fixed, please reply with them below.
-Carmen