26 Feb
2007
26 Feb
'07
8:41 a.m.
On Thu, 2007-02-22 at 06:42 -0600, Jan Depner wrote:
I can say that the QT package is much easier to use
and has
better documentation and support. Not that GTK is terrible, it's just
not as polished or professional.
the enemy of the good is the better.
i, for one, used the past 3 days to write a python module named
"audiogui", which provides widgets to mimick the look and feel of
traditional audio hardware panels (i dare you to start an audio ui
design war with me). it will be the base for providing an engine which
renders panels from stylesheets, to be used with plugins of aldrin - but
of course that whole thing could be connected to an OSC library and
control any DSSI host.
the basic idea was to imitate the design seen from native instruments
plugins and propellerheads reason. of course i'm damn proud that the
results look so well ;)
here is a demo showing the three widgets DecoBox, Knob and LCD, with
different settings applied.
http://www.paniq.org/images/audiogui5.png
in case you want to play with it, the module is based on PyGTK+ and
Cairo, and can be checked out from the aldrin svn.
http://svn.zeitherrschaft.org/aldrin/trunk
you find the scripts in share/aldrin, they are named audiogui.py and
lcdfont.py. run audiogui.py for above demonstration.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
26 Feb
26 Feb
9:37 a.m.
Hi
Very nice!!
Is the 'WTF' the volume control :))))
Cheers
Bob
On 26/02/07, Leonard Ritter <contact(a)leonard-ritter.com> wrote:
On Thu, 2007-02-22 at 06:42 -0600, Jan Depner wrote:
I can say that the QT package is much easier to
use and has
better documentation and support. Not that GTK is terrible, it's just
not as polished or professional.
the enemy of the good is the better.
i, for one, used the past 3 days to write a python module named
"audiogui", which provides widgets to mimick the look and feel of
traditional audio hardware panels (i dare you to start an audio ui
design war with me). it will be the base for providing an engine which
renders panels from stylesheets, to be used with plugins of aldrin - but
of course that whole thing could be connected to an OSC library and
control any DSSI host.
the basic idea was to imitate the design seen from native instruments
plugins and propellerheads reason. of course i'm damn proud that the
results look so well ;)
here is a demo showing the three widgets DecoBox, Knob and LCD, with
different settings applied.
http://www.paniq.org/images/audiogui5.png
in case you want to play with it, the module is based on PyGTK+ and
Cairo, and can be checked out from the aldrin svn.
http://svn.zeitherrschaft.org/aldrin/trunk
you find the scripts in share/aldrin, they are named audiogui.py and
lcdfont.py. run audiogui.py for above demonstration.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
11:24 a.m.
måndag 26 februari 2007 14:20 skrev Frank Smith:
Hi
Very nice!!
Dito
Is the 'WTF' the volume control :))))
Must be Whats The Fuzz. Can't imagine what else :-D
--
- Bengan ------------------------------------------------------------
- KTHNOC - No1 Internet Offspring | http://www.noc.kth.se/~bengan ---
- 08-7906586 (ej vidarekopplat), 070-6443325 ------------------------
12:31 p.m.
On Mon, 2007-02-26 at 16:24 +0100, Bengt Gördén wrote:
It's the War on Terror Filter of course!
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
måndag 26 februari 2007 14:20 skrev Frank Smith:
thank you!
Hi
Very nice!!
Dito Is the
'WTF' the volume control :))))
Must be Whats The Fuzz. Can't imagine what else :-D 
9:42 a.m.
Leonard Ritter wrote:
On Thu, 2007-02-22 at 06:42 -0600, Jan Depner wrote:
now that sounds cool... sort of a widget system specific for
audio
control gui's.
I can say that the QT package is much easier to
use and has
better documentation and support. Not that GTK is terrible, it's just
not as polished or professional.
the enemy of the good is the better.
i, for one, used the past 3 days to write a python module named
"audiogui", which provides widgets to mimick the look and feel of
traditional audio hardware panels (i dare you to start an audio ui
design war with me). it will be the base for providing an engine which
renders panels from stylesheets, to be used with plugins of aldrin - but
of course that whole thing could be connected to an OSC library and
control any DSSI host.
the basic idea was to imitate the design seen from native instruments
plugins and propellerheads reason. of course i'm damn proud that the
results look so well ;)
rightfully so, very impressive.
Pieter
8:14 p.m.
On 2/27/07, Pieter Palmers <pieterp(a)joow.be> wrote:
Leonard Ritter wrote:
wow... a sort of widget system for audio gui's....
http://phat.berlios.de http://khagan.berlios.de
;)
Loki
p.s. not to blow my own trumpet or anything, i'm pretty impressed
james new it existed.
On Thu, 2007-02-22 at 06:42 -0600, Jan Depner
wrote:
now that sounds cool... sort of a widget system specific
for audio
control gui's.
I can say that the QT package is much easier to
use and has
better documentation and support. Not that GTK is terrible, it's just
not as polished or professional.
the enemy of the good is the better.
i, for one, used the past 3 days to write a python module named
"audiogui", which provides widgets to mimick the look and feel of
traditional audio hardware panels (i dare you to start an audio ui
design war with me). it will be the base for providing an engine which
renders panels from stylesheets, to be used with plugins of aldrin - but
of course that whole thing could be connected to an OSC library and
control any DSSI host.
27 Feb
27 Feb
6:04 a.m.
Loki Davison wrote:
On 2/27/07, Pieter Palmers <pieterp(a)joow.be>
wrote:
The "renders panels from
stylesheets" is what I am referring to. Phat is
has very nice widgets, but AFAIK it stops before the container level.
That's where the widget 'system' comes in: a system that manages widgets
such that you don't have to care about that. Just write a UI description
and have the system generate the UI for you (at run time).
That would allow to concentrate on the coding and have someone else
figure out the best UI layout. Or have people customize their layout.
Pieter
Leonard Ritter wrote:
wow... a sort of widget system for audio gui's....
http://phat.berlios.de http://khagan.berlios.de On Thu, 2007-02-22 at 06:42 -0600, Jan Depner
wrote:
but
I can say that the QT package is much easier to
use and has
better documentation and support. Not that GTK is terrible, it's just
not as polished or professional.
the enemy of the good is the better.
i, for one, used the past 3 days to write a python module named
"audiogui", which provides widgets to mimick the look and feel of
traditional audio hardware panels (i dare you to start an audio ui
design war with me). it will be the base for providing an engine which
renders panels from stylesheets, to be used with plugins of aldrin - of course that whole thing could be connected to
an OSC library and
control any DSSI host.
now that sounds cool... sort of a widget system specific
for audio
control gui's.
6:45 a.m.
On Tue, 2007-02-27 at 11:01 +0100, Pieter Palmers wrote:
The "renders panels from stylesheets" is
what I am referring to. Phat
is
has very nice widgets, but AFAIK it stops before the container
level.
That's where the widget 'system' comes in: a system that manages
widgets
such that you don't have to care about that. Just write a UI
description
and have the system generate the UI for you (at run time).
right. you could argue that LV2 might offer enough metadata to help a
host build a good UI, but my approach is meant to give plugin coders
more control. i know from my experience with plugin developers that they
like to set apart their works "from the competition", and spend a great
deal on presentation. providing them with a set of highly customizable
(hardware-like) widgets + a document-like format to describe a panel is
the goal here. yes, it's nothing big. it's just about making this
special field more accessible. the result will be screenshots showing
off a lot of beautiful panels that people are used to from commercial
applications. the effect will be "i want this, it looks good. i want to
play with it."
of course there is nothing wrong with a beauty of logic beneath the
surface that waits to be discovered by the attentive and insistent.
however, inside of everyone, there is a little child easily amazed by
beauty, with a longing to possess, touch, move and play with the things
it adores.
and, in my opinion, playing around is something very important in music.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
7:25 p.m.
On 2/27/07, Pieter Palmers <pieterp(a)joow.be> wrote:
Loki Davison wrote:
I kinda thought that's what khagan does. Allows users to build there
own UI or let a layout designer build it. Thus why i gave both links.
Loki
On 2/27/07, Pieter Palmers
<pieterp(a)joow.be> wrote:
The "renders panels from
stylesheets" is what I am referring to. Phat is
has very nice widgets, but AFAIK it stops before the container level.
That's where the widget 'system' comes in: a system that manages widgets
such that you don't have to care about that. Just write a UI description
and have the system generate the UI for you (at run time).
That would allow to concentrate on the coding and have someone else
figure out the best UI layout. Or have people customize their layout.
Pieter
Leonard Ritter wrote:
wow... a sort of widget system for audio gui's....
http://phat.berlios.de http://khagan.berlios.de On Thu, 2007-02-22 at 06:42 -0600, Jan Depner
wrote:
> I can say that the QT package is much easier to use and has
> better documentation and support. Not that GTK is terrible, it's just
> not as polished or professional.
the enemy of the good is the better.
i, for one, used the past 3 days to write a python module named
"audiogui", which provides widgets to mimick the look and feel of
traditional audio hardware panels (i dare you to start an audio ui
design war with me). it will be the base for providing an engine which
renders panels from stylesheets, to be used with plugins of aldrin -
but
of course that whole thing could be connected to
an OSC library and
control any DSSI host.
now that sounds cool... sort of a widget system specific
for audio
control gui's.
28 Feb
28 Feb
5:32 a.m.
Loki Davison wrote:
On 2/27/07, Pieter Palmers <pieterp(a)joow.be>
wrote:
I would expect that you know it better than me ;) So you're most
probably right. The only 'issue' I have is that it seems to force you to
use OSC as a control protocol. But then again, that might be a good thing...
Pieter
PS: does anyone know where I can 'GPL' an decent OSC server
implementation in C++?
Loki Davison wrote:
The "renders panels from
stylesheets" is what I am referring to. Phat is
has very nice widgets, but AFAIK it stops before the container level.
That's where the widget 'system' comes in: a system that manages widgets
such that you don't have to care about that. Just write a UI description
and have the system generate the UI for you (at run time).
That would allow to concentrate on the coding and have someone else
figure out the best UI layout. Or have people customize their layout.
Pieter
I kinda thought that's what khagan does. Allows users to build there
own UI or let a layout designer build it. Thus why i gave both links. On 2/27/07, Pieter Palmers
<pieterp(a)joow.be> wrote:
> Leonard Ritter wrote:
> > On Thu, 2007-02-22 at 06:42 -0600, Jan Depner wrote:
> >> I can say that the QT package is much easier to use and has
> >> better documentation and support. Not that GTK is terrible,
it's just
> >> not as polished or professional.
> >
> > the enemy of the good is the better.
> >
> > i, for one, used the past 3 days to write a python module named
> > "audiogui", which provides widgets to mimick the look and feel of
> > traditional audio hardware panels (i dare you to start an audio ui
> > design war with me). it will be the base for providing an engine
which
>
renders panels from stylesheets, to be used with plugins of aldrin -
but
> of course that whole thing could be connected to an OSC library and
> control any DSSI host.
now that sounds cool... sort of a widget system specific for audio
control gui's.
wow... a sort of widget system for audio gui's....
http://phat.berlios.de http://khagan.berlios.de 
1:33 p.m.
PS: does anyone know where I can 'GPL' an
decent OSC server
implementation in C++?
The LibLo implementation is GPL, very easy to use, and available in many
distros including Ubuntu.
http://liblo.sourceforge.net/
I'm using it for a project and it seems very good.
I think having an OSC-controlled audio back-end is a Good Thing.
Steve
1 Mar
1 Mar
12:35 p.m.
On 28 Feb 2007, at 17:29, Stephen Sinclair wrote:
PS: does anyone know where I can 'GPL' an decent OSC server
implementation in C++?
The LibLo implementation is GPL, very easy to use, and available in
many distros including Ubuntu.
http://liblo.sourceforge.net/
I'm using it for a project and it seems very good.
I think having an OSC-controlled audio back-end is a Good Thing.
It is C, not C++ though, but I think a few people have used it in
their C++ programs without too much trouble.
There are some native C++ implementations, but I don't remember the
names offhand.
- Steve
26 Feb
26 Feb
9:43 a.m.
here is a demo showing the three widgets DecoBox, Knob
and LCD, with
different settings applied.
http://www.paniq.org/images/audiogui5.png
Absolutely beautiful, thanks for making this!
I got the code from
and got some errors (pasted in at the end), but the GUI mostly
appeared. This is just a bug report, I don't need to see a fix.
How hard would it be to integrate this great work with that of Phat/PyPhat?
James
$ python audiogui.py
Traceback (most recent call last):
File "audiogui.py", line 736, in on_realize
self.get_characters() # to initialize
File "audiogui.py", line 753, in get_characters
ctx.push_group()
AttributeError: 'gtk.gdk.CairoContext' object has no attribute
'push_group'
Traceback (most recent call last):
File "audiogui.py", line 736, in on_realize
self.get_characters() # to initialize
File "audiogui.py", line 753, in get_characters
ctx.push_group()
AttributeError: 'gtk.gdk.CairoContext' object has no attribute
'push_group'
Traceback (most recent call last):
File "audiogui.py", line 792, in on_expose
self.draw(self.context)
File "audiogui.py", line 830, in draw
self.window.draw_drawable(gc, chars[ord(c)], 0, 0, int(rx), int(ry), -1, -1)
IndexError: list index out of range
Traceback (most recent call last):
File "audiogui.py", line 701, in on_expose
self.draw(self.context)
File "audiogui.py", line 668, in draw
ctx.push_group()
[... and many more similar ones ...]
12:29 p.m.
On Mon, 2007-02-26 at 13:32 +0000, James McDermott wrote:
and got some errors (pasted in at the end), but the
GUI mostly
appeared. This is just a bug report, I don't need to see a fix.
yes, i suppose this is version collision. i need those commands tho. i
use cairo 1.3.14 and python-cairo 1.2.0
How hard would it be to integrate this great work with that of Phat/PyPhat?
i don't know if the targets are the same. phat is supplying controls
suitable for controlling aspects of audio, while my controls are for
emulating audio hardware. adding to that, phat is written in c/c++,
while this module is written in python.
i will not write any code in c/c++ if it's not incredibly necessary.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
1:13 p.m.
On 2/26/07, Leonard Ritter <contact(a)leonard-ritter.com> wrote:
Agreed, they're not quite the same. From the point of view of critical
mass of developers, and that of learning the APIs, it would be nice to
be able to say "XYZ is *the* GTK widget set for audio apps" but yes,
perhaps the projects are too different. Both are nice!
On Mon, 2007-02-26 at 13:32 +0000, James McDermott
wrote:
I have these:
python-cairo:
Installed: 1.0.2-1ubuntu1
libcairo2:
Installed: 1.0.4-0ubuntu1
So that looks like significant version skew. Feel free to ignore me, I
haven't moved since Ubuntu Dapper...
and got some errors (pasted in at the end), but
the GUI mostly
appeared. This is just a bug report, I don't need to see a fix.
yes, i suppose this is version collision. i need those commands tho. i
use cairo 1.3.14 and python-cairo 1.2.0 How hard would
it be to integrate this great work with that of Phat/PyPhat?
i don't know if the targets are the same.
7:40 p.m.
On Mon, 2007-02-26 at 21:35 +0000, Chris Cannam wrote:
On Monday 26 Feb 2007 12:41, Leonard Ritter wrote:
check it out. it's y-linear. radial is for weirdos with the motor skills
of a clockmaker.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
(i dare you to start an audio ui design war with
me).
Radial or linear mouse control for the dials?
8:12 p.m.
On 2/27/07, Leonard Ritter <contact(a)leonard-ritter.com> wrote:
On Mon, 2007-02-26 at 21:35 +0000, Chris Cannam
wrote:
Awesome! ;) So phat and audiogui agree on that! ... radial is evil...
and i'm happy with putting this stuff into phat / pyphat if you are.
It's c and python btw not c++ but i code mostly python stuff now days.
I think it's okay to have the more emulation style gui's and the
modernist gui style in one package because mostly it's just front end
looks not actual actions. Though i'm more keen to get everyone to use
fansliders for everything because i think they are awesome some aspect
of choice is nice. If you want to merge this with phat i can give you
svn access. If you want to look at some really interesting audio gui
ideas some of Thorsten's widget ideas are amazing for env controls,
etc.
Loki
On Monday 26 Feb 2007 12:41, Leonard Ritter
wrote:
check it out. it's y-linear. radial is for weirdos with the motor skills
of a clockmaker.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com (i dare you to start an audio ui design war with
me).
Radial or linear mouse control for the dials?
27 Feb
27 Feb
4:10 a.m.
On Tue, 2007-02-27 at 11:12 +1100, Loki Davison wrote:
and i'm happy with putting this stuff into phat /
pyphat if you are.
give it some more time. when i made my first synth layouts with it, i'll
contribute.
Though i'm more keen to get everyone to use
fansliders for everything because i think they are awesome some aspect
of choice is nice.
To be honest, they confuse me. mapping resolution to the y-scale is not
such a good idea, since you can't have strict movements along the x or
y-axis. if i travel up or down to increase resolution, it is possible
that the x-position changes as well, because that's how a mouse works.
similarly, if i move the mouse left or right, it jitters up or down as
well. when in finetuning mode, the slider obstructs other gui elements.
Even if it's not crucial, that jittery-wobbly way of moving is
unnerving.
i do not need fine resolution most of the time. it is usually fine for
me to drag the slider where i want, and then adjust the last few clicks
with the scrollwheel. making fine resolution adjustment an integral and
pervasive aspect of the slider misses the point.
besides that it doesn't even look good. it's scary pointy-edged stuff.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
28 Feb
28 Feb
10:13 a.m.
On Tue, Feb 27, 2007 at 09:09:18AM +0100, Leonard Ritter wrote:
On Tue, 2007-02-27 at 11:12 +1100, Loki Davison
wrote:
well. when in finetuning mode, the slider obstructs other gui elements.
I'm hoping to some day, maybe later this year, find a way to make
fansliders translucent ...
besides that it doesn't even look good. it's
scary pointy-edged stuff.
and less scary, pointy-edged. Unless someone else gets to it first, of
course. These two aspects of the fansliders have always bothered me a
bit, but I still prefer them to knobs.
-Eric Rz.
6:30 p.m.
On 3/1/07, Eric Dantan Rzewnicki <eric(a)zhevny.com> wrote:
On Tue, Feb 27, 2007 at 09:09:18AM +0100, Leonard
Ritter wrote:
Yeah, new xorg stuff should make this very easy. Though i'm not sure
if demanding high xorg versions is perfect but i guess if people want
less pointy that's what they get.
Thorsten's not knobs are still the coolest thing since sliced bread.
Loki
On Tue, 2007-02-27 at 11:12 +1100, Loki Davison
wrote:
well. when in finetuning mode, the slider obstructs other gui elements.
I'm hoping to some day, maybe later this year, find a way to make
fansliders translucent ...
besides that it doesn't even look good.
it's scary pointy-edged stuff.
and less scary, pointy-edged. Unless someone else gets to it first, of
course. These two aspects of the fansliders have always bothered me a
bit, but I still prefer them to knobs.
-Eric Rz.
27 Feb
27 Feb
11:43 a.m.
On Monday 26 Feb 2007 23:40, Leonard Ritter wrote:
radial is for weirdos with the motor skills of a
clockmaker.
Correct! But where have all the radial supporters gone? There were
enough to sustain quite a flamewar about this a couple of years back.
I prefer linear in both axes (right or up to increment, left or down to
decrement), so there may be some scope for disagreement after all.
I've been considering making a small library of Qt4 widgets based on the
ones in the current SVN of Sonic Visualiser -- dial (based on the
RG/qsynth one), thumbwheel, panner, fader (based on Hydrogen).
They aren't particularly beautiful or consistent to look at -- if they
were, I wouldn't just be considering it, I'd have bundled them up a
while ago. But what they do do is work consistently: click and drag to
adjust, without any inadvertant jumps on plain clicks; double-click to
open a text field edit window provided by the widget; middle-click or
ctrl+left-click to reset to default; mouse wheel supported. They all
(except panner) support attaching a mapper object that translates
between the underlying floating point values and screen integers, so
you can use them for things like logarithmic scales and get the correct
mapping and units for their automatic tooltips and the edit window.
Chris
1:03 p.m.
On Tue, 2007-02-27 at 15:45 +0000, Chris Cannam wrote:
[...] But what they do do is work consistently: click
and drag to
adjust, without any inadvertant jumps on plain clicks; double-click to
open a text field edit window provided by the widget;
You could have a single text-field for the lot, placed somewhere
convenient. On mouse-over on a slider or knob, attach it to the
textfield and move focus there. Mouse-wheel and arrows still works as
expected but the widget will be instantly ready for direct numeric input
without double-clicking. Gives you an exact readout of the current
numeric value as well without wasting too much screen real-estate.
middle-click or
ctrl+left-click to reset to default; mouse wheel supported. They all
(except panner) support attaching a mapper object that translates
between the underlying floating point values and screen integers, so
you can use them for things like logarithmic scales and get the correct
mapping and units for their automatic tooltips and the edit window.
Chris
--
1:22 p.m.
On Tue, Feb 27, 2007 at 03:45:18PM +0000, Chris Cannam wrote:
On Monday 26 Feb 2007 23:40, Leonard Ritter wrote:
They are tired of this discussion? ;p
(No, it wasn't just me)
radial is for weirdos with the motor skills of a
clockmaker.
Correct! But where have all the radial supporters gone? There were
enough to sustain quite a flamewar about this a couple of years back. I prefer linear in both axes (right or up to
increment, left or down to
decrement), so there may be some scope for disagreement after all.
To me, the main problem is the lack of agreement on wether
plain knobs should be radial, linear-vertical, linear horizontaly,
linear-both.
That was part of my motivation for fan-sliders:
http://leute.uni-wuppertal.de/~ka0394/en/fan-sliders/index.html
I still think classic knob graphics imply radial and anything else
is visual lying. Quite a while ago I worked on a concept of widgets
with a knob-size footprint and graphics that hint at their non radial
nature.
First I worked out 2 ways how they could be linear without using
only one axis. The first image contains 2 charts to explain
the 2 ways:
- using distance the pointer has been move from the center after
mouse-down
- projecting the current position to the nearest axis
http://thorwil.affenbande.org/index.php/2007/02/27/circulars/
There was one developer who pretty much insistet on knobs in
Phat and who was at one point willing to implement my design(s),
but then dropped it just because I called them not-knobs at
some point (plus being busy otherwise, I guess). Nobody else was
in sight, so I stopped there.
... panner, fader (based on Hydrogen).
Looked at Ardour 2 recently? I think you should have a look at
the new sliders and panners.
--
Thorsten Wilms
3:09 p.m.
On Tuesday 27 February 2007, Thorsten Wilms wrote:
On Tue, Feb 27, 2007 at 03:45:18PM +0000, Chris Cannam
wrote:
A well done radial device would have some usefullness in another field,
that of machine control, where a continuously rotating 'knob' with a
decent calibration dial around it, could be made into a good substitute
for the handwheels on a lathe or milling machine. If it could be made
into a fairly well self contained module, with only a quadrature encoded
output to be steered to the axis where you want to cause a motion, I think
the guys on the emc list might be interested.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
On Monday 26 Feb 2007 23:40, Leonard Ritter
wrote:
They are tired of this discussion? ;p
(No, it wasn't just me)
radial is for weirdos with the motor skills of a
clockmaker.
Correct! But where have all the radial supporters gone? There were
enough to sustain quite a flamewar about this a couple of years back. I prefer linear in both axes (right or up to
increment, left or down
to decrement), so there may be some scope for disagreement after all.
To me, the main problem is the lack of agreement on wether
plain knobs should be radial, linear-vertical, linear horizontaly,
linear-both.
That was part of my motivation for fan-sliders:
http://leute.uni-wuppertal.de/~ka0394/en/fan-sliders/index.html
I still think classic knob graphics imply radial and anything else
is visual lying. Quite a while ago I worked on a concept of widgets
with a knob-size footprint and graphics that hint at their non radial
nature.
First I worked out 2 ways how they could be linear without using
only one axis. The first image contains 2 charts to explain
the 2 ways:
- using distance the pointer has been move from the center after
mouse-down
- projecting the current position to the nearest axis
http://thorwil.affenbande.org/index.php/2007/02/27/circulars/
There was one developer who pretty much insistet on knobs in
Phat and who was at one point willing to implement my design(s),
but then dropped it just because I called them not-knobs at
some point (plus being busy otherwise, I guess). Nobody else was
in sight, so I stopped there.
... panner, fader (based on Hydrogen).
Looked at Ardour 2 recently? I think you should have a look at
the new sliders and panners. 
1:23 p.m.
Chris Cannam wrote:
On Monday 26 Feb 2007 23:40, Leonard Ritter wrote:
Linear dials are counter-intuitive. If you see something you are suposed
to "turn" in real life, you will not try "lifting" it first. Besides,
with radial dials it's easier to control the value precisely --- you
want more precision, just move the pointer further away from the center.
Anyway I prefer faders. I don't really understand why one would need 4
(or more) diferent widgets wich do the same thing: dials, thumbwheels,
panners, faders, spinboxes, scrollbars, etc. The same happens with
non-audio widgets: lists do the same as radioboxes and dropdowns,
checkboxes could be replaced with togglebuttons, (qt) toolboxes act
just like tabbed windows.
It is inconsistent and, IMHO, it looks ugly.
Camilo.
radial is for weirdos with the motor skills of a
clockmaker.
Correct! But where have all the radial supporters gone? There were
enough to sustain quite a flamewar about this a couple of years back.
I prefer linear in both axes (right or up to increment, left or down to
decrement), so there may be some scope for disagreement after all.
I've been considering making a small library of Qt4 widgets based on the
ones in the current SVN of Sonic Visualiser -- dial (based on the
RG/qsynth one), thumbwheel, panner, fader (based on Hydrogen).
28 Feb
28 Feb
9:22 a.m.
On Tue, Feb 27, 2007 at 03:45:18PM +0000, Chris Cannam wrote:
On Monday 26 Feb 2007 23:40, Leonard Ritter wrote:
sorry... for high latency :)
A KNOB WITHOUT RIGHT CLICK RADIAL MOVEMENTS IS A BAD KNOB.
and nobody wants bad knobs.
grrrr... ;)
radial is for weirdos with the motor skills of a
clockmaker.
Correct! But where have all the radial supporters gone? There were
enough to sustain quite a flamewar about this a couple of years back.
I prefer linear in both axes (right or up to increment, left or down to
decrement), so there may be some scope for disagreement after all.
I've been considering making a small library of Qt4 widgets based on the
ones in the current SVN of Sonic Visualiser -- dial (based on the
RG/qsynth one), thumbwheel, panner, fader (based on Hydrogen).
They aren't particularly beautiful or consistent to look at -- if they
were, I wouldn't just be considering it, I'd have bundled them up a
while ago. But what they do do is work consistently: click and drag to
adjust, without any inadvertant jumps on plain clicks; double-click to
open a text field edit window provided by the widget; middle-click or
ctrl+left-click to reset to default; mouse wheel supported. They all
(except panner) support attaching a mapper object that translates
between the underlying floating point values and screen integers, so
you can use them for things like logarithmic scales and get the correct
mapping and units for their automatic tooltips and the edit window.
Chris
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
10:10 a.m.
En/na Chris Cannam ha escrit:
I've been considering making a small library of
Qt4 widgets based on the
ones in the current SVN of Sonic Visualiser -- dial (based on the
RG/qsynth one), thumbwheel, panner, fader (based on Hydrogen).
They aren't particularly beautiful or consistent to look at -- if they
were, I wouldn't just be considering it, I'd have bundled them up a
while ago. But what they do do is work consistently: click and drag to
adjust, without any inadvertant jumps on plain clicks; double-click to
open a text field edit window provided by the widget; middle-click or
ctrl+left-click to reset to default; mouse wheel supported. They all
(except panner) support attaching a mapper object that translates
between the underlying floating point values and screen integers, so
you can use them for things like logarithmic scales and get the correct
mapping and units for their automatic tooltips and the edit window.
Hi Chris,
Such Qt4 widgets plugin (library) would be great!
In clam we already have a Qt4 plugin useful giving the user the ability
to desig the front-end of a clam processing network:
http://iua-share.upf.es/wikis/clam/index.php/Network_Editor_tutorial
The widgets in our plugin are not sliders and knobs, but for data
visualization (a.k.a. "monitors") such as oscilloscope, spectrogram,
sinusoidal peaks, chord-space (tonal), etc. At the moment we use normal
Qt sliders as controls, so it would be great to reuse your control
widgets.
Maybe you might be interested in our data monitor widgets, as well.
Those widgets are only coupled to a DataSource abstract class (C++), so
they can easily be incorporated into different apps. At the moment we
only have instantaneous (or frame) monitors. X-axis-time monitors are
planted after clam 1.0. So this seems another opportunity to share among
Qt4 based audio apps.
Cheers,
Pau
--
http://clam.iua.upf.edu
27 Feb
27 Feb
4:37 p.m.
Le Mon, 26 Feb 2007 13:41:08 +0100,
Leonard Ritter <contact(a)leonard-ritter.com> a écrit :
On Thu, 2007-02-22 at 06:42 -0600, Jan Depner wrote:
Just a remark about Qt GUI. It is like another OS: well looking but foolish. I
use QJackCtl on FVWM-Crystal, and when changing the recipe (theme in
FVWM-Crystal) the systray icon become weird or just disappear because Qt/KDE
implementation of the systray is compatible with nothing else. If QJackCtl
was minimized with the systray, the consequence is at I must "killall qjackctl"
and restart it in order to get in control again. It is not what I call
"professional".
I don't have this problem with GTK applications.
Another problem with Qt/KDE is dcop. It work well inside KDE but produce more
warning or error messages in the logs as useful effects on another wm's as kde.
Again, it is not what I call "professional".
I don't want to start a flame war, it is just what I an thinking. Otherwise, I
don't care much about the look of a program as long at it is doing the job and
at I will be able to read what is on the screen even when running my screen at
high definition.
In that regard, a good feature for a toolkit will be the possibility to
completely zoom in or out a program, inclusive the pixmaps on the toolbars and
the text everywhere (as with Ctrl-Alt-+/- for X but just for a program), but I
know no toolkit that can do that.
Cheers,
Dominique
I can say that the QT package is much easier to
use and has
better documentation and support. Not that GTK is terrible, it's just
not as polished or professional.
6:21 p.m.
Dominique Michel wrote:
Le Mon, 26 Feb 2007 13:41:08 +0100,
Leonard Ritter <contact(a)leonard-ritter.com> a écrit :
Remarks due: First of all, QjackCtl just has no relation to KDE
whatsover, besides sharing the same toolkit framework (Qt3). More
importantly to your case, QjackCtl systray icon implementation is _my_
own, and is _only_ supposed to work on KDE, Gnome and on all other
freedesktop.org X11/systray icon protocol compliant desktop
environments. All other DE/WM's are thus _not_ supported and users
should avoid opting on using QjackCtl systray icon mode, due to
unpredictable behavior.
If you find QjackCtl systray behavior "unprofessional" its just because
you're forcing it to run where it was never tested nor designed to work.
Just switch the systray icon option off and you'll be fine, I hope.
Cheers,
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Thu, 2007-02-22 at 06:42 -0600, Jan Depner
wrote:
> I can say that the QT package is much easier to use and has
> better documentation and support. Not that GTK is terrible, it's just
> not as polished or professional.
Just a remark about Qt GUI. It is like another OS: well looking but foolish. I
use QJackCtl on FVWM-Crystal, and when changing the recipe (theme in
FVWM-Crystal) the systray icon become weird or just disappear because Qt/KDE
implementation of the systray is compatible with nothing else. If QJackCtl
was minimized with the systray, the consequence is at I must "killall
qjackctl"
and restart it in order to get in control again. It is not what I call
"professional".
28 Feb
28 Feb
6:56 a.m.
Le Tue, 27 Feb 2007 22:19:19 +0000,
Rui Nuno Capela <rncbc(a)rncbc.org> a écrit :
Dominique Michel wrote:
I don't get this problem with other programs as sylpheed-claws. No matter, I
use another workaround for this systray issue. I added a qjackctl menu in my
audio button. It have 2 options: "killall qjackctl" and "start
qjackctl".
The good news is at this problem occur only with recipe switching, so I almost
never use this qjackctl menu. The other good news is at I try to use
stalonetray that is freedesktop compliant with crystal and it work fine.
B.t.w., QJackCtl is a very good program.
--
Dominique Michel
--
N.B.: Tous les emails que je reçois sont filtrés par spamassassin avant de me
parvenir.
Le Mon, 26 Feb 2007 13:41:08 +0100,
Leonard Ritter <contact(a)leonard-ritter.com> a écrit :
Remarks due: First of all, QjackCtl just has no relation to KDE
whatsover, besides sharing the same toolkit framework (Qt3). More
importantly to your case, QjackCtl systray icon implementation is _my_
own, and is _only_ supposed to work on KDE, Gnome and on all other
freedesktop.org X11/systray icon protocol compliant desktop
environments. All other DE/WM's are thus _not_ supported and users
should avoid opting on using QjackCtl systray icon mode, due to
unpredictable behavior.
If you find QjackCtl systray behavior "unprofessional" its just because
you're forcing it to run where it was never tested nor designed to work.
Just switch the systray icon option off and you'll be fine, I hope.
Cheers, On Thu, 2007-02-22 at 06:42 -0600, Jan Depner
wrote:
> I can say that the QT package is much easier to use and has
> better documentation and support. Not that GTK is terrible, it's just
> not as polished or professional.
Just a remark about Qt GUI. It is like another OS: well looking but
foolish. I use QJackCtl on FVWM-Crystal, and when changing the recipe
(theme in FVWM-Crystal) the systray icon become weird or just disappear
because Qt/KDE implementation of the systray is compatible with nothing
else. If QJackCtl was minimized with the systray, the consequence is at I
must "killall qjackctl" and restart it in order to get in control again. It
is not what I call "professional".
8:46 a.m.
Le Wed, 28 Feb 2007 13:37:37 +0100,
Dominique Michel <dominique.michel(a)citycable.ch> a écrit :
Le Tue, 27 Feb 2007 22:19:19 +0000,
Rui Nuno Capela <rncbc(a)rncbc.org> a écrit :
I was actualy to fast with my conclusion. stalonetray is working once on ten
when I change the recipe, so I send its log to its maintainer to sort out if it
is a bug in stalonetray or qjakctl.
Dominique Michel wrote:
I don't get this problem with other programs as sylpheed-claws. No matter, I
use another workaround for this systray issue. I added a qjackctl menu in my
audio button. It have 2 options: "killall qjackctl" and "start
qjackctl".
The good news is at this problem occur only with recipe switching, so I almost
never use this qjackctl menu. The other good news is at I try to use
stalonetray that is freedesktop compliant with crystal and it work fine.
Le Mon, 26 Feb 2007 13:41:08 +0100,
Leonard Ritter <contact(a)leonard-ritter.com> a écrit :
Remarks due: First of all, QjackCtl just has no relation to KDE
whatsover, besides sharing the same toolkit framework (Qt3). More
importantly to your case, QjackCtl systray icon implementation is _my_
own, and is _only_ supposed to work on KDE, Gnome and on all other
freedesktop.org X11/systray icon protocol compliant desktop
environments. All other DE/WM's are thus _not_ supported and users
should avoid opting on using QjackCtl systray icon mode, due to
unpredictable behavior.
If you find QjackCtl systray behavior "unprofessional" its just because
you're forcing it to run where it was never tested nor designed to work.
Just switch the systray icon option off and you'll be fine, I hope.
Cheers, On Thu, 2007-02-22 at 06:42 -0600, Jan Depner
wrote:
> I can say that the QT package is much easier to use and has
> better documentation and support. Not that GTK is terrible, it's just
> not as polished or professional.
Just a remark about Qt GUI. It is like another OS: well looking but
foolish. I use QJackCtl on FVWM-Crystal, and when changing the recipe
(theme in FVWM-Crystal) the systray icon become weird or just disappear
because Qt/KDE implementation of the systray is compatible with nothing
else. If QJackCtl was minimized with the systray, the consequence is at I
must "killall qjackctl" and restart it in order to get in control again.
It is not what I call "professional".
B.t.w., QJackCtl is a very good program.
--
Dominique Michel
--
N.B.: Tous les emails que je reçois sont filtrés par spamassassin avant de me
parvenir.
5:13 a.m.
tisdag 27 februari 2007 22:13 skrev Dominique Michel:
Another problem with Qt/KDE is dcop. It work well
inside KDE but produce
more warning or error messages in the logs as useful effects on another
wm's as kde. Again, it is not what I call "professional".
That might be the case but it is on it's way out and dbus will be the
successor. If it's better or worse remains to see. But dbus is the more
widley adopted (gnome, kde....)
http://en.wikipedia.org/wiki/Dcop
http://en.wikipedia.org/wiki/D-Bus
--
- Bengan ------------------------------------------------------------
- KTHNOC - No1 Internet Offspring | http://www.noc.kth.se/~bengan ---
- 08-7906586 (ej vidarekopplat), 070-6443325 ------------------------
6:16 a.m.
Dominique Michel wrote:
Le Mon, 26 Feb 2007 13:41:08 +0100,
Another problem with Qt/KDE is dcop. It work well
inside KDE but produce more
warning or error messages in the logs as useful effects on another wm's as kde.
Again, it is not what I call "professional".
(please don't consider this as an attack on your person, it's intended
as an expression of a general feeling towards some common expectations)
Please give it all some credit...
DCOP does have advantages, and though it has some issues, it does do the
job. It's been around for a while, and newer & better (hopefully) is
coming. AFAIK it was rather high-tech back when it was introduced.
Qt is a really nice toolkit, and though it also has it disadvantages, I
found it very clean when compared to some others (personal opinion). I
have to admit that it has been a while since I've looked at the
'professional' MFC, but back then I certainly preferred QT. (haven't
looked back since).
I personally have an issue with this "professional" requirement,
especially if it is about these 'details'. If you want "professional"
stuff, pay for it (and see if you get it). This is not a plea for
unprofessionality on our side at all. I personally try and be as
professional as possible for my code. I am not a 'professional'
programmer, in the first place because I'm not paid for it, and in the
second place because I get paid for doing something else than programming.
Eliminating the warning messages from DCOP/KDE won't be that hard, so
you could do it yourself if they bother you. You have the source.
And how about the "professionalism" of FVWM: why doesn't it seem to
support the freedesktop system tray spec correctly? that would solve
your problem with QJackCtl, and many other programs. Note that it could
equally well be an issue with Rui's implementation, but don't call that
unprofessional. Call it a bug.
What I'm trying to say here is that when using free/OSS software, you
have a choice, and with that choice you have to take the consequences.
You win some, you lose some, and in the end I think you win more than
you lose. And for the area's you lose on, you have the opportunity (i.e.
source code) to cut your losses.
What I'm not trying to say is that you shouldn't indicate problems with
certain programs or general issues. Just don't make this an issue of
"professionalism". There are plenty of arguments to say that the only
thing professional about windows is that it is a million dollar
business. If you compare some Linux stuff to the stuff created by some
'professionals' I certainly conclude that these pro's should be ashamed.
I do agree on the fact that Linux software does seem to have troubles
with 'the last mile'. Probably because it is often the least interesting
part, and is often considered as lower priority than implementing that
other missing functionality (I'd call this the version 0.99.754
phenomenon). You could call that 'unprofessional' if you wanted to...
Greets,
Pieter
8:49 a.m.
On Wed, 2007-02-28 at 11:14 +0100, Pieter Palmers wrote:
I personally have an issue with this
"professional" requirement,
especially if it is about these 'details'.
on a sidenote, when approaching the "what is professional" discussion, i
like to tell about the coincidence that in german, another word for
prostitutes is "die professionellen" - and i find this to be interesting
on multiple levels.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
6260
days inactive
6263
days old
linux-audio-dev@lists.linuxaudio.org
36 comments
19 participants
participants (19)
-
Bengt Gördén -
Camilo Polyméris -
Chris Cannam -
Dave Phillips -
Dominique Michel -
Eric Dantan Rzewnicki -
Frank Smith -
Gene Heskett -
James McDermott -
Jens M Andreasen -
Leonard Ritter -
Loki Davison -
Pau Arumi -
Pieter Palmers -
Rui Nuno Capela -
Stephen Sinclair -
Steve Harris -
Thorsten Wilms -
torbenh＠gmx.de