[linux-audio-dev] Knobs, the reply

Oh well, just read through the more than 30 mails ... Thanks to Arnold, Marek, Tim Hockin, Benno, Uwe, Tim Orford for the nice words. Thanks to everyone for the interest. About a standard toolkit: The general desktop toolkits do not adress some special needs of audio apps, that's clear. While an integrated look/feel with other, non-audio apps, would be nice, it can hardly be achieved (think alone of theming). Therefor a somewhat alien look could be of advantage (better clearly different than somewhat alike). Unification advantages: write once, get used to once, allowing usage to become somewhat subconcious (switching between different looks/feels doesn't allow that). It would be great to have all scalable vector guis (especialy interesting options for modular systems, overview vs tuning). Even without scaling, I think I would prefer to deliver plain SVG. Beside implementations in the major toolkits there's also Y at the horizone, with a base collection of widgets that is planned to be extendable with modules. About generating plugin guis from parameter descriptions: don't forget that layout is important. There would have to be some hints for that at least. I'm working on something very general regarding user interfaces, and widgets will be one topic. This should give me a nice foundation for an audio toolkit design from the look and feel side. So how about building a standard for exactly that: look and feel? Who's with me? About the implementation: wouldn't it be possible to wrap things up in enough ways to every capable developers likes? For people like me it would be more interesting to have gui editors / high level descriptions for concentrating on design. (hand writing xml or similar is acceptible for me, fiddling around with c code rather not) To Rtaylor: I'm all for breaking away from analog limitations. But I still think that a little 3d look helps with making clear what is manipulatable and what is not. And I hope it's possible to make both purists and eye-candy freaks happy enough (I'm myself more on the purist side, being german industrial design student, think Bauhaus and all :) And would you say what I presented is not clear/easy to read/decipher? About advanced knob functionality: For resetting knob with center (pan) I would rather replace the simple line mark with an arrow, that can be clicked for reset. Mousewhell should work, of course! Backwards decrease, forwards increase, to match with scrollbars/sliders. When Ctrl is used for finer adjustment, Shift or Alt could boost. Plus/minus buttons could also work. Right-click must be preserved for context menus (knobs could of course have such). For numerical input making use of a text field close to the knob might be better (but in any case only when numerical exactness makes sense). Tim Hockin: please elaborate about velocity sensitve knobs like used by OhmForce. A special fine adjustment accessible by a non-left click or with modifier key is a little problematic, because it breaks the connection between scale/indicator and mouse movement (not that I'm against it, only wanted to point this out). Clicks/modifier keys should not be user options. No need for extra coding, overloaded preferences / layout problems and users fiddling around instead of using the software. Radial? For those who think radial is bad: in that case knobs shouldn't be used at all! (Tim Hockin: it makes no sense to disagree to a half sentence/meaning!) Popping up a slider doesn't help much, the nature of the control should be clear right away. However, I never had problems dealing with radial knobs, but always found linear ones do not feel right. There's no need to move the pointer accurately in circular fashion, a soft bow works perfectly fine. I do not say knobs are perfect / better than sliders or other solutions in all cases, and I'm aware of the problems. Oh, and about linear needing 2 directions, up/down for gain and right left for pan (Uwe): Sure. And the widget has to be clear about that in advance. About releasing the knobs Everybody can have the existing svg, png export or Blender 3d files (just ask). I doubt I will continue with Blender, so future work will be vector or directly bitmap. Like I said, it's not finalized at all. ATM I do not know how to best generate series of bitmaps for rotations. Would be nice if someone could help with a little imagemagick or gimp scripting to do the rotation and combine it with fixed parts. Benno: I think Dave Robillard is right. Only when you're very sure the saved space can be put to better use, knobs ar an option there. And the design would have to be adapted to fit in. --- Thorsten Wilms