Better settings management

Aeros Loop Studio Feature Requests
1

Problem statement

I find the way settings are managed kind of counter-intuitive between the global config and the song config and find always myself looking first in the song settings before realizing it’s actually at global level. Having then to switch back to main menu, reply if I want or not to save the song etc… And redo that again and again with the next song :stuck_out_tongue_winking_eye:

This topic is a proposal which goal is to lead to an easier config management, more versatile and potentially even more resilient regarding firmware updates.

All this for me comes from the fact the split between what is today the global config and the song config is arbitrary and at least not really consistent.

Song config

The song config contains settings that have clearly their place at song level, but they lack some default values.

Global config

The global config contains some settings that are really system-wide, like all those related to routing for example.
But it contains as well some settings that are arguably system-wide, like clicks management for example or even flags related to how transitions should occur. They could completely be at song level either.

Proposal

Pre-requisites

Everything starts by first identifying the global settings that are really system-wide. And really apart routing and maybe some MIDI settings, I do not see any other.

Recipee

My proposal is to migrate all settings to global settings, without exception.

When a song is created all song-related settings present at global config level (let’s call them template settings now) are duplicated at song level and become the song config. You can then tweak them without changing the global settings (like clicks for example, that you may definitely want different for this or this song).

Impact

  • You simplify navigation within the device to access settings.
  • You bring more features in terms of tweaks at song level.
  • You introduce a nice templating mechanism for song settings values
  • Here it’s just a guess and maybe I’m wrong, but I feel like if you introduce new stuff at global template level (now in global config) with a new firmware, you would not impact previously recorded songs, which only need their local config (a kind of backward compatibility).

From a development point of view depending on your architecture it may be not so costly (there I am in full guess mode, so forgive me if I’m wrong):

  • The UI is already there, not necessarily at the right place.
  • You probably already build a kind of context when you start a song. You would just build it differently (probably simpler).
  • You impact the song creation flow by introducing a settings copy mechanism at that time.

Even if obviously not urgent, if you assess such a migration is not so costly, I would definitely say that it brings a lot of possibilities while bringing a much cleaner navigation flow for the user.

Feedback welcome.

5 Likes
2

Interesting proposal, it’s worth exploring, I know we want to simplify the menu, this may not be the route we choose (due to currently unforeseen factors of which there always are) but is definitely an option.

I do not, however, think that 6x6/2x2, quantized/free, time signature, and tempo are practical as Global settings. I don’t know if that limits the application of the idea in any way for the other settings, I’ll bring it up.

The most attractive part here is the idea of song templates.

3

Hello @BrennanSingularSound

Could you please consider tagging this request ?

4

Hey there, we agree that we need to work on the settings mgmt, but this is low priority right now. We have spoken about it, however, so we have all the intention of bettering it when the time is right. Thank you for your feedback.

That being said, we don’t know yet how we will implement, so we will take your suggestions under consideration.

1 Like
5

An idea I’ve had while using mine would go a long way to managing settings and is a tiny change…

Make it so a song can be saved when nothing is recorded to it. In that case it could be labelled as “ballad settings” “6x6 ABC sync start settings” or whatever we liked and we’d have that collection of settings ready to go.

For bonus points, mark songs without audio recorded as “templates” in the UI (or whatever nomenclature seems best to you).

Edit: latest firmware seems to support this save-empty already. Excellent. Little fixes like this are making huge differences for me.

1 Like
6

That’s what I did/wanted from the beginning on. I only do full live performance. Unfortunately, some important parameters are under settings by design instead of song level. Let’s make SS change this.

Have a look at this post and support it please: Urgent Change Request: Song Settings (Lock Track related)

7

Yes. The only settings that seem justifiably global to me are anything that is to do with physical connections, which we can assume don’t change. There seem very few that fall into that category though.

I like @LaurentB’s proposal that global settings effectively become “default” settings; but I’d also advocate for a different method. Global settings become the things that really only apply to the entire system (and there aren’t many). The song settings should then be handled with the ability to mark a song as a “template”. They’d probably forcibly have no song content and simply be a way of naming a set of settings. Then the “defaults” come when we create a new song from a particular template. I know I don’t only have one standard set of settings, so a single global set of defaults wouldn’t be that useful for me.

1 Like
8

I agree that templates are cool, but I didn’t want to scary @BrennanSingularSound too much :wink:. The problem of what you you suggest (yet I agree for me this should be the target solution) is that it introduces a third level of config (the templates), implying new icons, menus, flows in the UI etc… whereas relying on what exists today (2 levels) is probably more realistic for a first phase…

But once a mechanism to create the song config from a template (the global level) exists, it may be easier to go for what you request. Let’s see it as a phasing :slight_smile:

9

Actually I just envisaged a ‘template’ toggle on the settings screen. The primary difference between templates and songs (if we use Word as a model) is that when you open from a template it’s still “untitled”. Other than that they’re just ordinary songs with their settings defined exactly as they are in your model.

10

The problem is that this simple toggle has impacts. Let me show you why I think my solution is a step towards what you actually want. My goal is that Singular Sound agrees to do things we want, and for that we need to bring use cases where there is a lot of benefits while minimizing the risks and complexity.

I think there are different aspects to take into consideration:

  • How the configuration available to a song is accessed at runtime. Let’s call that the “contextual config” or context.
  • How the initial config of a song is created.
  • How the config is managed from a UI and user flow perspective.

Runtime Access to config or context

Let’s assume the totally silly idea that currently the code is full of getGlobalConfig(blah blah blah) and getSongConfig(...).

So all our both proposals have actually the same impact if we change in which bucket this or this config flag goes we have to change everywhere in the code how to access it. I know it can be tricky depending on how config access is already managed and requires to be confident in the automated tests.

Let’s face it, we will have a hard time convincing devs to do it. There are options to mitigate the problem etc, but this is not a simple patch.

Initial Song config creation

Today, when we create a new song, its config comes with default values. meaning that internally there is already a kind of “template” (probably more a default structure) to create it.

My proposal is to have only one “template” or set of default values for when you create a new song and to have those default values within the global/system config. And of course you generate the initial config of a song from these.

You propose to have a set of possible templates from which we could create new songs. And generate the song config from one of them.

So here your solution requires already a bit more complexity. At least a mechanism to know which template to use when creating a new song.

Config management

In my proposal, no new screen. The Global config contains all setting both the real (few) global ones and (separated somehow) all those related to a song and which in this case can be seen as default values for created songs. We can absolutely see the second part of the global config as my sole and unique “template” in this case… So in the end, same number of screens, no new user flows, only the set of properties displayed in global and song config differ.

In your proposal, there is potentially a lot to change in the UI and even flows:

  • Templates management. That could be light, if the only change is a toggle switch… But you may want to identify them from the list of songs, etc…
  • From where to allow to create a new song. If from the template it is not really practical, if from the main screen as it is it introduce a selection of the template to use and even if there is one by default (another ui config somewhere), an extra click.

No doubt the template solution is heavier to put in place.

For me the template solution is superior in terms of features it brings and should definitely be the target, but I think the solution I proposed is a reasonable step towards that direction that should be far less costly to implement as a first phase.

11

Then you and I, at least, are in complete agreement.

To address the complexity issue though (since I get the distinct impression you’re a techie too :slight_smile: ):

Perhaps I’m being overly simplistic… but if I were designing, I’d substitute all getGlobalConfig(KEY) and getSongConfig(KEY) for getConfig(KEY) – the caller shouldn’t need to know where a particular key came from. The in getConfig() it looks first in the current song config, then, if not present it looks in the global config – if one of my devs took more than a day for that, I’d be very disappointed. That’s the fundamental work for your suggestion too.

Next is a toggle on the song list to mark the song as a template. Depending on the UI library, this is potentially not easy, despite being simple in presentation.

Finally, one new screen: when the “new song” button is pushed, an extra popup appears listing all those songs with the “template” flag set. You pick one, and a new song is created as a copy of that song.

I’ll certainly agree that it’s the more complicated option – how could it not be. I don’t think I agree with “it’s not a simple patch” though. Given what is already obviously present in the code by observation, it’s just a bit of plumbing. (Although as a colleague of mine is fond of saying, all project management evil is represented by the word “just”).

I’m certainly not unreasonable though: none of what I ask for is a demand; and what the hell do I really know about the code base internals? I really only say these things so that they potentially enter the Singular Sound consciousness. I don’t think they’ll implement anything they don’t think is a good idea – but perhaps if I throw enough of my crap at the wall, some of it will stick :slight_smile:

12

Although you’re right, I have a bit of technical background :wink: , I try not to enter into those considerations within this forum for 2 reasons:

  • This is not a development forum. I don’t think people here care a lot about tail recursion or containerization orchestration or whatever dev concept.
  • If I would do a parallel of this forum with a dev process, I would say that those of us here who try to sketch solutions for various problems, play somehow the role of the PO in agile. And POs suggest functional solutions not technical…

That said, I tend to see the over-optimism of the youth in your answer :slight_smile: . Especially in the world of embedded software. But we could discuss that offline if you want. I would prefer to keep topics on the what and let the how to the relevant people. That doesn’t prevent suggesting or even evaluating the relative costs of various options to ease the decision or strategy…

1 Like
13

Agreed. Apart from the youth part… Oh how I wish that were still so. :slight_smile:

I’m certainly enthusiastic about Aeros though, and it seems we’re closer to the developers on this forum than is usual for product forums (I literally have never joined another user forum), and I’m afraid that means my techie half can’t help but leak out. I do try not to go too far though and I can only hope the other users forgive my noise.

1 Like
14

Done in 5.0.0

:slight_smile:

We have Organized all the Device settings into categories:

  • Routing
  • Behavior
  • MIDI
    • MIDI IN
    • MIDI Out
  • Hands Free
  • Pedal
  • Fades
  • System
  • Diagnostic
2 Likes