User Scale feature development

I think the User Scale is really useful, so I hope the beta continues to get developed. Two obvious features: make the changes to a scale persist across scale changes and power cycles. To avoid that kind of destructive editing, create some user scale slots (4 or more) dedicated to destructive editing of scales.

Yeah this is something that is on my list (which I’m hoping to include in 1.4) but I’m still not sure what would be the best way to improve upon the idea.
I’ve thought about 3 different ways this could be expanded but so far I haven’t decided which would be the best option.

Option 1: Have 1 global user scale that is saved to the device’s memory / EEPROM.
This would be the easiest option to implement but it’d be quite limiting since you’d only have 1 custom scale. It’d also mean that modifying it would end up affecting all projects that use the custom scale. It would be possible to add a couple more but I do worry about using too much of the available space and end up compromising other future ideas.

Option 2: Save the custom scale to the project file.
This would let users have different custom scales per project but if you’d like to use the same scale for different projects you’d have to recreate it every time.

Option 3: Save custom scales as files.
This might take a bit longer to implement (since I’d also need to add options for editing scale names, etc) but it would be doable. It’d also require some sort of fallback in case the user tries to load a project that uses a custom missing scale.

Personally I’ve been leaning towards Option 2 mostly because I also plan on upgrading the template system to let users load projects as templates, which would solve the limitation I mentioned.

I’m definitely curious to hear what people think about this and I’m also open to other suggestions!

Yes, it looks like Option 2 is the best practical solution because re-creating a user scale should be easy enough for anyone who is already interested in customizing scales. Assigning a custom name to the scale would make it easier to keep track of things, but even if the names have to be fixed to something like “User 1,” User 2," etc., it would still be useful.

One quick-and-dirty beta-level idea: let the user destructively edit the factory scales. As a “power user” feature, the user would then be expected to keep track of things. Six of the current scales are diatonic modes, so for a workaround, choose MAJOR for the scale, then assign any of the other five to a track via the OFFSET parameter.

Since you asked for other suggestions, consider adding microtonality (such as 19-EDO) via channel pitch bend. Microtonal tracks would have to be monophonic because pitch bend affects the entire channel, and notes that aren’t octave equivalents require different pitch bend amounts.

Currently the scales are stored and loaded from the flash memory so, to let users edit them, I’d essentially have to implement something like Option 1.
Option 2 does seem to be a better option in terms of flexibility and storage. I think having a single “User” scale that gets stored in the project could work for most use cases.

Yeah something like this has been on my someday list for a long time. It would be a really cool niche feature to have but it would take quite some time to implement properly and I think there are some other things I’d like to add and improve first.

1 Like

More than one would be nice. I work with custom scales that aren’t simply related by offset. Sometimes eight of them at a time.