by John Bowen » Mon Mar 03, 2008 12:16 am
Hi,
I thought I'd give an update to my latest thinking here.
Concerning the 'current parameter' issue - there's actually 2 issues involved.
1) from the video interview, to be aware of which line is currently active for the knobs
2) Which parameter in that active line is currently active for data input from the numeric keypad, alpha knob, inc/dec.
The ideas of reverse video or blinking had to do with #2, but what I was probably talking about in the video was #1, which currently uses black pointers (like triangles on their sides) next to each parameter to indicate the current line.
From my use of the interface now for several months, and from the extra feedback with Zimmer's group, I've decided to reduce the number of parameters per display page, using soft labels for each parameter on the top line, and have the knobs primarily work with the bottom line. However, this does increase the number of 'sub-pages' needed to get through all the parameters quite a bit, so for all the modulation paths, we can still use the top line/bottom line functionality, by using push button knobs to select top or bottom line, with the black triangles pointing to the current active choice (as was discussed back in the beginning by me and the Sonic Core guys). The functions which are currently designed for the push knobs can be put in an additional sub-page, and in fact, opens up possibilities for more flexible modulation options.
I could also leave the text displays as they are, and use push knobs for every knob in the UI, but I think if I just rearrange parameters and make it simpler, there will be less 'push button activity' needed, which would be a good thing. One of the things that bothered me using the cursor controls to move from top to bottom was the constant lateral movement required when you were trying to adjust parameters top to bottom. This extra physical movement impairs the experience of ease-of-use, in my mind, and putting the line movement under the push of the knob allows for single control of things without this lateral movement.
Another issue of the UI solved by using soft labels for the parameters is that now anything that was not 'explained' by the silkscreened labels (such as Oscillator Type or Waveshape Select) can be clearly labeled. Also, for future use, soft labels can change as needed whenever new algorithms are implemented. (And another interesting point was, with the darker panel, not all the printed labels were easily readable, and I noticed Hans himself was looking for labels in the displays, although certainly this could be improved by using light or white print for all printed labels.)
I don't think they'll be able to have all the parameter lines re-coded in time for the Frankfurt Messe, but I hope some of them will be done (like the filter section), and I expect it will prove to be a lot more intuitive to use this way.
Of course, none of this addresses issue #2, which we've still got to decide. I hope to try the 'inverse video' option next, to see how it looks.
cheers,
john b.
cornutt wrote:In the Sonic State NAMM video, John mentioned the issue of the parameters on the two-line displays, and how to inform the user as to which line is being edited by the knobs at any given moment. The obvious idea is LEDs next to or in the selection buttons, but that adds hardware. I'm thinking something that uses the display itself. A couple of thoughts:
1. Reverse video to identify the active line. Kind of an old-school idea. t works, and I've used it / seen it used a lot in the past. On the other hand, I kind of think reverse video is obnoxious.
2. Putting some kind of indication on the line that is active, like askterists between the parameters. Back in the day, Emacs used to do this, but it might be all that noticeable, and it takes up space in the display.
3. Put a box around the active line. I don't know if the display is large enough to accommodate it.
4. Swap the two lines, such that the active line is always the one closest to the knobs. I think that, as a user, after getting used to this it would seem quite intuitive. But at first it would be confusing, I'll admit.
5. Putting the active line in some kind of different font, like an italic font. Neat idea in theory, but it might not work well with the display resolution.
I think my preference would be #3, followed by #1 and then #4.
Hi,
I thought I'd give an update to my latest thinking here.
Concerning the 'current parameter' issue - there's actually 2 issues involved.
1) from the video interview, to be aware of which line is currently active for the knobs
2) Which parameter in that active line is currently active for data input from the numeric keypad, alpha knob, inc/dec.
The ideas of reverse video or blinking had to do with #2, but what I was probably talking about in the video was #1, which currently uses black pointers (like triangles on their sides) next to each parameter to indicate the current line.
From my use of the interface now for several months, and from the extra feedback with Zimmer's group, I've decided to reduce the number of parameters per display page, using soft labels for each parameter on the top line, and have the knobs primarily work with the bottom line. However, this does increase the number of 'sub-pages' needed to get through all the parameters quite a bit, so for all the modulation paths, we can still use the top line/bottom line functionality, by using push button knobs to select top or bottom line, with the black triangles pointing to the current active choice (as was discussed back in the beginning by me and the Sonic Core guys). The functions which are currently designed for the push knobs can be put in an additional sub-page, and in fact, opens up possibilities for more flexible modulation options.
I could also leave the text displays as they are, and use push knobs for every knob in the UI, but I think if I just rearrange parameters and make it simpler, there will be less 'push button activity' needed, which would be a good thing. One of the things that bothered me using the cursor controls to move from top to bottom was the constant lateral movement required when you were trying to adjust parameters top to bottom. This extra physical movement impairs the experience of ease-of-use, in my mind, and putting the line movement under the push of the knob allows for single control of things without this lateral movement.
Another issue of the UI solved by using soft labels for the parameters is that now anything that was not 'explained' by the silkscreened labels (such as Oscillator Type or Waveshape Select) can be clearly labeled. Also, for future use, soft labels can change as needed whenever new algorithms are implemented. (And another interesting point was, with the darker panel, not all the printed labels were easily readable, and I noticed Hans himself was looking for labels in the displays, although certainly this could be improved by using light or white print for all printed labels.)
I don't think they'll be able to have all the parameter lines re-coded in time for the Frankfurt Messe, but I hope some of them will be done (like the filter section), and I expect it will prove to be a lot more intuitive to use this way.
Of course, none of this addresses issue #2, which we've still got to decide. I hope to try the 'inverse video' option next, to see how it looks.
cheers,
john b.
[quote="cornutt"]In the Sonic State NAMM video, John mentioned the issue of the parameters on the two-line displays, and how to inform the user as to which line is being edited by the knobs at any given moment. The obvious idea is LEDs next to or in the selection buttons, but that adds hardware. I'm thinking something that uses the display itself. A couple of thoughts:
1. Reverse video to identify the active line. Kind of an old-school idea. t works, and I've used it / seen it used a lot in the past. On the other hand, I kind of think reverse video is obnoxious.
2. Putting some kind of indication on the line that is active, like askterists between the parameters. Back in the day, Emacs used to do this, but it might be all that noticeable, and it takes up space in the display.
3. Put a box around the active line. I don't know if the display is large enough to accommodate it.
4. Swap the two lines, such that the active line is always the one closest to the knobs. I think that, as a user, after getting used to this it would seem quite intuitive. But at first it would be confusing, I'll admit.
5. Putting the active line in some kind of different font, like an italic font. Neat idea in theory, but it might not work well with the display resolution.
I think my preference would be #3, followed by #1 and then #4.[/quote]