Re: Knob styles (was: AU host properties)
Re: Knob styles (was: AU host properties)
- Subject: Re: Knob styles (was: AU host properties)
- From: James Chandler Jr <email@hidden>
- Date: Sat, 10 May 2003 13:16:05 -0400
I don't have a problem with the look of rotary knobs, because they are
certainly space efficient, but I find myself always using a slider
movement
when adjusting them. For those not familiar, Logic Audio allows you
to click
in the center of a knob and drag up and down (probably also left to
right, but
I don't use that) instead of requiring circular mouse movements.
I don't know if my habits represent a large group, but it seems
significant to
me that my hands don't want to spend a lot of time coaxing the mouse
into
simulating rotation without the tactile feedback of a real knob.
Hi Brian
Thanks for the good ideas.
Perhaps a "knob to make everybody happy" would offer five global user
options?
1. Vertical-only
2. Horizontal-only
3. Both Vert and Horz
4. Relative Rotary control
5. Absolute Rotary control (Thumb follows mouse pointer)
When started on PC 6 years ago, it was easy to implement favorite
Mac-sequencer-style vertical-only knobs and vertical-drag-edit
textboxes. Easier than writing Mac CDEFs. But the PC products tended
toward consumer-oriented. We received numerous complaints about the
"weird and difficult to operate" knobs and textboxes.
The home-musician, at least on the PC side, seemed to prefer
Absolute-Rotary-Control knobs and non-draggable textboxes with ugly
spin buttons. Perhaps "intuitive" is preferable to "fast" for the
occasional user? On prosumer Mac music software, dunno if the same
customer preferences would apply.
It is very good to provide exact values in a text field. What would
be nice,
I think, is if someone developed some reusable objects which paired a
knob or
slider with a text box as a single unit. Then we developers could
plop them in
as a unit and hook them up once without having to write the code to
set both
UI elements every time a value change is made. In Cocoa, it's fairly
easy to
do this and even avoid cyclic messages, but I guess AudioUnits will
have to
wait a bit longer for Cocoa controls.
On PC with Borland Dephi or C++ Builder, it is trivially trivial
(GRIN). You can make "Panels" which are canned composite controls. Just
click-drag a Knob, Textbox, Title, and Border object into a Panel file,
and write a few lines of code to glue them together. Then use the
hour-of-effort "TextKnob Panel" in any project, just like any IDE
built-in component.
Maybe it is just as easy in Cocoa, dunno. Am ignorant of Cocoa--
struggling desperately learning to Carbonize Band-in-a-Box. It would
take too many years to Cocoize it (GRIN).
For Classic Mac programs, wrote a lot of CDEFs. Seemed more efficient
to implement custom behavior in CDEFs, so you could benefit from very
simple standard control handling in the application.
In Carbon, custom controls must reside in project source code, which
has advantages and disadvantages. Maybe Carbon custom controls are too
much a PITA in practice, dunno yet. A composite Knob-and-Textbox custom
control shouldn't have cyclic message problems, since all the elements
would just look like a single slider control to the OS?
All the requisite building blocks are in my old CDEF source code,
depending on how difficult Carbonization turns out. After getting far
enough along in application carbonization, will check the feasibility
of carbonizing some of the more useful CDEFs. If I make a Carbon
composite Knob-and-Textbox custom control, will share the code in case
it is useful...
James Chandler Jr.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.