7 Sep
2010
7 Sep
'10
8:20 p.m.
This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
Gordon MM0YEQ
7 Sep
7 Sep
8:23 p.m.
On Tue, 7 Sep 2010, Gordon JC Pearce wrote:
This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
My opinion...
circle: no.
up and down: yes.
scroll wheel: yes.
left and right: up to you.
-gabriel
8:25 p.m.
On Tue, Sep 7, 2010 at 6:23 PM, Gabriel M. Beddingfield
<gabrbedd(a)gmail.com> wrote:
On Tue, 7 Sep 2010, Gordon JC Pearce wrote:
i like distance scaling - the further the mouse is from the center of
the knob, the coarser the changes in response to whatever motion
drives changes.
This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
My opinion...
circle: no.
up and down: yes.
scroll wheel: yes.
left and right: up to you. 
9:11 p.m.
Hello everyone,
On 09/07/2010 08:25 PM, Paul Davis wrote:
On Tue, Sep 7, 2010 at 6:23 PM, Gabriel M.
Beddingfield
<gabrbedd(a)gmail.com> wrote:
I like it too, but there always are unwanted changes while you go away from the
center. I think that a good workaround could be up and down with fine-tuning
(eg: Ctrl + move up/down).
--
Olivier
On Tue, 7 Sep 2010, Gordon JC Pearce wrote:
i like distance scaling - the further the mouse is from the center of
the knob, the coarser the changes in response to whatever motion
drives changes. This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
My opinion...
circle: no.
up and down: yes.
scroll wheel: yes.
left and right: up to you.
9:24 p.m.
On Tue, Sep 7, 2010 at 7:11 PM, Olivier Guilyardi <list(a)samalyse.com> wrote:
well, yeah, that was a given.
Hello everyone,
On 09/07/2010 08:25 PM, Paul Davis wrote:
i like
distance scaling - the further the mouse is from the center of
the knob, the coarser the changes in response to whatever motion
drives changes.
I like it too, but there always are unwanted changes while you go away from the
center. I think that a good workaround could be up and down with fine-tuning
(eg: Ctrl + move up/down). 
8 Sep
8 Sep
9:21 a.m.
Am Dienstag, den 07.09.2010, 18:25 +0000 schrieb Paul Davis:
On Tue, Sep 7, 2010 at 6:23 PM, Gabriel M.
Beddingfield
<gabrbedd(a)gmail.com> wrote:
that's also happens in circular movements automatic. :-)
On Tue, 7 Sep 2010, Gordon JC Pearce wrote:
i like distance scaling - the further the mouse is from the center of
the knob, the coarser the changes in response to whatever motion
drives changes. This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
My opinion...
circle: no.
up and down: yes.
scroll wheel: yes.
left and right: up to you.
7 Sep
7 Sep
8:29 p.m.
Am Dienstag, den 07.09.2010, 13:23 -0500 schrieb Gabriel M.
Beddingfield:
On Tue, 7 Sep 2010, Gordon JC Pearce wrote:
I prefer this way
circle : default
up ad down: strg + mouse
left and right: no
important is also the mouse wheel ;-)
hermann
This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
My opinion...
circle: no.
up and down: yes.
scroll wheel: yes.
left and right: up to you.
-gabriel
8:37 p.m.
On Tue, 7 Sep 2010 13:34:50 -0500 (CDT)
"Gabriel M. Beddingfield" <gabrbedd(a)gmail.com> wrote:
On Tue, 7 Sep 2010, hermann wrote:
Very appropriate!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
up ad down: strg + mouse
strangle + mouse ??
8:34 p.m.
On Tue, 7 Sep 2010 13:23:17 -0500 (CDT)
"Gabriel M. Beddingfield" <gabrbedd(a)gmail.com> wrote:
On Tue, 7 Sep 2010, Gordon JC Pearce wrote:
Hate the things. Would much prefer a neat collection of sliders and/or
spin boxes.
In the real world you grab a knob with your fingers and have real
precise *tactile* control. This is nothing like a computer
representation, so why try to fake it?
A compact 2000 step spin box would be rather hard (and expensive) to
implement in the real world, and how would it deal with direct entry of
numbers? It works perfectly on a GUI.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
My opinion...
circle: no.
up and down: yes.
scroll wheel: yes.
left and right: up to you.
-gabriel
8:38 p.m.
On Tue, Sep 7, 2010 at 6:34 PM, Folderol <folderol(a)ukfsn.org> wrote:
In the real world you grab a knob with your fingers and have real
precise *tactile* control. This is nothing like a computer
representation, so why try to fake it?
because it provides a compact, visually-accessible representation of a
numeric value.
9:43 p.m.
On Tue, 2010-09-07 at 19:34 +0100, Folderol wrote:
On Tue, 7 Sep 2010 13:23:17 -0500 (CDT)
"Gabriel M. Beddingfield" <gabrbedd(a)gmail.com> wrote:
Never going to happen. Numbers are the worst possible way to represent
an "analogue" value.
I don't care if Fc is 1752.7Hz - I care if it's "about quarter up".
On Tue, 7 Sep 2010, Gordon JC Pearce wrote:
Hate the things. Would much prefer a neat collection of sliders and/or
spin boxes. This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
My opinion...
circle: no.
up and down: yes.
scroll wheel: yes.
left and right: up to you.
-gabriel In the real world you grab a knob with your fingers
and have real
precise *tactile* control. This is nothing like a computer
representation, so why try to fake it?
Instant visual recognition of configured values.
A compact 2000 step spin box would be rather hard (and
expensive) to
implement in the real world, and how would it deal with direct entry of
numbers? It works perfectly on a GUI.
I can show you a compact 2000-step spin box -
http://www.rigpix.com/icom/ic2e.htm
Okay, so the least-significant digit is only ever 0 or 5, and not all of
the ten possibilities for the most-significant digit are valid. Have
you never seen those thumbwheel switches before? They crop up on old
external SCSI drives. I have one of those radios sitting on my bench
right in front of me ;-)
Gordon MM0YEQ
9:44 p.m.
On 09/07/2010 08:34 PM, Folderol wrote:
On Tue, 7 Sep 2010 13:23:17 -0500 (CDT)
"Gabriel M. Beddingfield" <gabrbedd(a)gmail.com> wrote:
I have been working on an experimental slider in Jackbeat. When untouched it is
very small, but big enough to see what the level is. When you click and hold on
it, it unfolds (becomes much bigger), and the mouse changes the level with
increased precision.
It may need some refinement, but some of you may like it. Unfortunately, it
isn't a real Gtk widget class, but it should be reusable in some ways:
http://jackbeat.samalyse.org/browser/trunk/src/gui/slider.c?rev=636
--
Olivier
circle: no.
up and down: yes.
scroll wheel: yes.
left and right: up to you.
Hate the things. Would much prefer a neat collection of sliders and/or
spin boxes.
9:58 p.m.
On Tue, 2010-09-07 at 21:44 +0200, Olivier Guilyardi wrote:
I have been working on an experimental slider in
Jackbeat. When untouched it is
very small, but big enough to see what the level is. When you click and hold on
it, it unfolds (becomes much bigger), and the mouse changes the level with
increased precision.
That sounds a bit like the the fansliders in phat...
Gordon MM0YEQ
10:15 p.m.
On 09/07/2010 09:58 PM, Gordon JC Pearce wrote:
On Tue, 2010-09-07 at 21:44 +0200, Olivier Guilyardi
wrote:
Actually, I used the fansliders before, in the very same place :) But there were
two things that I didn't like:
- the way they look, especially when unfolded, those ugly/huge shapes around
- the fact that unwanted changes happen when you go away to gain precision
That's why I made those sliders IIRC. You have increased precision right after
clicking, you don't need to move away for that. Plus, with the way they are
integrated and some mouse magic, it doesn't matter if the window is closed to a
screen border or not. And I think they look neat ;)
That said, the increased precision is fixed. You can't go into the pico dB.. But
it works for me.
--
Olivier
I have been working on an experimental slider in
Jackbeat. When untouched it is
very small, but big enough to see what the level is. When you click and hold on
it, it unfolds (becomes much bigger), and the mouse changes the level with
increased precision.
That sounds a bit like the the fansliders in phat... 
10 Sep
10 Sep
2:37 a.m.
On Wed, Sep 8, 2010 at 6:15 AM, Olivier Guilyardi <list(a)samalyse.com> wrote:
On 09/07/2010 09:58 PM, Gordon JC Pearce wrote:
Fansliders are lovely ideas, but the current implementation is pretty
crappy, and I haven't look at the code in years and didn't have a
clear idea about what I was doing with it last time anyway. Now that x
composite is a lot more common it would be easier. I'm surprised
Thorsten hasn't jumped in to the knob discussion yet. If anyone else
wants to fix fan sliders feel free to give me a yell.
I still think knobs are pretty evil though. :)
Loki
On Tue, 2010-09-07 at 21:44 +0200, Olivier
Guilyardi wrote:
Actually, I used the fansliders before, in the very same place :) But there were
two things that I didn't like:
- the way they look, especially when unfolded, those ugly/huge shapes around
- the fact that unwanted changes happen when you go away to gain precision
That's why I made those sliders IIRC. You have increased precision right after
clicking, you don't need to move away for that. Plus, with the way they are
integrated and some mouse magic, it doesn't matter if the window is closed to a
screen border or not. And I think they look neat ;)
That said, the increased precision is fixed. You can't go into the pico dB.. But
it works for me.
--
Olivier I have been working on an experimental slider in
Jackbeat. When untouched it is
very small, but big enough to see what the level is. When you click and hold on
it, it unfolds (becomes much bigger), and the mouse changes the level with
increased precision.
That sounds a bit like the the fansliders in phat...
2:33 p.m.
On 09/10/2010 02:37 AM, Loki Davison wrote:
Since I used fan sliders in my app, I've been thinking a lot about them, and I'm
not sure they're such a great idea, for the reasons outlined above. And I saw
some sound engineers getting really confused when first trying them. But this
might be because they were just surprised.
On Wed, Sep 8, 2010 at 6:15 AM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
Actually, I
used the fansliders before, in the very same place :) But there were
two things that I didn't like:
- the way they look, especially when unfolded, those ugly/huge shapes around
- the fact that unwanted changes happen when you go away to gain precision
That's why I made those sliders IIRC. You have increased precision right after
clicking, you don't need to move away for that. Plus, with the way they are
integrated and some mouse magic, it doesn't matter if the window is closed to a
screen border or not. And I think they look neat ;)
Fansliders are lovely ideas, but the current implementation is pretty
crappy, and I haven't look at the code in years and didn't have a
clear idea about what I was doing with it last time anyway. Now that x
composite is a lot more common it would be easier. I'm surprised
Thorsten hasn't jumped in to the knob discussion yet. If anyone else
wants to fix fan sliders feel free to give me a yell. I still think knobs are pretty evil though. :)
Well, as I previously said, I think that knobs can make sense in certain
situations. So I'd rather see the phat knob improved ;) I think that's a really
cool widget, it provides a very clear visual indication, but it only supports
the circle movements.
It would be great if there were runtime options to customize the phat knob
behavior, to also support up/down and/or left/right, fine-tuning with a key
modifier, etc..
Providing alternative styles would also be very cool.
--
Olivier
6:06 p.m.
Am Freitag, den 10.09.2010, 14:32 +0200 schrieb Olivier Guilyardi:
Well, as I previously said, I think that knobs can
make sense in
certain
situations. So I'd rather see the phat knob improved ;) I think that's
a really
cool widget, it provides a very clear visual indication, but it only
supports
the circle movements.
It would be great if there were runtime options to customize the phat
knob
behavior, to also support up/down and/or left/right, fine-tuning with
a key
modifier, etc..
Providing alternative styles would also be very cool.
All that we have done in the libgxw / ligxwmm library witch comes with
guitarix.
greats hermann
11 Sep
11 Sep
7:36 p.m.
On 09/10/2010 06:06 PM, hermann wrote:
Am Freitag, den 10.09.2010, 14:32 +0200 schrieb
Olivier Guilyardi:
That's great work indeed. I have just tried pygxw with the provided demo.
That said, I think that the behavior should be more customizable. From what I
saw, the default behavior is circle-move, and with Ctrl it becomes up/down. I
also saw that this behavior can be inverted with gx_set_knob_jump_to_mouse().
There isn't really fine-tuning AFAICS. I mean, to be consistent, one may want to
have up/down by default, and fine-tuning up/down with Ctrl (no circles).
IMO, this widget, although very cool, is similar to the phat knob. It works well
for the specific purpose it was designed. But it lacks several options, in order
to satisfy the various tastes mentioned on this thread.
Also, the phat knob, with its large orange/blue border provides better
visualization IMO. I am however quite sad that in both cases, phat and libgxw,
no SVG source is provided.
--
Olivier
Well, as I previously said, I think that knobs
can make sense in
certain
situations. So I'd rather see the phat knob improved ;) I think that's
a really
cool widget, it provides a very clear visual indication, but it only
supports
the circle movements.
It would be great if there were runtime options to customize the phat
knob
behavior, to also support up/down and/or left/right, fine-tuning with
a key
modifier, etc..
Providing alternative styles would also be very cool.
All that we have done in the libgxw / ligxwmm library witch comes with
guitarix.
8:23 p.m.
Am Samstag, den 11.09.2010, 19:36 +0200 schrieb Olivier Guilyardi:
On 09/10/2010 06:06 PM, hermann wrote:
You comes into the fine-tune mode after you have leave ctrl and hold the
mouse-button pressed. A right click on a Controller pops up a spinbox to
set a Value direct.
Also you can use your own images (with rcstyle files) with your own size
for the knob's, two different sizes for the knobs are possible. You can
change the Image during runtime.
Main author of libgxw is Andreas Degert, it's in Alpha stage, and open
for suggestions.
But indeed we see the need for a GTK Audio Widget library because we
need it for our project, so we start to create on.
hermann
Am Freitag, den 10.09.2010, 14:32 +0200 schrieb
Olivier Guilyardi:
That's great work indeed. I have just tried pygxw with the provided demo.
That said, I think that the behavior should be more customizable. From what I
saw, the default behavior is circle-move, and with Ctrl it becomes up/down. I
also saw that this behavior can be inverted with gx_set_knob_jump_to_mouse().
There isn't really fine-tuning AFAICS. I mean, to be consistent, one may want to
have up/down by default, and fine-tuning up/down with Ctrl (no circles).
IMO, this widget, although very cool, is similar to the phat knob. It works well
for the specific purpose it was designed. But it lacks several options, in order
to satisfy the various tastes mentioned on this thread.
Also, the phat knob, with its large orange/blue border provides better
visualization IMO. I am however quite sad that in both cases, phat and libgxw,
no SVG source is provided.
--
Olivier
Well, as I previously said, I think that knobs
can make sense in
certain
situations. So I'd rather see the phat knob improved ;) I think that's
a really
cool widget, it provides a very clear visual indication, but it only
supports
the circle movements.
It would be great if there were runtime options to customize the phat
knob
behavior, to also support up/down and/or left/right, fine-tuning with
a key
modifier, etc..
Providing alternative styles would also be very cool.
All that we have done in the libgxw / ligxwmm library witch comes with
guitarix.
12 Sep
12 Sep
12:28 p.m.
On 09/11/2010 08:23 PM, hermann wrote:
You comes into the fine-tune mode after you have leave
ctrl and hold the
mouse-button pressed. A right click on a Controller pops up a spinbox to
set a Value direct.
Press ctrl, hold the mouse button, release ctrl but not the button... That's
quite a hidden feature. I do respect your choice, but that confirms what I said:
it's designed for a specific purpose, it needs some more options to become a
generic widget that can accommodate the various tastes mentioned on this thread.
Also you can use your own images (with rcstyle files)
with your own size
for the knob's, two different sizes for the knobs are possible. You can
change the Image during runtime.
Changing the background image isn't sufficient to rival with the phat knob
visual animation, which provide a rotary level meter, as found in many modern
software. Check out the underlying pixmap(s):
http://svn.berlios.de/wsvn/phat/trunk/phat/pixmaps/knob.png
Main author of libgxw is Andreas Degert, it's in
Alpha stage, and open
for suggestions.
But indeed we see the need for a GTK Audio Widget library because we
need it for our project, so we start to create on.
IMO you should get some inspiration from Phat..
http://phat.berlios.de/
--
Olivier
2:05 p.m.
Main author of
libgxw is Andreas Degert, it's in Alpha stage, and open
for suggestions.
But indeed we see the need for a GTK Audio Widget library because we
need it for our project, so we start to create on.
IMO you should get some inspiration from Phat..
http://phat.berlios.de/
13 Sep
13 Sep
3:53 p.m.
On 09/12/2010 02:05 PM, Loki Davison wrote:
Thorsten's design is as always fantastic. :)
Agreed, it's a a shame his new knob designs at
http://thorwil.wordpress.com/?s=knobs were never implemented. I think they're
very cool and somehow remind me of Live knobs.
I'd think about doing more on phat but ardour is
basically the only
application i'm using now. If anyone wants to contribute patches or
anything i'll be happy to merge/release etc.
If Thorsten is ok, I think you should commit the Blender sources just mentioned.
Having only the knob pixmaps is everything but flexible.
That said I have started to work on a PhatWheel widget, inspired by this thread
and Thorsten's designs.
I don't have much time, but chances are that I'll make it work and add several
options for both rendering and behavior customization.
--
Olivier
4:55 p.m.
On Mon, Sep 13, 2010 at 9:53 AM, Olivier Guilyardi <list(a)samalyse.com> wrote:
On 09/12/2010 02:05 PM, Loki Davison wrote:
except ... they were ...
hans baier took the idea and implemented it in cairo as part of his
prolooks library, and i took what hans had done and incorporated it
into ardour3 in the new monitor section.
Thorsten's design is as always fantastic. :)
Agreed, it's a a shame his new knob designs at
http://thorwil.wordpress.com/?s=knobs were never implemented. I think they're
very cool and somehow remind me of Live knobs.
4:38 p.m.
On 09/13/2010 04:25 PM, Paul Davis wrote:
On Mon, Sep 13, 2010 at 9:53 AM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
Okay, I was playing with Vala and Cairo, and the result was rather faithful to
the design. Where's this prolooks library? I can't find anything about it.
I'll
have a look at the new monitor of ardour3. I suppose there might still be a bit
of work to make it a fully reusable and customizable widget.
--
Olivier
On 09/12/2010 02:05 PM, Loki Davison wrote:
except ... they were ...
hans baier took the idea and implemented it in cairo as part of his
prolooks library, and i took what hans had done and incorporated it
into ardour3 in the new monitor section. Thorsten's design is as always fantastic. :)
Agreed, it's a a shame his new knob designs at
http://thorwil.wordpress.com/?s=knobs were never implemented. I think they're
very cool and somehow remind me of Live knobs.
4:45 p.m.
On Mon, Sep 13, 2010 at 10:38 AM, Olivier Guilyardi <list(a)samalyse.com> wrote:
On 09/13/2010 04:25 PM, Paul Davis wrote:
the implementation is in libs/gtkmm2ext/motion_feedback.cc
this has existed for years, but i reimplemented the expose/draw method.
On Mon, Sep 13, 2010 at 9:53 AM, Olivier
Guilyardi <list(a)samalyse.com> wrote:
Okay, I was playing with Vala and Cairo, and the result was rather faithful to
the design. Where's this prolooks library? I can't find anything about it.
I'll
have a look at the new monitor of ardour3. I suppose there might still be a bit
of work to make it a fully reusable and customizable widget. On 09/12/2010 02:05 PM, Loki Davison wrote:
except ... they were ...
hans baier took the idea and implemented it in cairo as part of his
prolooks library, and i took what hans had done and incorporated it
into ardour3 in the new monitor section. Thorsten's design is as always fantastic. :)
Agreed, it's a a shame his new knob designs at
http://thorwil.wordpress.com/?s=knobs were never implemented. I think they're
very cool and somehow remind me of Live knobs.
10:14 p.m.
On 09/13/2010 04:43 PM, Paul Davis wrote:
On Mon, Sep 13, 2010 at 10:38 AM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
I haven't yet run it, but I see hard-coded colors for gradients. This isn't what
the design tries to achieve IIUC, nor my idea. I'm talking about a GTK compliant
widget, which uses the base colors by default and thus support theming.
(actually, I would quite like to make it customizable, and support gradient as
well, trough gtk rc styles).
For the default rendering of the blue part, using
GtkStyle.bg[GDK_STATE_SELECTED] seems to make sense since it renders to a color
(blue, brown, etc..) in many modern themes. However, in some other themes, it's
just another shade of gray.
Thorsten, did you think about this?
--
Olivier
On 09/13/2010 04:25 PM, Paul Davis wrote:
the implementation is in libs/gtkmm2ext/motion_feedback.cc
this has existed for years, but i reimplemented the expose/draw method. On Mon, Sep 13, 2010 at 9:53 AM, Olivier
Guilyardi <list(a)samalyse.com> wrote:
Okay, I was playing with Vala and Cairo,
and the result was rather faithful to
the design. Where's this prolooks library? I can't find anything about it.
I'll
have a look at the new monitor of ardour3. I suppose there might still be a bit
of work to make it a fully reusable and customizable widget. On 09/12/2010 02:05 PM, Loki Davison wrote:
> Thorsten's design is as always fantastic. :)
Agreed, it's a a shame his new knob designs at
http://thorwil.wordpress.com/?s=knobs were never implemented. I think they're
very cool and somehow remind me of Live knobs.
except ... they were ...
hans baier took the idea and implemented it in cairo as part of his
prolooks library, and i took what hans had done and incorporated it
into ardour3 in the new monitor section. 
14 Sep
14 Sep
9:14 a.m.
On Mon, 2010-09-13 at 22:14 +0200, Olivier Guilyardi wrote:
For the default rendering of the blue part, using
GtkStyle.bg[GDK_STATE_SELECTED] seems to make sense since it renders to a color
(blue, brown, etc..) in many modern themes. However, in some other themes, it's
just another shade of gray.
Thorsten, did you think about this?
Sure. AFAIR fan-sliders use that approach.
I wonder if you can query for the color used for progress-bars.
Either ignore unfortunate themes, or try to evaluate the provided
colors, to use some fall-back if there isn't sufficient contrast.
An option for user-defined colors would have the problem that users have
to know about that and then have to bother defining it, if colors are
unpleasant, otherwise.
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
12:27 p.m.
On 09/14/2010 09:14 AM, Thorsten Wilms wrote:
On Mon, 2010-09-13 at 22:14 +0200, Olivier Guilyardi
wrote:
Of course you can do that, but I think that by default (and usually in themes)
it's the same as the selected color, such as the one when you click/hover a menu
item.
For the default rendering of the blue part, using
GtkStyle.bg[GDK_STATE_SELECTED] seems to make sense since it renders to a color
(blue, brown, etc..) in many modern themes. However, in some other themes, it's
just another shade of gray.
Thorsten, did you think about this?
Sure. AFAIR fan-sliders use that approach.
I wonder if you can query for the color used for progress-bars. Either ignore unfortunate themes, or try to evaluate
the provided
colors, to use some fall-back if there isn't sufficient contrast.
Detecting contrast sounds like unreliable magic. I agree about ignoring
unfortunate themes. It needs a bit of testing, but even if there's just gray, I
think that the contrast should be sufficient in most cases.
An option for user-defined colors would have the
problem that users have
to know about that and then have to bother defining it, if colors are
unpleasant, otherwise.
To me, it's also the developer responsibility. With a customizable knob widget,
by default it would just use the base color palette. But a developer could
customize colors by providing his own styles, and even have different colors for
different knobs in the UI.
But, since most of the appearance could be controlled through GTK rc styles,
users as well as theme designers could add specific global rules for the knobs.
That would only work if the developer doesn't override them in his app of course.
Ideally, I think it could be useful to allow gradients (through some start/end
colors style rules), as well as wheel thickness and possibly a couple of other
details.
It'll take a bit of time, but I'll try and show you something that works when
it's ready.
--
Olivier
10:49 p.m.
On 09/13/2010 04:43 PM, Paul Davis wrote:
On Mon, Sep 13, 2010 at 10:38 AM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
I would quite like to have a look at your knob, but ardour3 r7775 segfaults
here, right after clicking on Apply in the New Session dialog. Attached: output
and backtrace.
Note: I changed the jack dependency to 0.118 in libs/midi++2/wscript and
libs/ardour/wscript, to build with Debian's libjack 1:0.118+svn3796-7.
--
Olivier
olivier@etoile:~/dev/ardour3$ gtk2_ardour/ardev
Ardour3.0pre0 (built using 7775 and GCC version 4.4.5 20100728 (prerelease))
Copyright (C) 1999-2010 Paul Davis
Some portions Copyright (C) Steve Harris, Ari Johnson, Brett Viren, Joel Baker
Ardour comes with ABSOLUTELY NO WARRANTY
not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This is free software, and you are welcome to redistribute it
under certain conditions; see the source for copying conditions.
ardour: [INFO]: Loading default ui configuration file
gtk2_ardour/../gtk2_ardour/ardour3_ui_default.conf
Loading ui configuration file gtk2_ardour/../build/default/gtk2_ardour/ardour3_ui_dark.rc
ardour: [INFO]: Ardour will be limited to 1024 open files
ardour: [INFO]: Loading user configuration file /home/olivier/.config/ardour3/ardour.rc
Using SSE optimized routines
Callback to ardour.org ...
Current release is 2.8.11
Unusual local version: 3.0pre0
Found 0 along :/home/olivier/.config/ardour3/templates
Grab new name focus
lost focus
lost focus
no more csLADSPA plugins
Segmentation fault
Program received signal SIGSEGV, Segmentation fault.
0xb607a145 in std::string::assign(std::string const&) () from /usr/lib/libstdc++.so.6
(gdb) bt
#0 0xb607a145 in std::string::assign(std::string const&) () from
/usr/lib/libstdc++.so.6
#1 0xb7f4ce09 in XMLNode::XMLNode(XMLNode const&) () from
gtk2_ardour/../build/default/libs/pbd/libpbd.so.4
#2 0xb7f4cfee in XMLNode::add_child_copy(XMLNode const&) () from
gtk2_ardour/../build/default/libs/pbd/libpbd.so.4
#3 0xb7f42f1c in PBD::Stateful::add_instant_xml(XMLNode&, PBD::sys::path const&)
() from gtk2_ardour/../build/default/libs/pbd/libpbd.so.4
#4 0xb7c2dfb6 in ARDOUR::Session::add_instant_xml(XMLNode&, bool) () from
gtk2_ardour/../build/default/libs/ardour/libardour.so.3
#5 0x081c1b8a in ARDOUR_UI::build_session(std::string const&, std::string const&,
ARDOUR::BusProfile&) ()
#6 0x081c1e8b in ARDOUR_UI::build_session_from_nsd(std::string const&, std::string
const&) ()
#7 0x081c22a6 in ARDOUR_UI::get_session_parameters(bool, bool, std::string) ()
#8 0x081c348a in ARDOUR_UI::startup() ()
#9 0x081cd7cc in sigc::internal::slot_call0<sigc::bound_mem_functor0<void,
ARDOUR_UI>, void>::call_it(sigc::internal::slot_rep*) ()
#10 0xb76c2e09 in Gtkmm2ext::UI::run(Receiver&) () from
gtk2_ardour/../build/default/libs/gtkmm2ext/libgtkmm2ext.so.0
#11 0x085176f7 in main ()
On 09/13/2010 04:25 PM, Paul Davis wrote:
the implementation is in libs/gtkmm2ext/motion_feedback.cc
this has existed for years, but i reimplemented the expose/draw method. On Mon, Sep 13, 2010 at 9:53 AM, Olivier
Guilyardi <list(a)samalyse.com> wrote:
Okay, I was playing with Vala and Cairo,
and the result was rather faithful to
the design. Where's this prolooks library? I can't find anything about it.
I'll
have a look at the new monitor of ardour3. I suppose there might still be a bit
of work to make it a fully reusable and customizable widget. On 09/12/2010 02:05 PM, Loki Davison wrote:
> Thorsten's design is as always fantastic. :)
Agreed, it's a a shame his new knob designs at
http://thorwil.wordpress.com/?s=knobs were never implemented. I think they're
very cool and somehow remind me of Live knobs.
except ... they were ...
hans baier took the idea and implemented it in cairo as part of his
prolooks library, and i took what hans had done and incorporated it
into ardour3 in the new monitor section.
15 Sep
15 Sep
12:03 a.m.
On Tue, Sep 14, 2010 at 4:49 PM, Olivier Guilyardi <list(a)samalyse.com> wrote:
I would quite like to have a look at your knob, but
ardour3 r7775 segfaults
here, right after clicking on Apply in the New Session dialog. Attached: output
and backtrace.
we are not ready to "support" ardour3 yet. if you'd like to compile
with --debug at the ./waf configure step, regenerate the backtrace and
file it in the bugtracker, someone will take a look at it. this is not
a known crash at this time. the backtrace as provided (without debug
info) is more or less useless, unfortunately.
9:39 a.m.
On 14.09.2010 22:49, Olivier Guilyardi wrote:
I would quite like to have a look at your knob, but ardour3 r7775 segfaults
here, right after clicking on Apply in the New Session dialog. Attached: output
and backtrace.
I wanted to try Ardour3 too and had the same problem. Ardour, at least
for me, created new session before segfaulting. So, if you run it again
and just open that session it should not crash.
Igor
12:32 p.m.
On 09/15/2010 09:38 AM, Igor Brkic wrote:
On 14.09.2010 22:49, Olivier Guilyardi wrote:
Thanks Igor, that did the trick. But I can't find the new monitor section that
you mention Paul. It should be in the mixer, right? Any pref?
--
Olivier
I would quite like to have a look at your knob, but ardour3 r7775
segfaults
here, right after clicking on Apply in the New Session dialog.
Attached: output
and backtrace.
I wanted to try Ardour3 too and had the same problem. Ardour, at least
for me, created new session before segfaulting. So, if you run it again
and just open that session it should not crash.
12:56 p.m.
On Wed, Sep 15, 2010 at 6:32 AM, Olivier Guilyardi <list(a)samalyse.com> wrote:
On 09/15/2010 09:38 AM, Igor Brkic wrote:
its an option selected in the initial first-time user dialog (remove
~/.config/ardour3 and start again) or in Preferences.
On 14.09.2010 22:49, Olivier Guilyardi wrote:
Thanks Igor, that did the trick. But I can't find the new monitor section that
you mention Paul. It should be in the mixer, right? Any pref?
I would quite like to have a look at your knob, but ardour3 r7775
segfaults
here, right after clicking on Apply in the New Session dialog.
Attached: output
and backtrace.
I wanted to try Ardour3 too and had the same problem. Ardour, at least
for me, created new session before segfaulting. So, if you run it again
and just open that session it should not crash.
4:53 p.m.
On Tue, Sep 14, 2010 at 4:49 PM, Olivier Guilyardi <list(a)samalyse.com> wrote:
I would quite like to have a look at your knob, but
ardour3 r7775 segfaults
here, right after clicking on Apply in the New Session dialog. Attached: output
and backtrace.
This issue has been fixed as of rev 7780
16 Sep
16 Sep
10:52 a.m.
On 09/15/2010 04:52 PM, Paul Davis wrote:
On Tue, Sep 14, 2010 at 4:49 PM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
Confirmed, it works here.
I have now enabled the monitor bus and I can see the widgets. Here is a
screenshot for those who are interested:
http://testing.samalyse.com/lad/widgets/ardour3_monitor.png
It's nice indeed, you have worked on some light effect I see. That said, it's a
little blurred. I've also had that kind of problem with my first Cairo experiments.
Here is my personal selection:
http://testing.samalyse.com/lad/widgets/wheel1.png
I quite like it when it's minimal, not too realistic. It reminds be a bit of the
memory/swap meters in the Gnome System Monitor:
http://testing.samalyse.com/lad/widgets/system_monitor.png
The +/- variant could be nice when the value increases by steps. Those +/-
buttons would be activated by mouse button release, so that it should still be
possible to click and move up/down or in circles.
For the centered label, there could be an option to place it under the knob as
in Juce or Live, if it needs more space. Ideally, when double-clicking the
label, you could edit it in-place, although I'm not quite sure how to achieve this.
What do you all think?
--
Olivier
I would quite like to have a look at your knob,
but ardour3 r7775 segfaults
here, right after clicking on Apply in the New Session dialog. Attached: output
and backtrace.
This issue has been fixed as of rev 7780 
5:01 p.m.
On Thu, Sep 16, 2010 at 4:52 AM, Olivier Guilyardi <list(a)samalyse.com> wrote:
I quite like it when it's minimal, not too
realistic. It reminds be a bit of the
memory/swap meters in the Gnome System Monitor:
http://testing.samalyse.com/lad/widgets/system_monitor.png
the one issue i have with that style is pretty stupid really: it
always takes me a 2nd thought to decide whether they indicate "the
glass is 1/3rd empty" or "the glass is 1/3rd full". With color like
that, its not so hard, but i have a camera that uses that kind of
display to show memory-fullness, and its stuck with a black/white
approach that makes it quite hard to decide what its showing you.
8:06 p.m.
On 09/16/2010 05:01 PM, Paul Davis wrote:
On Thu, Sep 16, 2010 at 4:52 AM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
I was mentioning these to show how a minimal knob can look in a GTK window. It's
not shaded, nor embossed, but it integrates quite well I think.
That helps me to imagine how the knobs could integrate. And I don't think they
would be affected by the problem that you mention, thanks to needle/hand.
--
Olivier
I quite like it when it's minimal, not too
realistic. It reminds be a bit of the
memory/swap meters in the Gnome System Monitor:
http://testing.samalyse.com/lad/widgets/system_monitor.png
the one issue i have with that style is pretty stupid really: it
always takes me a 2nd thought to decide whether they indicate "the
glass is 1/3rd empty" or "the glass is 1/3rd full". With color like
that, its not so hard, but i have a camera that uses that kind of
display to show memory-fullness, and its stuck with a black/white
approach that makes it quite hard to decide what its showing you.
14 Sep
14 Sep
5:07 a.m.
Am Sonntag, den 12.09.2010, 12:28 +0200 schrieb Olivier Guilyardi:
On 09/11/2010 08:23 PM, hermann wrote:
Okay, when you have generic Desktop rc-style files in mind, maybe libgxw
isn't the solution, I have more something like this in mind:
http://img834.imageshack.us/img834/5087/screenshot027x.png
I guess with a ordinary GTK RC Desktop style file it will look ugly.
greats hermann
You comes into the fine-tune mode after you have
leave ctrl and hold the
mouse-button pressed. A right click on a Controller pops up a spinbox to
set a Value direct.
Press ctrl, hold the mouse button, release ctrl but not the button... That's
quite a hidden feature. I do respect your choice, but that confirms what I said:
it's designed for a specific purpose, it needs some more options to become a
generic widget that can accommodate the various tastes mentioned on this thread.
Also you can use your own images (with rcstyle
files) with your own size
for the knob's, two different sizes for the knobs are possible. You can
change the Image during runtime.
Changing the background image isn't sufficient to rival with the phat knob
visual animation, which provide a rotary level meter, as found in many modern
software. Check out the underlying pixmap(s):
http://svn.berlios.de/wsvn/phat/trunk/phat/pixmaps/knob.png
Main author of libgxw is Andreas Degert, it's
in Alpha stage, and open
for suggestions.
But indeed we see the need for a GTK Audio Widget library because we
need it for our project, so we start to create on.
IMO you should get some inspiration from Phat..
http://phat.berlios.de/
--
Olivier
12:44 p.m.
On 09/14/2010 05:07 AM, hermann wrote:
Okay, when you have generic Desktop rc-style files in
mind, maybe libgxw
isn't the solution, I have more something like this in mind:
http://img834.imageshack.us/img834/5087/screenshot027x.png
I guess with a ordinary GTK RC Desktop style file it will look ugly.
The knobs I'm thinking about would be fully themable, so you should be able to
integrate them into that kind of interface by overriding styles with a rc file
provided by your app. I know that it's a bit controversial, apps shouldn't
bundle/override users' styles according to GTK rules, but some compromise should
be possible.
That said, I'm not really thinking about photorealistic knobs. If you need that,
libgxw or phat are maybe the way to go. I'm more into making a minimal
well-designed knob, in the /spirit/ of Ableton Live. I think that Thorsten's
ideas go into that direction, which I do like, and which could fit in a variety
of UIs.
Actually, it's not really a knob. It's a rotary control *and* level meter. I'd
call it a wheel.
--
Olivier
11 Sep
11 Sep
10:45 p.m.
On Sat, 2010-09-11 at 19:36 +0200, Olivier Guilyardi wrote:
Also, the phat knob, with its large orange/blue border
provides better
visualization IMO. I am however quite sad that in both cases, phat and libgxw,
no SVG source is provided.
--
Olivier
That's the knob animation I use in nekobee. I was going to try to
recreate it in pure cairo - at the moment the "new" cairo knobs just use
cairo surfaces to blit the appropriate frame of animation.
Gordon MM0YEQ
12 Sep
12 Sep
12:39 p.m.
On 09/11/2010 10:45 PM, Gordon JC Pearce wrote:
On Sat, 2010-09-11 at 19:36 +0200, Olivier Guilyardi
wrote:
In my experience it's hard to write code that draws something as cute and smooth
as the phat knob. Ah, actually, I think that JUCE has that.. Needs checking.
In regard to phat, if only the SVG, or XCF, or whatever sources were on svn,
that would allow to tune the colors, the size, etc... Maybe that the solution is
to redraw it in Inkscape.
--
Olivier
Also, the phat knob, with its large orange/blue
border provides better
visualization IMO. I am however quite sad that in both cases, phat and libgxw,
no SVG source is provided.
That's the knob animation I use in nekobee. I was going to try to
recreate it in pure cairo - at the moment the "new" cairo knobs just use
cairo surfaces to blit the appropriate frame of animation.
1:35 p.m.
On Sun, 2010-09-12 at 12:39 +0200, Olivier Guilyardi wrote:
In regard to phat, if only the SVG, or XCF, or
whatever sources were on svn,
that would allow to tune the colors, the size, etc... Maybe that the solution is
to redraw it in Inkscape.
The source is a Blender file. Peter Shorthose took care of animation and
post-processing after I did the design.
I would think this has to be in a repo somewhere, but I have a local
copy, anyway:
http://dl.dropbox.com/u/485382/old_knob_3d.tar.bz2
Great how those won't die, as much as I wish they would, while all the
stuff in http://thorwil.wordpress.com/?s=knobs didn't go anywhere.
The main issue for me is that they always appear alien in GTK windows.
Then the design is not strong enough to warrant creating a whole
matching theme. They are not scalable.
Creating such a series for a knob animation with Inkscape is not exactly
trivial, if you want consistent lighting and a physical feel. For
optimal, scalable results, the drawing should be coded, as otherwise you
get issues with lines that should stay 1px wide and might be neighbors
in some cases.
With knobs, you still have a problem with putting them into a layout
with labels. I think much could be gained with sliders with integrated
labels:
http://dl.dropbox.com/u/485382/sliders.png
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
2:17 p.m.
On 09/12/2010 01:35 PM, Thorsten Wilms wrote:
On Sun, 2010-09-12 at 12:39 +0200, Olivier Guilyardi
wrote:
Cool! Thank you :) I just wish it was plain SVG, I'm everything but familiar
with Blender and friends.
If you can do that, it would be great to commit these files to the Phat SVN.
Pixmaps are like binaries after all, and you got the sources.
In regard to phat, if only the SVG, or XCF, or
whatever sources were on svn,
that would allow to tune the colors, the size, etc... Maybe that the solution is
to redraw it in Inkscape.
The source is a Blender file. Peter Shorthose took care of animation and
post-processing after I did the design.
I would think this has to be in a repo somewhere, but I have a local
copy, anyway:
http://dl.dropbox.com/u/485382/old_knob_3d.tar.bz2 Great how those won't die, as much as I wish they
would, while all the
stuff in http://thorwil.wordpress.com/?s=knobs didn't go anywhere.
Wow, brilliant and professional looking ideas in there..
The main issue for me is that they always appear alien
in GTK windows.
Then the design is not strong enough to warrant creating a whole
matching theme. They are not scalable.
Well, to me, the phat knobs are currently the only simple solution that look ok
in a GTK Window. They're not that alien, there is worse..
Theming, that's a problem. About scalability, I was thinking about rendering SVG
with Cairo (maybe several layers), but that may not be realistic.
IMO, Knobs will always be borderline in regard to GTK UI rules, and that's not
such a big deal, if you provide the proper keyboard shortcuts, etc..
Creating such a series for a knob animation with
Inkscape is not exactly
trivial, if you want consistent lighting and a physical feel. For
optimal, scalable results, the drawing should be coded, as otherwise you
get issues with lines that should stay 1px wide and might be neighbors
in some cases.
I understand, that's quite complex. A simple solution could be to generate the
phat PNG "animation" from 3 SVG files with some python script. One could tweak
the SVG files (or intermediary PNG files) before doing so, adjusting borders if
needed, etc.. The result won't be scalable, but at least, a developer could
easily choose the style and size(s) he wants.
On the other hand, coded drawing may have the downside of fixed style and
anonymous look-and-feel. IMO, audio and music apps need eye-candy, they're not
just scientific instruments.
That said, there really are interesting GTK friendly ideas on your blog.
With knobs, you still have a problem with putting them
into a layout
with labels. I think much could be gained with sliders with integrated
labels:
http://dl.dropbox.com/u/485382/sliders.png
Of course knobs have downsides. But, in a window, knobs can be appropriate for
certain settings, and you can use sliders for others. It can give some graphical
balance. A window full of sliders may not be attractive, and may lack usability.
--
Olivier
14 Sep
14 Sep
6:26 p.m.
On Sun, 12 Sep 2010 12:39:05 +0200
Olivier Guilyardi <list(a)samalyse.com> wrote:
On 09/11/2010 10:45 PM, Gordon JC Pearce wrote:
Juce uses its antialiased drawing code to draw the knob. This requires
no image resources and enables displaying the rotation precisely, it
can be scaled and it's themable (by changing the colours). I think it's
a good way to do it. I don't like realistic-looking knobs very much, to
me it looks always very 90s-Windows-VST-interface-ish, but that's a
personal preference thing I guess.
On Sat, 2010-09-11 at 19:36 +0200, Olivier
Guilyardi wrote:
In my experience it's hard to write code that draws something as cute and smooth
as the phat knob. Ah, actually, I think that JUCE has that.. Needs checking. Also, the phat knob, with its large orange/blue
border provides better
visualization IMO. I am however quite sad that in both cases, phat and libgxw,
no SVG source is provided.
That's the knob animation I use in nekobee. I was going to try to
recreate it in pure cairo - at the moment the "new" cairo knobs just use
cairo surfaces to blit the appropriate frame of animation.
6:46 p.m.
On Tue, Sep 14, 2010 at 12:26 PM, Johannes Kroll <jkroll(a)lavabit.com> wrote:
Juce uses its antialiased drawing code to draw the
knob. This requires
no image resources and enables displaying the rotation precisely, it
can be scaled and it's themable (by changing the colours). I think it's
a good way to do it.
cairo is a highly portable way to do this, and is what hans and i used
to render thorwil's knob design.
15 Sep
15 Sep
2:27 p.m.
On 09/14/2010 06:45 PM, Paul Davis wrote:
On Tue, Sep 14, 2010 at 12:26 PM, Johannes Kroll
<jkroll(a)lavabit.com> wrote:
I too really like Juce, and its knob is indeed a state-of-the-art widget to me.
But I feel like there's something more modern about Thorwil's design, especially
the minimal knobs, not the pseudo-realistic ones. Juce's knob looks a bit as a
clock, or some speed meter, which I don't fancy so much.
For the technical part, that's right, Cairo is just fine.
--
Olivier
Juce uses its antialiased drawing code to draw
the knob. This requires
no image resources and enables displaying the rotation precisely, it
can be scaled and it's themable (by changing the colours). I think it's
a good way to do it.
cairo is a highly portable way to do this, and is what hans and i used
to render thorwil's knob design. 
7 Sep
7 Sep
9:24 p.m.
On Tue, Sep 7, 2010 at 7:23 PM, Gabriel M. Beddingfield
<gabrbedd(a)gmail.com> wrote:
circle: no.
up and down: yes.
scroll wheel: yes.
left and right: up to you.
Agreed on all counts. Of course you can make them respond to
horizontal motion as well, without screwing up people who expect
vertical motion, by taking the max of horizontal and vertical
displacement as the displacement to use.
You don't give quite enough information, though -- there is some
discrepancy out there with regard to whether moving the mouse up
should move the rotary towards the start or end of its travel (i.e. up
= anticlockwise, down = clockwise or the reverse). I had to go and
test some rotary controllers to remind myself which behaviour my hand
expects, and it turns out it's up = clockwise.
Chris
9:44 p.m.
On Tue, 2010-09-07 at 20:24 +0100, Chris Cannam wrote:
On Tue, Sep 7, 2010 at 7:23 PM, Gabriel M.
Beddingfield
<gabrbedd(a)gmail.com> wrote:
That's a funny thing, because I've been looking at some radio equipment
with a big rotary knob to scroll through menu options. Turning the knob
clockwise moves the pointer up, and turning it anti-clockwise moves it
down - utterly unintuitive! Perhaps it's because the scrolly knob is to
the right of the display, so the edge of the knob that moves up should
"follow" the cursor? Without getting the drill out, I can't try the
knob and screen the other way round, and I suspect that the manufacturer
would be unhappy with that.
Gordon MM0YEQ
circle: no.
up and down: yes.
scroll wheel: yes.
left and right: up to you.
Agreed on all counts. Of course you can make them respond to
horizontal motion as well, without screwing up people who expect
vertical motion, by taking the max of horizontal and vertical
displacement as the displacement to use.
You don't give quite enough information, though -- there is some
discrepancy out there with regard to whether moving the mouse up
should move the rotary towards the start or end of its travel (i.e. up
= anticlockwise, down = clockwise or the reverse). I had to go and
test some rotary controllers to remind myself which behaviour my hand
expects, and it turns out it's up = clockwise.
10:18 p.m.
On Tue, Sep 7, 2010 at 8:44 PM, Gordon JC Pearce <gordonjcp(a)gjcp.net> wrote:
On Tue, 2010-09-07 at 20:24 +0100, Chris Cannam wrote:
It may be that. I really couldn't work out in my head which direction
ought to be more intuitive -- and I was surprised by that.
In practise I find I clearly prefer mouse up = clockwise, which is the
relation that you just called unintuitive (and I think I would agree
with you -- there's no very good reason to suppose that preference in
mouse movement would be the same as preference in how a vertical
selection responds to rotary control, but it's interesting to find
they actually do differ). My preference might be just familiarity, or
it might be my vision in the absence of any other cue aligning the
movement of the mouse with that of the left edge of the knob.
Chris
test some rotary controllers to remind myself
which behaviour my hand
expects, and it turns out it's up = clockwise.
That's a funny thing, because I've been looking at some radio equipment
with a big rotary knob to scroll through menu options. Turning the knob
clockwise moves the pointer up, and turning it anti-clockwise moves it
down - utterly unintuitive! Perhaps it's because the scrolly knob is to
the right of the display, so the edge of the knob that moves up should
"follow" the cursor? 
9 Sep
9 Sep
4:15 p.m.
On Tue, 2010-09-07 at 20:44 +0100, Gordon JC Pearce wrote:
That's a funny thing, because I've been
looking at some radio equipment
with a big rotary knob to scroll through menu options. Turning the knob
clockwise moves the pointer up, and turning it anti-clockwise moves it
down - utterly unintuitive!
The knob was on the left side of the display?
--
eins, zwei, drei ... tekno tekno??
http://www.youtube.com/watch?v=ZEgbW1FxR78
7 Sep
7 Sep
8:27 p.m.
Excerpts from Gordon JC Pearce's message of 2010-09-07 20:20:10 +0200:
This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
Gordon MM0YEQ
Imho everything's better than in circles. Even better than mouse is
keyboard (qwerty) control, in which case circles would be really bad.
--
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
10:18 p.m.
On Tue, Sep 07, 2010 at 07:20:10PM +0100, Gordon JC Pearce wrote:
This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
The ones I'm using on some (unpublished ATM) apps and plugins
do:
* click, move either up or right to increment, left or down
to decrement, or
* use the mouse wheel, With shift pressed you get higher
resolution.
For some functions they also display a numerical value for
a few seconds when touched.
The important thing with rotary controls is that everything
should be relative. Having the knob move intantly to a click
position is more than useless, and in some cases quite dangerous.
This is similar to the advantage of *real* rotary controls
vs. linear ones. Try to control a linear fader while you're
running from a riot police assault during a manifestation.
Or under attack from a US helicopter mistaking your mic for
a rocket launcher.
The nice thing about rotary controls - both real and sofrware
- is that they provide a very good quick visual indication of
the current state, something a spinbox well never do, while
linear controls require much more space.
BTW, the main reason why mixers have linear faders is *space*.
A really big rotary knob provides much better control than any
linear fader. But it doesn't allow a for design with just a few
centimeters per channel strip. So as mixer channel counts went
up, the only solution was a linear fader.
Ciao,
--
FA
There are three of them, and Alleline.
10:31 p.m.
On Tue, Sep 7, 2010 at 9:18 PM, <fons(a)kokkinizita.net> wrote:
The important thing with rotary controls is that
everything
should be relative.
True, but also true of (computer GUI, rather than real) faders.
Dragging the mouse should give the impression of dragging the control,
rather than clicking the element instantly positioning the control.
This is similar to the advantage of *real* rotary
controls
vs. linear ones. Try to control a linear fader while you're
running from a riot police assault during a manifestation.
Or under attack from a US helicopter mistaking your mic for
a rocket launcher.
Aside from a certain concern about your longevity if such is your CV,
I think that's a quite different effect -- the cause of that is that
rotary controls have a centre, so that if your hand moves
involuntarily the control won't jump -- you'll just try to push it
into a different place, which will do nothing unless the axle breaks.
Real faders also move in a relative way; you can't instantly move them
to wherever your hand happens to be. It's just that you can push them
much more quickly with an involuntary motion. The absolute vs
relative thing I think is entirely a computer phenomenon.
Chris
10:53 p.m.
On Tue, Sep 07, 2010 at 09:31:08PM +0100, Chris Cannam wrote:
True, but also true of (computer GUI, rather than
real) faders.
Dragging the mouse should give the impression of dragging the control,
rather than clicking the element instantly positioning the control.
I agree.
Aside from a certain concern about your longevity if
such is your CV,
I think that's a quite different effect
Yes, it is different, but there are some subjective similarities.
I've never been under attack from above, but running from the riot
police and tear gas while recording is something I've had to do a
few times (in the Nagra era - they had quite solid rotary gain
controls).
-- the cause of that is that
rotary controls have a centre, so that if your hand moves
involuntarily the control won't jump -- you'll just try to push it
into a different place, which will do nothing unless the axle breaks.
A 1/4 inch steel axle can take a lot more abuse than any linear
fader I know of... unless the potentiometer is supported only by
the PCB, in which case that will be the part that gets destroyed.
But you are right, the essential advantage is that a rotary control
provides support for you hand, you can easily hold it without turning
it even while being shaken in all directions.
Ciao,
--
FA
There are three of them, and Alleline.
10:35 p.m.
Hello Fons,
On 09/07/2010 10:18 PM, fons(a)kokkinizita.net wrote:
The nice thing about rotary controls - both real and
sofrware
- is that they provide a very good quick visual indication of
the current state, something a spinbox well never do, while
linear controls require much more space.
IMO, knobs aren't as good as sliders when it comes to visual feedback.
Also, there's something very counter-intuitive in going up and down to perform
rotation. I know people are used to it, but still...
Growing/unfolding sliders (such as the one I mentioned before) are a solution to
the space problem.
That said, I reckon that adding a few knobs here and there looks cool :) It can
bring some graphical balance and eye-candy, which may be very important. When
you make music, the UI look & feel has some emotional influence on you.
--
Olivier
10:51 p.m.
On Tue, 2010-09-07 at 22:35 +0200, Olivier Guilyardi wrote:
That said, I reckon that adding a few knobs here and
there looks cool :) It can
bring some graphical balance and eye-candy, which may be very important. When
you make music, the UI look & feel has some emotional influence on you.
I've said this all along - "photorealistic" GUIs for softsynths *aren't*
pointless eyecandy. How the app looks materially affects the way we
respond to it and how we perceive its behaviour. In an informal and
not-terribly-controlled experiment, I set up three versions of nekobee.
All had identical voice engines, the only difference between them being
the knob and background pixmaps. One was the "normal" silver with
light-grey knobs, one was black with dark grey knobs, and one was a
plasticky-looking red with black shiny plastic-looking knobs. Of the
four people who tried them, they *all* thought that the silver one
sounded smoother, the black one had a warmer bassier sound and the red
one had a more cutting, middle-y and distorted sound.
Now, if you want to use a "generic" host-supplied UI, that's fine. If
you want a GUI that uses standard toolkit elements (GtkVScale, for
instance) that's fine too. But - I think a softsynth has to *look* like
something you want to fiddle with. Even if it's just a screenshot, it's
got to make you want to find one and have a shot of it. Remember your
first gearlust? It's got to do that.
As for little boxes with numbers, if I wanted to sit and fiddle with
those I'd go and work out my tax rebate on a spreadsheet...
Gordon MM0YEQ
10:57 p.m.
On Tue, 7 Sep 2010, Gordon JC Pearce wrote:
I've said this all along -
"photorealistic" GUIs for softsynths *aren't*
pointless eyecandy. How the app looks materially affects the way we
respond to it and how we perceive its behaviour. In an informal and
This is true. Thank you for articulating it.
-gabriel
8 Sep
8 Sep
1:06 a.m.
On 09/07/2010 10:51 PM, Gordon JC Pearce wrote:
On Tue, 2010-09-07 at 22:35 +0200, Olivier Guilyardi
wrote:
Interesting experiment :)
That said, I reckon that adding a few knobs here
and there looks cool :) It can
bring some graphical balance and eye-candy, which may be very important. When
you make music, the UI look & feel has some emotional influence on you.
I've said this all along - "photorealistic" GUIs for softsynths
*aren't*
pointless eyecandy. How the app looks materially affects the way we
respond to it and how we perceive its behaviour. In an informal and
not-terribly-controlled experiment, I set up three versions of nekobee.
All had identical voice engines, the only difference between them being
the knob and background pixmaps. One was the "normal" silver with
light-grey knobs, one was black with dark grey knobs, and one was a
plasticky-looking red with black shiny plastic-looking knobs. Of the
four people who tried them, they *all* thought that the silver one
sounded smoother, the black one had a warmer bassier sound and the red
one had a more cutting, middle-y and distorted sound. Now, if you want to use a "generic"
host-supplied UI, that's fine. If
you want a GUI that uses standard toolkit elements (GtkVScale, for
instance) that's fine too. But - I think a softsynth has to *look* like
something you want to fiddle with. Even if it's just a screenshot, it's
got to make you want to find one and have a shot of it. Remember your
first gearlust? It's got to do that.
As for little boxes with numbers, if I wanted to sit and fiddle with
those I'd go and work out my tax rebate on a spreadsheet...
"something you want to fiddle with", I agree. Something that inspires you, I
would maybe say.
But, there's nothing absolute about this. If it's about inspiration then it's
highly subjective. For example, I just spent about a full week composing a song
on Renoise. It has plenty of those little boxes with numbers, it's not
photorealistic at all, but the UI is just beautiful to me, and it feels good.
It's very subjective.
When one chooses a guitar, not only the sound is important, but also the way it
feels and looks. Actually, a good guitar is a work of art in itself.
So, forget development, it's time for software lutherie ;)
--
Olivier
9:47 p.m.
On Wed, 08 Sep 2010 01:06:06 +0200
Olivier Guilyardi <list(a)samalyse.com> wrote:
<snip>
But, there's nothing absolute about this. If
it's about inspiration then it's
highly subjective. For example, I just spent about a full week composing a song
on Renoise. It has plenty of those little boxes with numbers, it's not
photorealistic at all, but the UI is just beautiful to me, and it feels good.
It's very subjective.
Exactly, and as I'm a numbers person too, maybe I shouldn't have
diverted the discussion for the knobs ... er, people :)
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
12:15 a.m.
On Tue, Sep 7, 2010 at 10:18 PM, fons wrote:
...
BTW, the main reason why mixers have linear faders is
*space*.
A really big rotary knob provides much better control than any
linear fader. But it doesn't allow a for design with just a few
centimeters per channel strip. So as mixer channel counts went
up, the only solution was a linear fader.
Interesting and plausible, I've never thought of that reason.
I'd still call the reason I previously thought to be the main
one a major one:
Linear faders allow control of more than one parameter
simultaneously with one hand. This may be less accurate
than using a dedicated hand for each parameter but it's
useful, especially for channel volume (where the linear ones
are mostly applied). Besides, it's another reason to build
narrow mixer strips.
And it is another advantage of physical faders/knobs
towards a digital pointer device. Multitouch screens may
improve the situation but they still lack the mechanical
feedback provided by tangible physical objects.
best,
d
12:01 a.m.
On Tuesday 07 September 2010 20:20:10 Gordon JC Pearce wrote:
This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
rotary-movement: Fire up paint. Try to draw 5 perfect quarter circles. And
then ditch that idea completely and forever. The only special cases where
rotary movement works is multi-touch screens or in a limited why when your
"mouse" is a track-ball.
Make it look like a rotary, make it usable like a slider (that is up/down
_or_ left/right movement).
And if you really need to save space: Use it like a slider, paint it as a
color-field with the value as number and color...
Have fun,
Arnold
10:36 a.m.
Excerpts from Arnold Krille's message of 2010-09-08 00:01:30 +0200:
On Tuesday 07 September 2010 20:20:10 Gordon JC Pearce
wrote:
That's actually a neat idea, color for immediate visual feedback. I
imagine the problem is the colors. What would be sane? I guess three
basic colors and interpolate between them?
low = blue
middle = yellow
high = top
It needs to be rather intuitive. I guess the more colors the less
intuitive it will become. Maybe two are enough.
I wonder which color would best represent 'low' or 'bottom'.
Blue, black?
--
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
rotary-movement: Fire up paint. Try to draw 5 perfect quarter circles. And
then ditch that idea completely and forever. The only special cases where
rotary movement works is multi-touch screens or in a limited why when your
"mouse" is a track-ball.
Make it look like a rotary, make it usable like a slider (that is up/down
_or_ left/right movement).
And if you really need to save space: Use it like a slider, paint it as a
color-field with the value as number and color...
Have fun,
Arnold
12:06 p.m.
On Wednesday 08 September 2010 10:35:56 Philipp Überbacher wrote:
Excerpts from Arnold Krille's message of
2010-09-08 00:01:30 +0200:
For the matrix-mixer in ffado-mixer (only in some devices present) I used:
high (max) = red
mid (0dB) = yellow
low (lowest above mute) = blue
mute = black
I also thought about making it dependent of the color-scheme. Like background
for mute and from there on to the highlight-background for max. But there you
don't get as many colors. Which is nice from a designers pov but to
distinguish the values better, two or three different colors should be used
imho.
Have fun,
Arnold
And if you really need to save space: Use it like
a slider, paint it as a
color-field with the value as number and color...
That's actually a neat idea, color for immediate visual feedback. I
imagine the problem is the colors. What would be sane? I guess three
basic colors and interpolate between them?
low = blue
middle = yellow
high = top
It needs to be rather intuitive. I guess the more colors the less
intuitive it will become. Maybe two are enough.
I wonder which color would best represent 'low' or 'bottom'.
Blue, black? 
4:36 p.m.
Previously:
That's actually a neat idea, color for immediate
visual feedback. I
imagine the problem is the colors. What would be sane? I guess three
basic colors and interpolate between them?
low = blue
middle = yellow
high = top
It needs to be rather intuitive. I guess the more colors the less
intuitive it will become. Maybe two are enough.
I wonder which color would best represent 'low' or 'bottom'.
Blue, black?
Please forgive total outsider butting in.
I suggest you keep it simple, i.e. only two colours if possible, but
make them configurable for the benefit of those with visual disabilities.
Andrew Bryant
5:36 p.m.
Excerpts from Andrew Bryant's message of 2010-09-08 16:35:31 +0200:
Previously:
There are no insiders or outsiders, there are just list members.
That's actually a neat idea, color for
immediate visual feedback. I
imagine the problem is the colors. What would be sane? I guess three
basic colors and interpolate between them?
low = blue
middle = yellow
high = top
It needs to be rather intuitive. I guess the more colors the less
intuitive it will become. Maybe two are enough.
I wonder which color would best represent 'low' or 'bottom'.
Blue, black?
Please forgive total outsider butting in. I suggest you keep it simple, i.e. only two colours if
possible, but
make them configurable for the benefit of those with visual disabilities.
Andrew Bryant
I wondered about that part too, especially about color blind people.
I don't know any, as far as I know, and so I have no experience with it.
So just maybe a greyscale mode would help? This would depend heavily on
the background color though. So maybe Arnolds idea with the background
color on the lower end makes sense. You still need to see that there is
something that shows you something and you still need a certain
color/intensity range, or it's rather useless.
In greyscale white background to black for highest intensity would offer
the largest range. I guess some light grey to black would still be good
enough.
--
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
6:18 p.m.
On 08/09/10 16:36, Philipp Überbacher wrote:
Snip
You could play with colours, and offer a .jpg to this link:
http://www.etre.com/tools/colourblindsimulator/
to make sure it's acceptable.
Andrew.
I suggest you keep it simple, i.e. only two
colours if possible, but
make them configurable for the benefit of those with visual disabilities.
Andrew Bryant
I wondered about that part too, especially about color blind people.
I don't know any, as far as I know, and so I have no experience with it.
So just maybe a greyscale mode would help? This would depend heavily on
the background color though. So maybe Arnolds idea with the background
color on the lower end makes sense. You still need to see that there is
something that shows you something and you still need a certain
color/intensity range, or it's rather useless.
In greyscale white background to black for highest intensity would offer
the largest range. I guess some light grey to black would still be good
enough.
7:19 p.m.
On Wednesday 08 September 2010 16:35:31 Andrew Bryant wrote:
Previously:
Two colors simply isn't enough. You need a color for low, a color for middle
and a value for high. And then you haven't even looked at a fourth color for
mute/off.
And fading from green directly/linear to red gives an ugly brown in the
middle. It looks much nicer to go across yellow. And then you can really use
that third color to stand for a special step, not just "in the middle of the
slider".
If these colors are taken from the color-scheme the user has chosen, I feel
confident, that these are suitable for all kinds of color-blindness (otherwise
the color-scheme is chosen wrongly). But I don't know (yet) which color roles
to use from the color-schemes...
Have fun,
Arnold
That's actually a neat idea, color for
immediate visual feedback. I
imagine the problem is the colors. What would be sane? I guess three
basic colors and interpolate between them?
low = blue
middle = yellow
high = top
It needs to be rather intuitive. I guess the more colors the less
intuitive it will become. Maybe two are enough.
I wonder which color would best represent 'low' or 'bottom'.
Blue, black?
I suggest you keep it simple, i.e. only two colours if possible, but
make them configurable for the benefit of those with visual disabilities.
9:06 p.m.
Excerpts from Arnold Krille's message of 2010-09-08 19:18:54 +0200:
On Wednesday 08 September 2010 16:35:31 Andrew Bryant
wrote:
If all you want is 'middle' and that doesn't need to be well defined,
then two colors will do. I suggested blue because of the ugly brown you
get between green and red. With blue the middle will likely be some kind
of purple, which may or may not be optimal. Maybe black to red would be
nicer, it just gives you an increasingly bright red.
Mute/off, if required, would be the same as the lowest setting.
Previously:
Two colors simply isn't enough. You need a color for low, a color for middle
and a value for high. And then you haven't even looked at a fourth color for
mute/off.
And fading from green directly/linear to red gives an ugly brown in the
middle. It looks much nicer to go across yellow. And then you can really use
that third color to stand for a special step, not just "in the middle of the
slider". That's actually a neat idea, color for
immediate visual feedback. I
imagine the problem is the colors. What would be sane? I guess three
basic colors and interpolate between them?
low = blue
middle = yellow
high = top
It needs to be rather intuitive. I guess the more colors the less
intuitive it will become. Maybe two are enough.
I wonder which color would best represent 'low' or 'bottom'.
Blue, black?
I suggest you keep it simple, i.e. only two colours if possible, but
make them configurable for the benefit of those with visual disabilities. If these colors are taken from the color-scheme the
user has chosen, I feel
confident, that these are suitable for all kinds of color-blindness (otherwise
the color-scheme is chosen wrongly). But I don't know (yet) which color roles
to use from the color-schemes...
Have fun,
Arnold
To what kind of user chosen color scheme do you refer to?
--
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
10:02 p.m.
Hi,
On Wednesday 08 September 2010 21:06:29 Philipp Überbacher wrote:
The one the user choose for his desktop. Which is the only real way to
compensate for visually impaired people (if thats the political correct name).
I don't like this every-app-chooses-its-own-colors at all. Though I do
understand that sometimes you need more colors, but that still is different
from "I define my apps colors on my own because I think that is cool". The
later results in apps with black text on dark-gray background in an otherwise
very light desktop-environment => bad. Or in apps with white window background
while the rest of the desktop is optimized for on-stage-in-the-dark with black
background and red foreground => bad. Or it results with using two collors to
"distinguish" which half visually impaired people can't discriminate =>
bad.
Thats why I really advocate using the systems color-scheme as much as possible
(and a bit more) every time the discussion regarding colors comes up.
Have fun,
Arnold
Excerpts from Arnold Krille's message of
2010-09-08 19:18:54 +0200:
I don't want 'a' middle, I want a special middle. Like 0dB between -48dB and
+12dB (the middle doesn't have to be in the geometrical middle). And I want to
know when that special middle value is reached by looking at the color.
On Wednesday 08 September 2010 16:35:31 Andrew
Bryant wrote:
If all you want is 'middle' and that
doesn't need to be well defined,
then two colors will do. I suggested blue because of the ugly brown you
get between green and red. With blue the middle will likely be some kind
of purple, which may or may not be optimal. Maybe black to red would be
nicer, it just gives you an increasingly bright red. Previously:
Two colors simply isn't enough. You need a color for low, a color for
middle and a value for high. And then you haven't even looked at a
fourth color for mute/off.
And fading from green directly/linear to red gives an ugly brown in the
middle. It looks much nicer to go across yellow. And then you can really
use that third color to stand for a special step, not just "in the
middle of the slider". That's actually a neat idea, color for
immediate visual feedback. I
imagine the problem is the colors. What would be sane? I guess three
basic colors and interpolate between them?
low = blue
middle = yellow
high = top
It needs to be rather intuitive. I guess the more colors the less
intuitive it will become. Maybe two are enough.
I wonder which color would best represent 'low' or 'bottom'.
Blue, black?
I suggest you keep it simple, i.e. only two colours if possible, but
make them configurable for the benefit of those with visual
disabilities. Mute/off, if required, would be the same as the lowest
setting.
There is a difference between mute/off and the lowest setting. At least there
can be.
Software-mixers might not make that discrete step between off and almost
silent. But some hardware mixers in devices do make that difference. And there
it will make a difference to your ear whether the signal is attenuated by 36dB
or muted.
If these
colors are taken from the color-scheme the user has chosen, I
feel confident, that these are suitable for all kinds of color-blindness
(otherwise the color-scheme is chosen wrongly). But I don't know (yet)
which color roles to use from the color-schemes...
To what kind of user chosen
color scheme do you refer to?
10:15 p.m.
On Wed, Sep 8, 2010 at 8:02 PM, Arnold Krille <arnold(a)arnoldarts.de> wrote:
The one the user choose for his desktop. Which is the
only real way to
compensate for visually impaired people (if thats the political correct name).
I don't like this every-app-chooses-its-own-colors at all. Though I do
understand that sometimes you need more colors, but that still is different
from "I define my apps colors on my own because I think that is cool". The
later results in apps with black text on dark-gray background in an otherwise
very light desktop-environment => bad. Or in apps with white window background
while the rest of the desktop is optimized for on-stage-in-the-dark with black
background and red foreground => bad. Or it results with using two collors to
"distinguish" which half visually impaired people can't discriminate =>
bad.
and which system color(s) do you propose to use to indicate:
* this thing is muted?
* this thing is rec-enabled?
* the value indicated here is at the low end of the scale?
* this object is blinking to alert you to some condition?
11:24 p.m.
Hi,
On Wednesday 08 September 2010 22:15:33 Paul Davis wrote:
On Wed, Sep 8, 2010 at 8:02 PM, Arnold Krille
<arnold(a)arnoldarts.de> wrote:
Here is my shot:
(Speaking in terms of
http://doc.trolltech.com/4.6/qpalette.html#ColorRole-enum because thats the
toolkit I know...)
The discussion started with faders showing the value by color. Could also be
used by meters.
Muted/off: Window-color (that is the normal background of windows)
Really low: Shadow
Low: Dark
Middle: Light
High: Highlight (which would be the alarm color)
I did a quick test with ffado-mixer, the first screenshot is the current version
with black-blue-green-yellow-red, the second is the window-shadow-dark-light-
highlight version:
http://positron.physik.uni-halle.de/~arnold/fadercolors-green_yellow_red.png
http://positron.physik.uni-halle.de/~arnold/fadercolors-system_colors.png
In the second case I think a small 1px border around each "fader" would be
appropriate. Have to think about that.
Now to the ardour-specific questions:
Muted could be visualized just by graying out the whole
track/channel/fader/meter or by de-saturating it.
Rec-enabled would be a border in the Highlight color.
And if its about toggle-buttons that should increase visibility when
activated, these could be colored in the Highlight color or the Base color
(used for input-widgets).
Something needing immediate attention could be marked by blinking in the
Highlight color. Or by having a blinking 5px border in the Highlight color.
Generally there are several ways to make something stand out:
- Color it to stand out. Which is what the Highlight color is for.
- Make it big.
- Give it space.
- Make it stand out with a simple 3D effect like a raised/sunken border or a
shadow.
The last three don't require special colors.
I know there are special apps that need so many colors that the system palette
is not enough. I know ardour is the prime example there.
But I don't understand why apps like puredata don't follow the systems
defaults? Black objects on white background stand out much to much when my
laptop is trimmed for live-foh usage where the normal "Text on Base" colors
would be "Wine Red on Black". If it simply used that colors as provided by the
system/toolkit, it would blend in perfectly...
Have fun,
Arnold
The one the user choose for his desktop. Which is
the only real way to
compensate for visually impaired people (if thats the political correct
name). I don't like this every-app-chooses-its-own-colors at all. Though
I do understand that sometimes you need more colors, but that still is
different from "I define my apps colors on my own because I think that
is cool". The later results in apps with black text on dark-gray
background in an otherwise very light desktop-environment => bad. Or in
apps with white window background while the rest of the desktop is
optimized for on-stage-in-the-dark with black background and red
foreground => bad. Or it results with using two collors to "distinguish"
which half visually impaired people can't discriminate => bad.
and which system color(s) do you propose to use to indicate:
* this thing is muted?
* this thing is rec-enabled?
* the value indicated here is at the low end of the scale?
* this object is blinking to alert you to some condition? 
11:38 p.m.
Hi,
On Wednesday 08 September 2010 23:24:01 Arnold Krille wrote:
I did a quick test with ffado-mixer, the first
screenshot is the current
version with black-blue-green-yellow-red, the second is the
window-shadow-dark-light- highlight version:
http://positron.physik.uni-halle.de/~arnold/fadercolors-green_yellow_red.pn
g http://positron.physik.uni-halle.de/~arnold/fadercolors-system_colors.png
I just did two more screenshots showcasing the system-colors thing with two
dark color-schemes. Nothing changed in ffado-mixer!
http://positron.physik.uni-halle.de/~arnold/fadercolors-system_colors-wonto…
http://positron.physik.uni-halle.de/~arnold/fadercolors-system_colors-obsid…
Have fun,
Arnold
9 Sep
9 Sep
12:37 a.m.
On 09/08/2010 11:37 PM, Arnold Krille wrote:
http://positron.physik.uni-halle.de/~arnold/fadercolors-system_colors-wonto…
http://positron.physik.uni-halle.de/~arnold/fadercolors-system_colors-obsid…
Sorry but wouldn't it be clearer with tiny level bars, instead of colors?
http://testing.samalyse.com/lad/widgets/numbers.png
http://testing.samalyse.com/lad/widgets/numbers.svg
--
Olivier
8 Sep
8 Sep
10:19 p.m.
Excerpts from Arnold Krille's message of 2010-09-08 22:02:10 +0200:
The one the user choose for his desktop. Which is the only real way to
compensate for visually impaired people (if thats the political correct name).
I don't like this every-app-chooses-its-own-colors at all. Though I do
understand that sometimes you need more colors, but that still is different
from "I define my apps colors on my own because I think that is cool". The
later results in apps with black text on dark-gray background in an otherwise
very light desktop-environment => bad. Or in apps with white window background
while the rest of the desktop is optimized for on-stage-in-the-dark with black
background and red foreground => bad. Or it results with using two collors to
"distinguish" which half visually impaired people can't discriminate =>
bad.
Thats why I really advocate using the systems color-scheme as much as possible
(and a bit more) every time the discussion regarding colors comes up.
Have fun,
Arnold
I don't know of any way to set a system wide color scheme of any sort. I
know of different toolkits using their specific settings, and that's as
close to a system color theme as I'm aware of. I did switch to a dark
theme and managed to get qt use the GTK theme, but that still leaves a
lot of programs out of the equation. Note that Desktop-Environments in
the sense of gnome/kde is something I despise, mainly because of their
current understanding of 'integration', which in practice means to
almost force users to use certain programs and an unbelievable
dependency hell. They each create their very specific ecosystem in which
they attempt to 'integrate' everything else, which just means to make
stuff dependent on more and more of the ecosystems specific subsystems.
/rant
Well, I don't know how to achieve anything like a system color scheme in
the foreseeable future.
--
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
Hi,
On Wednesday 08 September 2010 21:06:29 Philipp Überbacher wrote:
I was talking about controls in general, which means there might not be
any dB or mute or anything like that, it might be anything, and there
might be special cases/settings where you want a special color, agreed.
Excerpts from Arnold Krille's message of
2010-09-08 19:18:54 +0200:
I don't want 'a' middle, I want a special middle. Like 0dB between -48dB and
+12dB (the middle doesn't have to be in the geometrical middle). And I want to
know when that special middle value is reached by looking at the color.
On Wednesday 08 September 2010 16:35:31 Andrew
Bryant wrote:
If all you want is 'middle' and that
doesn't need to be well defined,
then two colors will do. I suggested blue because of the ugly brown you
get between green and red. With blue the middle will likely be some kind
of purple, which may or may not be optimal. Maybe black to red would be
nicer, it just gives you an increasingly bright red. Previously:
> That's actually a neat idea, color for immediate visual feedback. I
> imagine the problem is the colors. What would be sane? I guess three
> basic colors and interpolate between them?
> low = blue
> middle = yellow
> high = top
>
> It needs to be rather intuitive. I guess the more colors the less
> intuitive it will become. Maybe two are enough.
> I wonder which color would best represent 'low' or 'bottom'.
> Blue, black?
I suggest you keep it simple, i.e. only two colours if possible, but
make them configurable for the benefit of those with visual
disabilities.
Two colors simply isn't enough. You need a color for low, a color for
middle and a value for high. And then you haven't even looked at a
fourth color for mute/off.
And fading from green directly/linear to red gives an ugly brown in the
middle. It looks much nicer to go across yellow. And then you can really
use that third color to stand for a special step, not just "in the
middle of the slider". Mute/off, if required, would be the same as the
lowest setting.
There is a difference between mute/off and the lowest setting. At least there
can be.
Software-mixers might not make that discrete step between off and almost
silent. But some hardware mixers in devices do make that difference. And there
it will make a difference to your ear whether the signal is attenuated by 36dB
or muted. If these colors are taken from the color-scheme the
user has chosen, I
feel confident, that these are suitable for all kinds of color-blindness
(otherwise the color-scheme is chosen wrongly). But I don't know (yet)
which color roles to use from the color-schemes...
To what kind of user chosen
color scheme do you refer to?
10:37 p.m.
On Wed, Sep 08, 2010 at 10:19:50PM +0200, Philipp Überbacher wrote:
I don't know of any way to set a system wide color
scheme of any sort. I
know of different toolkits using their specific settings, and that's as
close to a system color theme as I'm aware of. I did switch to a dark
theme and managed to get qt use the GTK theme, but that still leaves a
lot of programs out of the equation. Note that Desktop-Environments in
the sense of gnome/kde is something I despise, mainly because of their
current understanding of 'integration', which in practice means to
almost force users to use certain programs and an unbelievable
dependency hell. They each create their very specific ecosystem in which
they attempt to 'integrate' everything else, which just means to make
stuff dependent on more and more of the ecosystems specific subsystems.
/rant
Well, I don't know how to achieve anything like a system color scheme in
the foreseeable future.
The simple fact is that X11 has and always has had an excellent system
to handle this. It allows to define resources (colors, fonts, whatever)
for
- all applications,
- classes of applications,
- a single application,
- a particular named instance of an application.
It's far superior to anything else I've seen (in particular
to anything else using XML).
Common GUI toolkits, wanting to be 'cross platform' usually
completely ignore this.
/rant
Ciao
--
FA
There are three of them, and Alleline.
11:38 p.m.
On 22:37 Wed 08 Sep , fons(a)kokkinizita.net wrote:
On Wed, Sep 08, 2010 at 10:19:50PM +0200, Philipp
?berbacher wrote:
Is it possible that the unrestrained urge and perception of glamour associated with shiny
toolkits has supplanted
solid if "boring" fundamentals already available in X?
Enquiring minds want to know. :)
Alex.
I don't know of any way to set a system wide
color scheme of any sort. I
know of different toolkits using their specific settings, and that's as
close to a system color theme as I'm aware of. I did switch to a dark
theme and managed to get qt use the GTK theme, but that still leaves a
lot of programs out of the equation. Note that Desktop-Environments in
the sense of gnome/kde is something I despise, mainly because of their
current understanding of 'integration', which in practice means to
almost force users to use certain programs and an unbelievable
dependency hell. They each create their very specific ecosystem in which
they attempt to 'integrate' everything else, which just means to make
stuff dependent on more and more of the ecosystems specific subsystems.
/rant
Well, I don't know how to achieve anything like a system color scheme in
the foreseeable future.
The simple fact is that X11 has and always has had an excellent system
to handle this. It allows to define resources (colors, fonts, whatever)
for
- all applications,
- classes of applications,
- a single application,
- a particular named instance of an application.
It's far superior to anything else I've seen (in particular
to anything else using XML).
Common GUI toolkits, wanting to be 'cross platform' usually
completely ignore this.
/rant
Ciao
--
FA
There are three of them, and Alleline.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
9 Sep
9 Sep
7:51 a.m.
New subject: X behaviour (was Mouse/knob interaction)
On 08/09/10 22:38, Alex wrote:
Snip
Is it possible that the unrestrained urge and
perception of glamour associated with shiny toolkits has supplanted
solid if "boring" fundamentals already available in X?
Enquiring minds want to know. :)
Alex.
I am inclined to concur with this proposition.
Are you able to name any X application written in this millennium which
understands "-geometry"? My current bete noire is alsaplayer which
adheres to the centre of the screen like a limpet. But I suppose I have
overlooked some simple switch somewhere.
Andrew
8:11 a.m.
New subject: X behaviour (was Mouse/knob interaction)
On Thursday 09 September 2010, Andrew Bryant wrote:
Most Qt/KDE applications:
qsynth -geometry 400x300
vmpk -geometry 2000x200
kmetronome -geometry 2000x800
smplayer -geometry 1024x700
For more information:
man 7 kdeoptions
man 7 qtoptions
Regards,
Pedro
On 08/09/10 22:38, Alex wrote:
Snip
> Is it possible that the unrestrained urge and perception of glamour
associated with shiny toolkits has supplanted
solid if
"boring" fundamentals already available in X?
Enquiring minds want to know. :)
Alex.
I am inclined to concur with this proposition.
Are you able to name any X application written in this millennium which
understands "-geometry"?
12:28 a.m.
Excerpts from fons's message of 2010-09-08 22:37:54 +0200:
On Wed, Sep 08, 2010 at 10:19:50PM +0200, Philipp
Überbacher wrote:
Just out of general interest, is this an Xlib thing or does XCB provide
the same stuff?
--
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
I don't know of any way to set a system wide
color scheme of any sort. I
know of different toolkits using their specific settings, and that's as
close to a system color theme as I'm aware of. I did switch to a dark
theme and managed to get qt use the GTK theme, but that still leaves a
lot of programs out of the equation. Note that Desktop-Environments in
the sense of gnome/kde is something I despise, mainly because of their
current understanding of 'integration', which in practice means to
almost force users to use certain programs and an unbelievable
dependency hell. They each create their very specific ecosystem in which
they attempt to 'integrate' everything else, which just means to make
stuff dependent on more and more of the ecosystems specific subsystems.
/rant
Well, I don't know how to achieve anything like a system color scheme in
the foreseeable future.
The simple fact is that X11 has and always has had an excellent system
to handle this. It allows to define resources (colors, fonts, whatever)
for
- all applications,
- classes of applications,
- a single application,
- a particular named instance of an application.
It's far superior to anything else I've seen (in particular
to anything else using XML).
Common GUI toolkits, wanting to be 'cross platform' usually
completely ignore this.
/rant
Ciao
--
FA
There are three of them, and Alleline.
8 Sep
8 Sep
10:47 p.m.
On Wednesday 08 September 2010 22:19:50 Philipp Überbacher wrote:
Excerpts from Arnold Krille's message of
2010-09-08 22:02:10 +0200:
The one the user choose for his desktop. Which is the only real way to
compensate for visually impaired people (if thats the political correct
name). I don't like this every-app-chooses-its-own-colors at all. Though
I do understand that sometimes you need more colors, but that still is
different from "I define my apps colors on my own because I think that
is cool". The later results in apps with black text on dark-gray
background in an otherwise very light desktop-environment => bad. Or in
apps with white window background while the rest of the desktop is
optimized for on-stage-in-the-dark with black background and red
foreground => bad. Or it results with using two collors to "distinguish"
which half visually impaired people can't discriminate => bad.
Thats why I really advocate using the systems color-scheme as much as
possible (and a bit more) every time the discussion regarding colors
comes up.
I don't know of any way to set a system wide color scheme of any sort. I
know of different toolkits using their specific settings, and that's as
close to a system color theme as I'm aware of. I did switch to a dark
theme and managed to get qt use the GTK theme, but that still leaves a
lot of programs out of the equation. Note that Desktop-Environments in
the sense of gnome/kde is something I despise, mainly because of their
current understanding of 'integration', which in practice means to
almost force users to use certain programs and an unbelievable
dependency hell. They each create their very specific ecosystem in which
they attempt to 'integrate' everything else, which just means to make
stuff dependent on more and more of the ecosystems specific subsystems.
/rant
Well, I don't know how to achieve anything like a system color scheme in
the foreseeable future.
You don't have to use the desktop-environment to use the toolkit. And the
toolkits have become good enough to support/respect each others style and
colors. At least here on my kde systems the gtk apps (apart from ardour:) use
the system-wide colors I set in kde's systemsettings.
And even if you personally don't use a DE, the users of your app will. And
they will a) like it more if it blends in and b) ditch it if its colors/fonts
don't respect system-defaults that are set because of visual imperfections.
Have fun,
Arnold
PS: No, we don't need another ColorSchemeKit and a GlobalFontKit;-)
Hi,
On Wednesday 08 September 2010 21:06:29 Philipp Überbacher wrote:
I was talking about controls in general, which means there might not be
any dB or mute or anything like that, it might be anything, and there
might be special cases/settings where you want a special color, agreed.
Excerpts from Arnold Krille's message of
2010-09-08 19:18:54 +0200:
I don't want 'a' middle, I want a special middle. Like 0dB between -48dB
and +12dB (the middle doesn't have to be in the geometrical middle). And
I want to know when that special middle value is reached by looking at
the color.
On Wednesday 08 September 2010 16:35:31 Andrew
Bryant wrote:
> Previously:
> > That's actually a neat idea, color for immediate visual feedback.
> > I imagine the problem is the colors. What would be sane? I guess
> > three basic colors and interpolate between them?
> > low = blue
> > middle = yellow
> > high = top
> >
> > It needs to be rather intuitive. I guess the more colors the less
> > intuitive it will become. Maybe two are enough.
> > I wonder which color would best represent 'low' or 'bottom'.
> > Blue, black?
>
> I suggest you keep it simple, i.e. only two colours if possible,
> but make them configurable for the benefit of those with visual
> disabilities.
Two colors simply isn't enough. You need a color for low, a color for
middle and a value for high. And then you haven't even looked at a
fourth color for mute/off.
And fading from green directly/linear to red gives an ugly brown in
the middle. It looks much nicer to go across yellow. And then you
can really use that third color to stand for a special step, not
just "in the middle of the slider".
If all you want is 'middle' and that doesn't need to be well defined,
then two colors will do. I suggested blue because of the ugly brown you
get between green and red. With blue the middle will likely be some
kind of purple, which may or may not be optimal. Maybe black to red
would be nicer, it just gives you an increasingly bright red. Mute/off, if required, would be the same as the
lowest setting.
There is a difference between mute/off and the lowest setting. At least
there can be.
Software-mixers might not make that discrete step between off and almost
silent. But some hardware mixers in devices do make that difference. And
there it will make a difference to your ear whether the signal is
attenuated by 36dB or muted. If these colors are taken from the color-scheme the
user has chosen,
I feel confident, that these are suitable for all kinds of
color-blindness (otherwise the color-scheme is chosen wrongly). But
I don't know (yet) which color roles to use from the
color-schemes...
To what kind of user chosen color scheme do you refer to?
9 Sep
9 Sep
12:38 a.m.
Excerpts from Arnold Krille's message of 2010-09-08 22:46:52 +0200:
On Wednesday 08 September 2010 22:19:50 Philipp
Überbacher wrote:
That's still very gtk/qt or even kde/gnome centric. There's a lot more
out there. Those might be the prevalent toolkits but certainly not the
only ones. That's the gnome/kde bubble so many seem to be stuck in and
not being able to see beyond.
Excerpts from Arnold Krille's message of
2010-09-08 22:02:10 +0200:
I don't know of any way to set a system wide color scheme of any sort. I
know of different toolkits using their specific settings, and that's as
close to a system color theme as I'm aware of. I did switch to a dark
theme and managed to get qt use the GTK theme, but that still leaves a
lot of programs out of the equation. Note that Desktop-Environments in
the sense of gnome/kde is something I despise, mainly because of their
current understanding of 'integration', which in practice means to
almost force users to use certain programs and an unbelievable
dependency hell. They each create their very specific ecosystem in which
they attempt to 'integrate' everything else, which just means to make
stuff dependent on more and more of the ecosystems specific subsystems.
/rant
Well, I don't know how to achieve anything like a system color scheme in
the foreseeable future.
You don't have to use the desktop-environment to use the toolkit. And the
toolkits have become good enough to support/respect each others style and
colors. At least here on my kde systems the gtk apps (apart from ardour:) use
the system-wide colors I set in kde's systemsettings. Hi,
On Wednesday 08 September 2010 21:06:29 Philipp Überbacher wrote:
I was talking about controls in general, which means there might not be
any dB or mute or anything like that, it might be anything, and there
might be special cases/settings where you want a special color, agreed.
Excerpts from Arnold Krille's message of
2010-09-08 19:18:54 +0200:
> On Wednesday 08 September 2010 16:35:31 Andrew Bryant wrote:
> > Previously:
> > > That's actually a neat idea, color for immediate visual feedback.
> > > I imagine the problem is the colors. What would be sane? I guess
> > > three basic colors and interpolate between them?
> > > low = blue
> > > middle = yellow
> > > high = top
> > >
> > > It needs to be rather intuitive. I guess the more colors the less
> > > intuitive it will become. Maybe two are enough.
> > > I wonder which color would best represent 'low' or
'bottom'.
> > > Blue, black?
> >
> > I suggest you keep it simple, i.e. only two colours if possible,
> > but make them configurable for the benefit of those with visual
> > disabilities.
>
> Two colors simply isn't enough. You need a color for low, a color for
> middle and a value for high. And then you haven't even looked at a
> fourth color for mute/off.
> And fading from green directly/linear to red gives an ugly brown in
> the middle. It looks much nicer to go across yellow. And then you
> can really use that third color to stand for a special step, not
> just "in the middle of the slider".
If all you want is 'middle' and that doesn't need to be well defined,
then two colors will do. I suggested blue because of the ugly brown you
get between green and red. With blue the middle will likely be some
kind of purple, which may or may not be optimal. Maybe black to red
would be nicer, it just gives you an increasingly bright red.
I don't want 'a' middle, I want a special middle. Like 0dB between -48dB
and +12dB (the middle doesn't have to be in the geometrical middle). And
I want to know when that special middle value is reached by looking at
the color.
Mute/off, if required, would be the same as the
lowest setting.
There is a difference between mute/off and the lowest setting. At least
there can be.
Software-mixers might not make that discrete step between off and almost
silent. But some hardware mixers in devices do make that difference. And
there it will make a difference to your ear whether the signal is
attenuated by 36dB or muted. > If
these colors are taken from the color-scheme the user has chosen,
> I feel confident, that these are suitable for all kinds of
> color-blindness (otherwise the color-scheme is chosen wrongly). But
> I don't know (yet) which color roles to use from the
> color-schemes...
To what kind of user chosen color scheme do you refer to?
The one the user choose for his desktop. Which is the only real way to
compensate for visually impaired people (if thats the political correct
name). I don't like this every-app-chooses-its-own-colors at all. Though
I do understand that sometimes you need more colors, but that still is
different from "I define my apps colors on my own because I think that
is cool". The later results in apps with black text on dark-gray
background in an otherwise very light desktop-environment => bad. Or in
apps with white window background while the rest of the desktop is
optimized for on-stage-in-the-dark with black background and red
foreground => bad. Or it results with using two collors to "distinguish"
which half visually impaired people can't discriminate => bad.
Thats why I really advocate using the systems color-scheme as much as
possible (and a bit more) every time the discussion regarding colors
comes up. And even if you personally don't use a DE, the
users of your app will. And
they will a) like it more if it blends in and b) ditch it if its colors/fonts
don't respect system-defaults that are set because of visual imperfections.
Have fun,
Arnold
I think b) is total bollocks, because there are no system-defaults, only
gnome/kde defaults (and apparently X defaults no one uses) and because
users won't ditch an app just because they don't blend in visually.
There are a lot more and a lot more important reasons to choose one
program over another.
PS: No, we don't need another ColorSchemeKit and a
GlobalFontKit;-)
Agreed.
(Written from a *kit-free system)
--
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
8 Sep
8 Sep
1:02 a.m.
On September 7, 2010 02:20:10 pm Gordon JC Pearce wrote:
This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
Gordon MM0YEQ
A quick check of our MusE knobs shows it's circular motion.
Circular or linear doesn't really bother me too much,
but if linear, then both up/down AND left/right should
operate the knob. I've seen some that do one but not the other.
However, I would like to share with you a 'patented' (he he)
technique I developed a long time ago:
When the mouse cursor goes to the edge of the screen you
have no more movement, forcing you to pick up the mouse
and go back to another position away from the screen edge
and continue adjusting.
So here's what you do in the coding:
When the control is clicked, you turn off the mouse cursor so that
it is always INVISIBLE during adjustment, then you force it to the
CENTRE of the screen, and wait for some mouse movement.
When movement happens, you record how much it moved (delta)
and use that to adjust the control's value (as usual), and then you
FORCE the mouse cursor right back to the CENTRE of the screen again,
waiting for more mouse movement, and the whole process repeats.
Then when the control is un-clicked, you force the mouse cursor
back to where it originally would have been, and turn it on again
so it's visible.
This way the mouse NEVER reaches the edge of the screen during
adjustment, although it may physically reach the edge of your desk.
However, with trackball mice you can keep on rolling and rolling, and
the control keeps adjusting without end !
I used this technique in a 'spinbox' derivative which I call 'RollEdit'.
I hate reeeeally tiny spinbox up/down arrows, and waiting for them
to increment, don't you?
With my 'RollEdit', you simply click anywhere in the edit portion
and start rolling, and rolling, and rolling, and the value keeps
going and going and going... No mouse repositioning needed.
I also used it in 3D modelling apps: You click anywhere in a 'scene'
and start rolling, and the zoom or viewer position (for example)
just keeps going and going. No visible mouse cursor to get in the way.
Excellent with trackballs !
(AutoDesk's 3D Studio at one time came close to this, but they
messed it up by leaving the mouse cursor visible and making
it 'wrap around' the edges of the screen. Like the game Asteroids,
very annoying.)
All of that work was in Windows and it was very complicated because
you can receive multiple mouse movement messages for just one
movement.
I've always wondered if Linux would be able to handle this technique
better than in Windows. Never investigated yet. Opinions?
In MusE, when you click on any slider, even in the slider trough area,
the mouse cursor is FORCED to the centre of the slider knob.
I did this to help with automation, so that you could easily 'grab' the
slider knob even while it was in fast motion due to existing automation
movements.
Gotta go! Looks like bad thunderstorm here!
Thanks. Tim.
1:37 p.m.
On 09/08/2010 12:46 AM, Tim E. Real wrote:
However, I would like to share with you a
'patented' (he he)
technique I developed a long time ago:
I am contesting the patent, I did start to work on the same idea two years ago :p
When the mouse cursor goes to the edge of the screen
you
have no more movement, forcing you to pick up the mouse
and go back to another position away from the screen edge
and continue adjusting.
Fully agreed.
Small knobs at the bottom of the screen are unusable.
So here's what you do in the coding:
When the control is clicked, you turn off the mouse cursor so that
it is always INVISIBLE during adjustment, then you force it to the
CENTRE of the screen, and wait for some mouse movement.
When movement happens, you record how much it moved (delta)
and use that to adjust the control's value (as usual), and then you
FORCE the mouse cursor right back to the CENTRE of the screen again,
waiting for more mouse movement, and the whole process repeats.
Then when the control is un-clicked, you force the mouse cursor
back to where it originally would have been, and turn it on again
so it's visible.
That's quite what happens with Jackbeat sliders, oh well, that was the basic
idea. The pointer is hidden during the move, and restored (warped) to its
original position afterwards. However, at some point in time, I think I left the
idea of centering on the screen aside. There must have been some GTK/GDK
problems on some OS out there. And actually I reorganized the UI so that is not
needed.
This way the mouse NEVER reaches the edge of the
screen during
adjustment, although it may physically reach the edge of your desk.
This isn't much of an issue, you can always lift the mouse and put it back on
the desk.
7:30 a.m.
Am Dienstag, den 07.09.2010, 19:20 +0100 schrieb Gordon JC Pearce:
This is going to stir up a bit of discussion!
Rotary knob GUI elements - should you move the mouse in a circle to
operate them, or up and down? What about side to side?
Gordon MM0YEQ
Like I said before, I prefer the circle movement, and I like to let the
knob jump to the point were I click. Therefore we used a smooth factor
to avoid clicks in the sound. But we make it also possible to move the
mouse up and down, when used together with ctrl, and when you leave the
ctrl while the mouse is pressed, you come in the fine tune mode. A
middle click pops up a Midi learn widget to connect the GUI controller
with a Midi controller.
Also we show the value permanent, and with a right click on the value, a
spinbox pops up, where you can enter your value with the keyboard
direct.
Anyway, mostly I use the mouse-wheel to change the values, that's what
gives me the best feeling for a Knob.
greats hermann
16 Sep
16 Sep
2:18 a.m.
This looks like a better mouse-knob interactor, e.g. use the mouse for
pointing/selecting, and then use this knob for simultaneously
controlling multiple parameters on the selected channel at once.
http://www.3dconnexion.com/products/spacenavigator.html
"push, pull, twist or tilt"
someone needs to build a driver that outputs MIDI controllers for every "axis"
-- Niels
http://nielsmayer.com
10:46 a.m.
On 09/16/2010 02:18 AM, Niels Mayer wrote:
This looks like a better mouse-knob interactor, e.g.
use the mouse for
pointing/selecting, and then use this knob for simultaneously
controlling multiple parameters on the selected channel at once.
http://www.3dconnexion.com/products/spacenavigator.html
"push, pull, twist or tilt"
someone needs to build a driver that outputs MIDI controllers for every "axis"
i've worked with a predecessor of this thing, and it was nice. the
downside of it is that it's an integrating controller: you apply
constant force or torque (=constant displacement) along any axis, and
it's interpreted as constant velocity of your pointer. that means it
behaves like a joystick, not like a mouse. very nice for intuitive
manipulation of objects, but hitting precise values or locations is
quite hard.
8:53 p.m.
On 09/16/2010 02:18 AM, Niels Mayer wrote:
This looks like a better mouse-knob interactor, e.g.
use the mouse for
pointing/selecting, and then use this knob for simultaneously
controlling multiple parameters on the selected channel at once.
In regard to controlling several parameters with a single knob, a pure software
UI could make use of the first item on the following post:
http://thorwil.wordpress.com/2007/04/22/not-knobs-4/
It is meant to control a range, but there could be other uses I guess.
I can't really think of a real world use-case right now though..
--
Olivier
5524
days inactive
5533
days old
linux-audio-dev@lists.linuxaudio.org
88 comments
22 participants
participants (22)
-
Alex -
Andrew Bryant -
Arnold Krille -
Chris Cannam -
David Adler -
Folderol -
fons＠kokkinizita.net -
Gabriel M. Beddingfield -
Gordon JC Pearce -
hermann -
Igor Brkic -
Jens M Andreasen -
Johannes Kroll -
Jörn Nettingsmeier -
Loki Davison -
Niels Mayer -
Olivier Guilyardi -
Paul Davis -
Pedro Lopez-Cabanillas -
Philipp Überbacher -
Thorsten Wilms -
Tim E. Real