Low priority (technical) suggestion on scaler state file content

Saving the state is a great feature, and this request is to suggest two minor changes to the current format.

1 The file is identified by the file name timestamp. It would be really useful if this were to be added as an element in the file i.e.

(left bracket) ScalerState (right bracket)
(left bracket)InfoState versionNumber=“2.3.1”/(right bracket)
(left bracket)TimeStamp= “2021-04-22_161758”/(right bracket)

2 Add the XML namespace definition, leaving the schema instance blank facilitating picking up a schema to execute XSLT to extract certain data i.e.

(left bracket) Scaler version=“2.3.1” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:noNamespaceSchemaLocation="" (right bracket)

Just a thought …

Hi @yorkeman

thanks for the suggestion, those are good technical recommendations.
We can definitely add this in a future update. May I ask what you are trying to achieve by extracting info from the state outside of Scaler?


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.

Cross-posting this, since topics seem related.

So @yorkeman you’re basically using the Scaler state XML file as sort of an API, to programmatically create permutations. Sounds like a workaround for Scaler currently missing automation options via MIDI. Do you think this capability could be achieved with Scaler’s parameters being surfaced via MIDI? Then you could use DAW automation means to create permutations. At least that is something I am looking forward to. If you take a DAW like Bitwig that is hyper-programmable, imaging how you could make a “programmable” Scaler sing! :slight_smile:

Not wholly. Firstly, the project objectives are not really in my mind anything that one would imagine falls to Scaler to do, for multiple reasons. Secondly, it’s an API only in the sense of being a read-only channel for an extract / transform / load process. Thirdly, it is perceived to be wholly subjective and not appropriate for Scalers architecture, which is a generic application. In a nutshell, this doesn’t imply any change to Scaler’s functionality.

If you look at the examples at the end of my post (“what states have I saved in E Lydian’”) Scaler doesn’t know, nor could it do so.

Anyway, I’m still at the viablity stage; can I extract and transform the data and lodge it in some data structure in way which (a) enables me to relate UUIDS to relevant meaningful values (b) allows me to extend the schema to embrace useful classifications.

It may not be possible / practical. I shall kick off with Talend https://www.talend.com/ and see if it’s something I can find the time and energy to do.

Yeah, I’m familiar with Talend and ETL tools/process. I guess I’d rather stay within the realm of musical tools for these explorations, as a human. When I start spending more time with coding & technology around music, I am missing the point why I got into music as a hobby in the first place. Even when I say “programming”, I mean twisting knobs, sliding faders, pressing buttons, either randomly or with method, and “analyze” with my ears, and sometimes others’ ears :wink: to see how it sounds, purely subjectively. One can go overly with seeing the world only through the lens of data science instead of the arts in themselves.

Believe me, I’m in complete agreement with your sentiments. My heart sinks at the thought of ‘hands on’ technology stuff, which I gave up about 50 year ago (although I was in the software business all my working life).
As I noted in one of my first posts, the challenge for Scaler users is that the possible permutations within scaler are huge, so how does one find something which would be a good starting point? I can cut the number of items to audition down by ignoring things like D &B (I hope Davide isn’t reading) and look for candidates which might be my thing (ambient, melodic trance sort of stuff). Of course, starting with assumptions about what might be good might mean that there just maybe something in one of those D&B things which is perfect…
Auditioning is slow. I fire up Scaler in Cantabile and then wade through methodically using a basic set of harmonised scale chords to see how each progression etc sounds. Some are really good, some ok, and some have bad dissonances etc. It’s slow, and I have to write down the combinations used in each case for future reference. I then need to audition songs and artists for some progression that might be good, and save those, in order to combine the two elements.

Using the state saving I can audition, then save or not save depending on the potential. Slight simplification there in what I actually do, but it’s vastly quicker.
However, I then have a wodge of xml files with no obvious way to figure out what they are from the content. So if I have an E Lydian progression, what might fit ?

So I thought all (ho, ho) I needed was a searchable list of the combinations I had saved (“cognisable to the human eye”, as my old contracts used to say about source code), and there is no way to do this now. I thought if I could map the state xml into something identifiable, then I could store that in either a structured file or as a modified XML structure in something like BaseX.

So this exploration is a major PITA, and I want to get back to exploring the wonders of neo-Riemannian meandering and churn out a few (bad) tracks, but I’ll trash a few hours on seeing whether this approach is actually feasible within the time budget I’m prepared to give it. [BTW, I don’t work, and COVID has trapped me at home for most of 2020…]

LOL, :rofl: you are risking to be :boom: