Edit: I modify this post, as some bugs were my fault, and some problems are new.
So I changed to Scala files which span not one, but several octaves, but I did not modify the base note accordingly. It should be C#1. If it is G#4, Midihub wraps the scale around and also, the cent values exceed the 127 Midi notes. But in theory, it is still a valid scale.
In test2.scl, every 19th note in that scale has a cent value of 3000 just for tests. However, Midihub changes all 3000 cent values to 0 as if it had problems with either abrupt cent changes or a tuning which is not strictly increasing. It seems contrary to the scala format which says nothing about cent differences, nor about monotonicity.
Anyway, if base note = g#3, f3 (midi value 33) is translated to c1 -1365. This low sound is probably what Midihub understands by 0 cents which it has put in place of every 3000 cents (not the “normal” 0 cents, which should not be as low). There are also few other notes out of tune as expected, not at distances of 19 because of the wrap-around. Yet, these other notes are not as low as f3, even if they also have cent values of zero.
To sum it up:
- strange pitch bend values in Monitor;
- does not support rapidly changing and/or non-monotonic scales (small problem, as I need such a tuning only for tests, but someone other may need it);
- occasionally, Microtune produces whatever (a scale read from a random place in memory?), requires a power cycle. Did not happen yet for the scale with base note=c#1.
A new small problem, related to the interface: changing the base note disables “always send pitch bend”.
The problem with Microtune requiring a power cycle is different from the one I had with previous versions of firmware. Previously, channels became confused. Now, there is a problem with frequencies. Maybe the channel problem has been fixed already, but the frequency problem is triggered only by the scale with base note=g#3?
test2.scl (1.8 KB)