#81

Just to add: I will make the layout for the Configuration Menu once the design/navigation approach is discussed and agreed upon here.

1 Like
#82

I can scale the knob value to any value. I had coded up an even-division scheme where, e.g., YES is left-of-center and NO is right of center, but I can do a fixed scale with a wrap-around no problem.

The scale might be tricky because banks can go up to 257 entries.

#83

Yeah, I was thinking about that. Two things:

1/ The content of the “number menus” in LOAD category can be adjusted to only show things that are actually there, and not display the empty slots. Even in the SAVE menu it can show only the existing “full” slots PLUS one extra slot to save to.

2/ With scaling of the knob behavior, I think rotating even through the list of 257 entries might not be bad, if the “precision” of the knob is adjusted to the speed with which user is moving it.

#84

I really like the approach! How about combining it with the configuration menu? We could save one screen then to know about which feels simpler and more minimalistic to me - LOAD/SAVE would just not work then with no USB drive plugged in.

I think when you really have 257 banks on your USB drive you have earned the privilege on some extra encoder turns…

#85

Way ahead of you on that: the core was built around this assumption.

It’s a pot, not an encoder. I’d rather not do anything with the speed of the turn.

Also, it would be 256 banks + BACK

#86

Totally agree!
:smile:

#87

256 values on a turn of a pot is going to be hard work. I even find the 128 values I have on the pots on my Korg Radias hard to dial in quickly.

I guess it will be something that’s easy enough to change, but be prepared for the number of banks being closer to 32 or 64 in order to be usable.

(edit, lovely design @laborcamp btw)

3 Likes
#88

I expect that people will not have anywhere near that number, even if the system is capable of it.

This makes the case for automatically scaling the knob to the number of selections. It’s predictable, but requires significant travel for few values, if you consider ~> 1/3 of a turn to be “significant” for a 3 value list.

It’s intuitive, I think.

2 Likes
#89

Just realized, @laborcamp, we need to allocate more space for column 2 in your mockup. We will now need more items there due to to the loss of the title bar.

4 more chars for SRC or DST plus a space.

Additionally, I can write the first line of the scene description on the bottom line of the screen if you want to simulate that.

#90

A couple more thoughts:

  • Perhaps instead of the highlight bar moving, it could always be in the center. Then turning the pot is like rotating a cylinder.
  • The third column (selector) will not need to be present when the OK window is shown. In fact, that window should probably be converted to a more “dialog” look and feel because some of the confirmation questions are critical, e.g.: overwriting a scene or bank.
  • Exit / Back should always be the first or last option in a list. Probably the first, as turning the dial left feels more like “back” to me than turning it right.

Also, I just wanted to say that whatever I had in my head would have turned out much worse than this is already going. Thanks for the high-quality contributions, @laborcamp!

#91

I wonder why I cannot follow anymore - is it me being a bit slow or are you just discussing it via PM to avoid the forum noise of deranging / uninformed opinions?

I think this would not fit very good into the tt design as parts of the menu would get hidden at the screen edges. Moving the cursor seems simple and beautiful to me.

Additionally, I can write the first line of the scene description on the bottom line of the screen if you want to simulate that.

I like this idea!

Also I am very thankful to @sliderule developing all this and @laborcamp for his dedicated work on all those beautiful descriptive screen mockups!

#92

This is all in the open. :man_shrugging:

#93

@laborcamp the layout looks fantastic!

understood that the destination needs to be selectable.

256 banks is going to be way too many. i’m pretty sure the scaling of the pot will be a problem at this resolution. in my opinion, 64 banks would be more than enough.

in general the pot position management will be tricky. ie, when you enter the usb mode with the pot at mid-value. unless you want to do some sort of dynamic scaling (ie, left is one speed, right is another speed-- and then each value change retunes the “step”) we may need some sort of first instruction to “reset” the pot back left (CCW).

i’d almost suggest the left-most position (top left of the menu) be EXIT, so it’s fast/intuitive to get out of the screen without a tuned micro-gesture.

#94

I guess then it’s just me. Anyway, I am sure it will turn out great in the end.

:+1:

1 Like
#95

Sure, I can limit it there. I just went with uint8_t limits, but I’ll throw in a hard cap at 63.

Why not just scale the pot value to the number of options. Examples:

Top menu:

  • First third “Back”
  • Second third “Load”
  • Third third “Save”

Selector:

  • Divided into 33 slices for a full bank

Dialog:

  • Left half “No”
  • Right half “Yes”
#96

yes, you could do that. might feel a bit awkward with varying degree-turns for switching between menus, and the position of the next menu popping into an unexpected position. ie, when you select “Save” the selector will always start somewhere in the last 1/3 of the numbers and you have to wheel it back.

definitely the easiest, though-- and this could be refined at a later point. so yeah, it has my vote.

#97

You know, the original design did not require selecting ‘DST BANK’ or anything like that because they came in sequence.

i.e.: Save -> Src Scene selector -> Dst Bank selector -> Dst Scene selector -> confirm

So the user will never actually be navigating the second column manually, it auto-advances.

Also, we can leave room for the selected Scene / Bank number right there to show progress.

Also also, the menu was supposed to be “deep” with SAVE going to [SAVE BANK, SAVE SCENE], but we can flatten out the first menu.

E.g, while selecting the destination scene in the SAVE SCENE operation:

EXIT       | SRC SCENE   5 |   16
SAVE BANK  |  DST BANK  11 |   17
SAVE SCENE | DST SCENE  __ |   18
LOAD BANK  |               |   19
LOAD SCENE |               |   ETC...

I should have caught this sooner. I was taken aback when @laborcamp designed this all in one screen. I imagined each of these modes as their own screen, so I just listed off the type of screens there were.

#98

OK, I got lost a bit in where things stand right now.
Is the interface paradigm I proposed still there, or are we rethinking it?
I have a bit of time right now to get something going, but just want to make sure my head is in the right place…

1 Like
#99

Your paradigm is fine.

  • The first and second columns need to be wider. See my text description above.

  • The okay dialog should obscure the selector column to allow more text, and should possibly take a different look and feel to signify the importance of confirmation. Maybe 2 buttons side-by-side?

  • Leave the final line for the first line of the scene text, allowing preview

#100

OK.

Meanwhile, here is a slight variation on user selecting
SAVE FROM > TO and
LOAD TO < FROM

Navigation as per above description, using combination of PARAM knob and module button.

45 AM
Screen Shot 2017-10-24 at 11.41.45 AM.png1816×612 21.9 KB