Closed mirabilos closed 5 years ago
odd, the code doesn't even inspect the current tuning, it just applies the new one according to the pitch. I'll see if I can reproduce the bug locally.
As I said, perhaps it’s a bug in MuseScore itself which only is exploited through the plugin.
Perhaps just setting a tuning, then resetting it to 0 (maybe after saving? quitting?), might trigger it.
Sorry it took so long to get to this, but it's fixed now.
The symptoms were if you chose a different tuning then re-selected the equal one, it works fine, but if you just open the plugin and hit apply, relying on the default, it fails because the setup code to assign the initial choice of equal temperament wasn't getting triggered .
The reason I could't reproduce was because when running it from MuseScore's Plugin Creator, it all works fine, but when running it as a plugin normally it behaves differently and badly.
I guess that's a bug in MuseScore, just not the bug we were expecting.
When I have a file in which a tuning is already applied, for example, A4 reads like this:
When I then apply, with your plugin (unmodified), a tuning in which A has offset 0 (e.g. back to equal temperament), the XML gets rendered thus:
(NaN being “not a number”, of course.)
I’m not sure whether this is a bug in your plugin (does it ever divide by zero?) or in MuseScore 2.2.1 (does it fuck up when setting
note.tuning = 0
?) but I’m reporting it here first, so you can check that.Removing all these bogus tuning lines (e.g. with
perl -pi -e '/<tuning>nan/d' *.mscx
) fixes the files locally, but of course that is no solution for the average user.