This gets at the heart of the design challenge. Minimum font size ends up being the determining factor for available information density, which in turn has maximum impact on visual hierarchy and information architecture.
In other words, minimum font size ends up being the single most important design choice to get right.
One of the best ways to make font sizes accessible (usable at 20/70 vision, the section 508 requirement) is to make sure your font’s x-height (the distance from baseline to the top of lowercase characters) is at least 0.3 degrees of arc.
It’s also a good idea to take into consideration the screen’s PPI density. There’s a handy calculator on this page that does all the math for you:
(yes, I know, we’re not designing for the web. My goal is to take the difference in usage into consideration.)
I need to spend a little more time with that calculator, because I stood at a typical posture for using the SSP, and held a tape measure from my eye to the screen, and given the ~40" distance I came up with, the calculator seemed to suggest I shouldn’t go lower than 48pts! That’s about 4x the smallest font size I’ve used in my mockups.
So, definitely back to the drawing board, but before I go there, the really critical piece of information we need to agree on is typical viewing distance.
What does “live performance situation” mean in practical reality? I have a 204HP case, so, for me, the SSP is never likely to be much further away (when I’m actively manipulating it) than a fully extended arm’s length. Do other people expect to use the SSP at greater distances than that, in typical scenarios?
Right now the MIDI output list is 16 pages long. Need to get more of that list on the screen at once if “no menu diving” is a genuine goal. 5 items at a time just isn’t enough.
I merged them with the scopes. I don’t necessarily see the scopes as “essential” (though they could potentially add useful information to the patching process, I certainly use similar scopes on the ER-301 when deciding which voltage source to apply to a parameter) I did want to show a correspondence between in and out for a particular parameter (including the names of both source and target) in addition to any scaling factor, and I was looking for a way to lay out that data. Putting it in context of a scope seemed logical. Not sure if that decision still holds with larger font sizes, it’s a question I’d have to work out visually.
Yes. Although, there’s still scrolling involved for very long i/o lists.
Does it? My understanding of the patching process (enable inputs, enable outputs, patch two modules) seems to indicate that you are considering inputs and outputs independently of one another, one at a time.
But I’m not opposed to the idea of having them simultaneously visible. My main goal was finding a way to have more than 5 on the screen at a time, and to give each one more space for additional display of relevant data.
This was a consequence of showing more than 16 module spaces at a time.
Definitely also interested in @NeilParfitt’s opinion. One thing that bothers me about the current setup is the need to hold shift while tapping the corresponding softkey. Makes it either a two-handed operation, or one that requires a more dexterous right hand gesture. I’m not touch typing here (remember, my arm is fully extended and I’m engaged in a “live performance”), so I’m suspicious of “shift” notions in general.
Not really. In fact, I can imagine moving this toggle to a global preferences page. Set it and forget it. It’s probably a better idea. Gives us another soft key to play with.
Which is still completely possible with a single encoder if inputs and outputs are not visible on the screen at the same time.
We can debate the frequency of bias scaling. On the ER-301 I find myself scaling bias of pretty much everything. Attenuverters are underappreciated.
Not a fan of two-handed operations in eurorack (especially if I’m also playing an MPE controller!). But I can live with it if we think of bias scaling as a configuration (not performance) task (which sounds right).
I think you’re absolutely right, and I’d love to test the design in this way. I’m very comfortable with linux (going back many many years) but I’m going to need some basic info about the procedure to do what you describe here.
I can understand this rationale.
Yep, I’m piggybacking on this soft key to also toggle display of inputs/outputs on the right side of the screen. But given the discussion above, I’m no longer sure this is advisable.
That’s what my “soft keys” soft key does. If we can think of the soft key legend as an ephemeral/temporary part of the screen layout, we can give it a lot more space.
Not at all! Thank you very much for your feedback. Let’s come to some agreement about expected typical viewing distance, and if you can provide some details about how I might get an image onto the SSP itself, I will revisit the design with your comments in mind.
I really appreciate your willingness to discuss all of this. I fear this degree of interaction does not make me an “easy” customer to support. Please let me know right away if this conversation ceases to be helpful to you.