I’m working on something related. I’ve back engineered the state schema, and am looking to create a data structure fed by saved states to allow some means of multi-parameter queries across them.
This will greatly save time in trying to audition through x,000,000 permutations implicit in scaler, something on the lines of
1 select some scale and mode
2 audition with a performance, noting any dissonances etc in any of the harmonised chords
3 Sounds ok → save / not good → back to 2.
4 run function to add saved states to database
5 add tags as desired
6 report and/or query
Scaler appears to be elegantly architected, and there is not much you can directly gain from looking at the XML, because of the use of UUIDs. However, by doing some differential analysis, and relying on the uniqueness of each UUID, you can figure out a key/pair relationship and build up (in parallel, using the time stamp as a common key) something useful.
As an example, compare the state file of C ionian and C aeolian. Only the UUIDs of the selected scale and the root note change. I sort of expected the ‘progression’ data to change, but Scaler is way smarter than that.
More interesting is comparing C ionian and B ionian, where only the ‘noteFilter’ attribute changes. This gives more insights to the workings.
Happy to keep you posted on this project as it evolves, but maybe we should do that off line ?