That makes sense :slight_smile: .
Is this last layout feasible though?
If the respective presence/absence of the BANK option is dynamic based on whether the user selects LOAD or SAVE from the first menu, it seems nicely streamlined.

Feasible? Yes! I don’t even think I’d need to refactor anything.

It’s actually quite attractive, I like it! :+1:

Also, note: We’re going to need a “back” icon to squeeze into the selector. Bitmap your heart out! I only say this so that because the text is seeming crowded and a lightweight icon would prevent BACK from becoming hard to see.

ok, cool.

Tell me more about the BACK button.

What situation is it needed for? If someone wants to go back and change their previous choice in the menu structure?
Where do you see this implemented? It seems that there would have to be a “BACK” option on every step, which would be a crazy/cluttered solution. We are looking at 5 step menu choices, would it not be possible to change the NO in the last menu to a BACK button? And change the order so BACK is on top:

BACK
YES

So you can just cycle through the menu options indefinitely, until you are happy with your choices in which you select YES at the end and commit?

I suppose if we want to absolutely be sure that someone is not accidentally overwriting anything, we could add an extra step/screen after they select YES, that just confirms this choice… like “ARE YOU SURE YOU WANT TO SAVE” etc. or something to that effect. Or just one word: COMMIT.

Yep!

What happens if you select the wrong bank and are now selecting scenes from the wrong bank?

You cycle around and change the bank… until you are happy with the settings…

I mean, it really is not that many steps, and you can see all the choices you made at all times. My thinking is that having the button always move forward, and when it reaches the rightmost column it defaults to the top selection, which would be BACK, it cycles back to the first menu choice that still is set to what you have just chosen, so just clicking the button through the choices back to the one you need to alter seems pretty intuitive to me. Don’t know though: might be one of those things that one just needs to see what it feels like in use…

In the “Tentative Menu” in the top post, @tehn notes each back button with “(+<)”, and the context of the discussion at the time was that back was obviously needed when menu-diving.

I really don’t like the cycle-through routine. A dedicated menu option where turning the knob fully left and hitting the button goes back a layer each button press is very attractive compared to punching through.

I see what you mean.
So that each menu has the BACK icon or some such as the top choice…
OK, let me sleep on it. :wink:
Honestly though: that almost seems like more work for the user, since they will need to use the knob AND the button for this operation. And if they need to move back more than one step, that is a lot of fiddling with the knob and button… no?

No. the knob stays in the leftmost position, and the user presses the front button to repeatedly step back through the menus.

The menu will jump to the knob value after pressing back, I think is what you’re missing.

Hmmm.
So, hypothetically, if the user made their choices for all the bank/scene settings, and is at the last/commit menu, and they realize that they should change the source scene, OR better yet, that instead of SAVE they have selected LOAD, and need to change that, then they will have to back through the all the menu sections, which will reset their selected values to the “back”=top of the menu?
Did I get that right, or am I missing something?

Yes, but it’s not like having the back option prevents you from pressing “NO” at the end.

If you’re going back, it’s because you have to fix something, so the knob jump doesn’t matter.

@laborcamp, I just realized re-reading the last few posts that I wasn’t clear in what I was asking for.

Just to be clear, I’m looking for an icon that will occupy the top position in every list that looks like a left-facing arrow.

Guess I could use <-

I guess I do not understand what kind of participation is agreeable.

What I tried was expressing that I find the UI confusing since it looks as if it allows loading to multiple banks on tt.

Why not keeping the discussion private when contributions disturb the process?

:man_shrugging:

The problem with that is that it then ends up excluding all the other developers from making contributions. We’re even lucky enough to have quite a few users on here from other manufacturers that are able to offer technical insights from their own experiences.

It’s also a major hindrance to future developers if they can’t go back though the forum to see the reasoning behind decisions.

1 Like

Just to state the obvious: it’s a forum.
And a forum is all about everyone’s participation.
I am grateful for every voice.

3 Likes

Got it.
I will give it a go today after work.

I’m sorry, I reacted before I fully understood your concern.

Rest assured that where visual artifacts suggest a deviation from the approved functionality, it is not meaningful. I will ensure that the approved functionality set is implemented.

1 Like

We’re probably going to keep chiming in. We’ll try not to ask dumb questions. It’s probably going to happen anyway though. I hope it’s not too irritating, as irritation is never a goal.

3 Likes

I appreciate the input. I was frustrated with myself that threads that I participate in become bloated and hard-to-read, and I responded rashly.

3 Likes

Hugs everyone!
:slight_smile:

3 Likes

I think there are only three options that would be simple enough and sty within the TT esthetic:

<
arrow
BACK

here is what the arrow could look like:

I also am thinking of what happens when you load from a bank TO a SCENE (so the BANK destination is blanked out with ----)

I replaced words EXIT and NO with arrows, since effectively they all indicate/execute “going back”, but am not certain whether that simplifies the interface or just introduces too many arrows pointing back?