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?
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!
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?
I think that the arrow is only required for the selector, really. Maybe 2 chars wide. I’ll put it together and I can figure out offsets as it’s dense. Thanks for mocking it up!
Great!
Yeah, I felt it was too many arrows.
I suggested a longer arrow (3 chars) mainly to make sure that it is not confused with
< or >
that are used in other instances.
Either way: it works.
bump for any format discussion, now that the interface looks spectacular
1 Like
With Grid Ops coming along, and new versions of TT imminent, are there any updates on the disk mode stuff?
Once TT Grid scenes start appearing, I can see a lot of people wanting to share what they made, and use awesome grid apps made by others (myself included).
3 Likes
USB disk mode interface in this manner relies on Serialisation of Presets (IMO). Implementing the USB interface redesign before that change would require a new text parser for the existing format to hook the new more-stateful UI. I’ve written one but it’s untested and would need to be rebased and also grid stuff would need to be ported.
So, essentially what you’re saying is “don’t hold your breath”
It’s not a very big job code-wise, but it needs some discussion and consensus to move forward. So… 
It is a tiny piece of the overall conversation here, but I have a PR that does this specific bit quoted above: splitting the serialization code from the IO code and adding unit tests. Proposal: separate scene serialization logic from USB disk logic, add scene serialization tests by Dewb · Pull Request #287 · monome/teletype · GitHub
It’s been thoroughly tested in software and lightly tested in hardware. It doesn’t preclude any of the more extensive changes discussed here, but hopefully makes them easier to contemplate.
2 Likes