---------- Forwarded message ----------
Message-Id: <[EMAIL PROTECTED]>
To: Abby <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Quasimodo art (long)
Date: Mon, 08 Mar 1999 00:08:42 -0500
From: Paul Barton-Davis <[EMAIL PROTECTED]>
Thanks for your comments. I'll try to respond to each of them one by
one, since they are issues that I am also concerned about (and have
thought about quite a bit).
>> 1) images of a small convex philips screw head, lit from the upper left
>.
>
>Looking at the Pulsar design, I can't see what good these do. Is there
>really a good reason to add visual clutter that conveys _no_
>information? It makes it look "more like a rack". How does that help?
>It's a subtle effect, but I think the screws make it just a bit harder
>to "read" the PULSAR display. Please-- leave the screws out!
In Quasimodo, the screws are actually buttons. Clockwise, from the top
left, they:
- pop up an editable window of the Csound definition of
the instrument.
- (currently) pop up the parser's-eye-view of the instrument
for debugging
(future) toggle display of all patch cords connected to
this instrument.
- remove the instrument (and its panel) from the rack.
- toggle on a voice/off all voices for the instrument
>> 2) a nice knob design, with 12 or more images to represent the knob as
>it turns.
>
>How much time have you spent using applications with virtual knobs? I've
>tried a couple -- Mix2000 (a soundcard mixer) and SLab (a virtual
>recording/mixing system) -- and I'm pretty much convinced that knobs
>don't work as well on-screen as they do in the physical world. Human
>hands find it easy to grasp a knob and twist it. Mouse pointers are
>rather more awkward, requiring a very fine control of the mouse in a
>circular direction, while eliminating the tactile feedback of the knob
>turning in your hand.
I agree very much with this. I spent a long time while writing
SoftWerk (http://www.op.net/~pbd/softwerk/) debating whether to do
knobs or buttons, and I thought about it even more during the design
of xphat (http://www.op.net/~pbd/xphat/). Overall, the keyboard is a
much more flexible, rapid and adaptable interface than the
mouse. Moreover, when you use a mouse, you don't really want to have
to move it if at all possible. I prefer buttons wherever possible, and
buttons with keyboard access too.
>And what's the benefit of the virtual knob?
Mostly just to make people say "coooooo-ul". But when you combine it
in the following way:
- make the knob be controllable from a keyboard key, with
direction reversal initiated from either another key or
a modifier key (e.g. ctrl, alt, caps)
- connect the knob to a numeric display that shows its current
value. The cyan-on-washed-blue-green in the Pulsar makes for
an extremely readable meter.
- operate with the mouse as in Rebirth, so that any vertical
mouse while the button is down works, thus not requiring
the user to do angular rotation
then i think it becomes a pretty strong UI component.
>But imagine translating that mixing desk onto a computer display. The
>display is much smaller, but it can also change itself very quickly, so
>it can effectively display _much_more_ information -- just not all at
>once. This eliminates any advantage of knobs over faders.
except that faders consume a lot more screen real estate, and they are
also expected to have interesting touch-feedback-response
curves. knobs don't come with this expectation.
>One problem with scrollbars in most applications is that they're all the
>same color. Large mixing desks color-code the knobs for good reason.
>Whether you use scrollbars or knobs, this is worth considering. The
>ultra-coolest would be if the user could specify the colors for their
>modules or instruments or whatever you're calling them. So every time I
>look at my favorite parametric EQ module, I'd know that the red control
>was Gain, the yellow control was Freq, and the purple control was Q. Or
>whatever! If coloring the actual controls is difficult to code (I've
>never done any GUI coding), at least see if the text labels of the
>controls can be color-coded. Anything that reduces the amount of time a
>user spends looking for one particular control is good.
Every single label, panel, piece of text, knob, socket etc. is
individually customizable by the user without any recompilation of
Quasimodo itself. You can specify the colors, font and images used for
every element of the UI (with the one restriction that various images
are intended be a fixed size). If you prefer to have yellow labels on
a black panel, no problem. If you want the audio sockets to be a
different color, also no problem (though you'll need to cook the
current image to be the color you want first, i suspect, but we'll
see.
The instrument designer gets to specify the layout of the instrument
panel, and in fact, I use Quasimodo as a GUI designer, since you can
reload the instrument after tweaking the layout specs, and check how
it looks, over and over again ! If you don't like the way a particular
module (say, the VCO) appears, just lay it out yourself, by editing
the file (either from a text editor, or ultimately from within
Quasimodo itself).
>As an example of what I think is bad design, SLab attempts to display an
>entire mixing desk at once, and as a result is both difficult to "read"
SLab is a disaster of UI to me. I've tried it on more than one
occasion, and I can get nowhere with it. I can't believe how bad it is.
[ ... sockets, etc ... ]
>This brings up the issue of the architecture of the whole GUI. Is the
>"rack" paradigm really the best way to represent modules onscreen?
>Remember that we have no need to worry about the practicalities of
>_physical_ design.
Agreed. But we also have several years of experience with people using
physical racks, and we've learnt quite a bit about how that works out.
Its wise not to throw this away. The best way to someone to do
interesting things with Quasimodo is to make it obvious how to think
about it, and right now, I think that the rack model is the best way.
If I or you or someone else comes up with a better model, we
can use that.
>The goal should always be for the user to be able to:
>1) Easily see what they are controlling at the moment, and
>2) See how that connects to other things.
Actually, I'd say that goal (0) is: make sure the user can easily
control one or more of the individual aspects of any instrument. After
that, I agree with (1) and (2) completely.
>I'm not sure how this can best be done. I can imagine a Quasimodo
>interface consisting of two windows: let's call them "overview" and
>"module". The "overview" window could show a flowchart representation of
>all the interconnections between modules, somewhat like Patchwork (which
>I must admit I haven't used much... couldn't get Xpatchwork to work, and
>I haven't tried Patchwork under WINE yet).
Nope. This is why the Pulsar model is so good. You have to *think*
about the flowchart representation, and often, you have to think
*hard*. The patch cord model, with clearly labelled ends on visually
distinguished modules, is much easier to read *when you want to read
it*. Remember that Quasimodo doesn't come with a bunch of predefined
modules like Patchwork (whose modules are Csound opcodes, in
essence). It comes with any modules/instruments anyone can write for
it, and distinguishing each module/instrument like that in a flowchart
display ends up with something that will be so close to the Pulsar-like
vision that its not worth doing separately, IMHO.
The "Module" window shows the
>interface for whatever module is currently selected in the "overview"
>window. A problem: One module window would probably be insufficient; one
>might want to look at several modules simultaneously. What if it were
>possible to switch between the PULSAR-style all-at-once view and the
>overview/module model I've suggested? That would be more work to code,
>but it might be well worth it.
My current model for how this will work is:
- each instrument is represented by a single "panel" in the GUI rack.
At some point, there will be support for multiple rack windows, right
now, there is just one, divided into N cabinets, each holding M
rack units (as in 1U, 3U, 4U rack size designations). You specify
how many cabinets and how big a 1U rack unit is in a config file
that Quasimodo reads when it starts up.
- the default set view of things will show patch cables as they are
"used", but this will be in an overlay window ...
- a button on the top of the rack window will remove the overlay,
leaving on the rack panels. Another button clears all the cables
from the overlay, but leaves it in place (invisible, more or
less).
- as mentioned above, each module/instrument has a button (a screw!)
that toggles the display of all patch cables connected to it in
the overlay window.
So, you can choose at any time to view no patch cords, just a few of
them, just one (set) of them, or all of them. How does this sound ?
There's no "Module" window, because we can fit all the detail we need
about an instrument in its panel (and anything else we can popup when
asked for it).
>> 7) a nice fat push button
>
>See if you can make it obvious at a glance whether the button's on or
>off! This is always annoying with analog mixing desks. You get used to
>it... but why should you have to?
>
>> 8) a multiposition switch
>
>Same as #7... make it easy to read.
Will try hard on both of these.
>Sorry if I'm coming off overly pedantic or something, but this project
>has the potential to be far more than your average software toy. I'd
>hate to see Quasimodo settling for the tried-and-tepid design paradigms
>when I believe it could be so much better!
>
>Thanks for listening to my rant. I don't ask that you do what I say,
>just that you think about it.
Don't apologize. Your thoughts are very on target, and I'd be very
interested in your responses to what I've written above.
--p
