Low priority (technical) suggestion on scaler state file content

Hi Ed

No inappropriate intent here at all.
One challenge of Scaler is the sheer exercise of exploring the vast number of permutations and combinations of the possible independent parameters one can amend. What creative gems are hidden in some combination of song / performance / grouping etc ?
The logical approach is to write down the various sets of parameters and then work through listening to all the variations; however, they can be cut down because I am not interested in certain genres, so that enables a significant reduction to only a six figure number or so :worried: . However, discovering the ability to save state made life simpler, because I could save the state of anything which I thought might be a good future candidate, rather than writing things on a sheet - much quicker. The issue here is that I would end up with n XML files, a directory of which would provide no information other than when they were produced.
To provide a better framework for a ‘database’ of musical possibilities I first back engineered a random state to create a more readable schema. The use of UUIDs made this harder initially to figure out how to extract further information (although it did point to an obviously elegant architecture in your platform). I then simply created pairs of states (e.g. C ionian /C aeolian, C ionian / D ionian, trance 6 / trance 7) and had a look what changed (actually very little, which indicates an sophisticated design).
This would indicate I can tie this up with a simple parallel key/value pair structure derived from the analysis above (although I’ll probably use a triple store) to which I can also add information like a rating and so on. This would enable me to achieve goal 1, which is a mechanism to list out (and indeed, search) from a ‘database’ the potential starting points for musical pieces. Perhaps then, to be able to find a sub-set of possibilities sharing common defined attributes to explore starting points.
So why the request ?

The date gives a unique key within the data as opposed to having to interpret this from the file name, and then to add that to the key/value list - it’s better in the Scaler data part, so the XML mapper can create the database record.

The schema request is because the XML file is ‘well formed’ but from the perspective of some software, ‘not valid’ without a schema refence. I can only map / extract / report if there is an associated schema. It would be useful if, rather than have to edit every state saved it could be added to the file by the system at creation time.

So I’d be able to ask/see “what are my top best rated ‘states’ thus far?” / “What was good in E Lydian?” Consider the number of possibilities Scaler gives to come up with some progression and melodic sequence - it’s humungously large, and auditioning it in some unstructured way would be inefficient (and a full time job :blush: ) So it’s a bit of work now, but it would enhance my use of scaler.