16 Jan
2004
16 Jan
'04
12:21 p.m.
Hello.
NMEdit was mentioned in my list. I'm in their devel list but
it has been quite quiet.
I will check Graphviz better in a few days but can one make
Quasimodo or Nord Modular type "graphs" with it? In a quick
look I saw some composite icons (not widgets?), but I feel
Graphviz is not very usable for us.
-*-
Both the standalone editor and the embedded editor would be needed.
Standalone editor could use sockets and shared memory for communicating
between the editor and application. Embedded editor could be launch
by filling in a callback table and calling the editor:
GtkWidget *editor;
editor = editor_create(callbacktable);
gtk_widget_show(editor);
It could be slightly more complex if GTK is not the only supported
toolkit. We also could have editor_menu_create() if one wants
attach the editor related menu to application's menubar.
-*-
Should we provide a standard (XML script?) for building module
interfaces? New GUI widgets would be included as soon as somebody
writes them. This kind of approach would be needed in creating
plugin GUIs and environments (a la Logic Audio).
Should we allow module author to code the GUI for the module using
directly GTK?
How GMPI handles the plugin GUIs? I see that we would do an overlapping
work here.
-*-
Assume I have written a module GUI with GTK. I load the calling
function to the editor and create the GUI with
modulewidget = mymodule_create_gui();
gtk_widget_show(modulewidget);
Now, can I trace the whole widget hierarchy starting from "modulewidget"?
In GTK, can one attach names to the widgets? E.g., I have a small
pixmap of a connector where a cable is plugged in. I want name all
these widgets as "connector". Then in the editor I would search all
connectors by tracing the widget hierarchy and looking for "connector"
names.
We need to know where these connectors are located because we want be
able to plug the cables in. Alternatively we could describe the
locations in a file, but then we would be bound to the fixed shape GUIs.
-*-
In gtk related mailing lists I have already suggested a general way
how to implement a zoom in the editor (Widget Portal). If that is not
possible in GTK, then I see no other way than write new widgets with
a zoom ability.
Regards,
Juhana
16 Jan
16 Jan
4:53 p.m.
Hi,
IMHO, think less about GTK and more about designing a language that can
be used to describe the GUI of a modular synthesizer. Why not for
example use XML or LISP or some other notation not being C. Then use
C+GTK to implement the new language.
Features to consider for the language:
* A widget set particularly designed for synthesizers.
* A way to construct modules from widgets.
* Cable and port types/coloring.
* Canvas grid that modules snap to.
* How user events are sent to the backend.
* How backend events update the GUI.
* Reusability of widget declarations.
Marcus
Juhana Sadeharju wrote:
Hello.
NMEdit was mentioned in my list. I'm in their devel list but
it has been quite quiet.
I will check Graphviz better in a few days but can one make
Quasimodo or Nord Modular type "graphs" with it? In a quick
look I saw some composite icons (not widgets?), but I feel
Graphviz is not very usable for us.
-*-
Both the standalone editor and the embedded editor would be needed.
Standalone editor could use sockets and shared memory for communicating
between the editor and application. Embedded editor could be launch
by filling in a callback table and calling the editor:
GtkWidget *editor;
editor = editor_create(callbacktable);
gtk_widget_show(editor);
It could be slightly more complex if GTK is not the only supported
toolkit. We also could have editor_menu_create() if one wants
attach the editor related menu to application's menubar.
-*-
Should we provide a standard (XML script?) for building module
interfaces? New GUI widgets would be included as soon as somebody
writes them. This kind of approach would be needed in creating
plugin GUIs and environments (a la Logic Audio).
Should we allow module author to code the GUI for the module using
directly GTK?
How GMPI handles the plugin GUIs? I see that we would do an overlapping
work here.
-*-
Assume I have written a module GUI with GTK. I load the calling
function to the editor and create the GUI with
modulewidget = mymodule_create_gui();
gtk_widget_show(modulewidget);
Now, can I trace the whole widget hierarchy starting from "modulewidget"?
In GTK, can one attach names to the widgets? E.g., I have a small
pixmap of a connector where a cable is plugged in. I want name all
these widgets as "connector". Then in the editor I would search all
connectors by tracing the widget hierarchy and looking for "connector"
names.
We need to know where these connectors are located because we want be
able to plug the cables in. Alternatively we could describe the
locations in a file, but then we would be bound to the fixed shape GUIs.
-*-
In gtk related mailing lists I have already suggested a general way
how to implement a zoom in the editor (Widget Portal). If that is not
possible in GTK, then I see no other way than write new widgets with
a zoom ability.
Regards,
Juhana
17 Jan
17 Jan
5:55 a.m.
On Fri, Jan 16, 2004 at 10:49:48 +0100, Marcus Andersson wrote:
Hi,
IMHO, think less about GTK and more about designing a language that can
be used to describe the GUI of a modular synthesizer. Why not for
example use XML or LISP or some other notation not being C. Then use
C+GTK to implement the new language.
Features to consider for the language:
* A widget set particularly designed for synthesizers.
* A way to construct modules from widgets.
* Cable and port types/coloring.
* Canvas grid that modules snap to.
* How user events are sent to the backend.
* How backend events update the GUI.
* Reusability of widget declarations.
Yes, yes, yes. Personally I would be very temped to do the rendering with
OpenGL, you have to do a bit more work yourself, but if you start with
something like GTK you will do a lot of overrinding and defining your own
behaviours anyway.
A system like this for describing plugin GUIs using XML, PNGs and OpenGL
(but extensible in C + OpenGL) is on my list of future projects, but
wether it will ever get to the top is another matter. The general lack of
interest in linux UIs, and lack of skilled graphic designers with time to
spare is a bit of a problem.
One potential problem with OpenGL is that people without working hardware
acceleration will find it sluggish, I havent experimented to find out how
bad it will be. For hardware accelerated systems the reduction in CPU
load and memory bandwidth is impressive, and significant for DSP heavy
systems. It has other fringe benfits too, like cheap but nice looking UI
zooming and thumbnailing and platform independence.
- Steve
6:17 a.m.
On Sat, 17 Jan 2004 10:52:18 +0000, Steve Harris wrote
On Fri, Jan 16, 2004 at 10:49:48 +0100, Marcus
Andersson wrote:
I don't know it, and it's not opengl, but would something based on XUL work?
They've probably done most of the hard work already.
Hi,
IMHO, think less about GTK and more about designing a language that can
be used to describe the GUI of a modular synthesizer. Why not for
example use XML or LISP or some other notation not being C. Then use
C+GTK to implement the new language.
Features to consider for the language:
* A widget set particularly designed for synthesizers.
* A way to construct modules from widgets.
* Cable and port types/coloring.
* Canvas grid that modules snap to.
* How user events are sent to the backend.
* How backend events update the GUI.
* Reusability of widget declarations.
Yes, yes, yes. Personally I would be very temped to do the rendering
with OpenGL, you have to do a bit more work yourself, but if you
start with something like GTK you will do a lot of overrinding and
defining your own behaviours anyway.
A system like this for describing plugin GUIs using XML, PNGs and OpenGL
(but extensible in C + OpenGL) is on my list of future projects, but
wether it will ever get to the top is another matter. The general
lack of interest in linux UIs, and lack of skilled graphic designers
with time to spare is a bit of a problem. One potential problem with OpenGL is that people
without working hardware
acceleration will find it sluggish, I havent experimented to find
out how bad it will be. For hardware accelerated systems the
reduction in CPU load and memory bandwidth is impressive, and
significant for DSP heavy systems. It has other fringe benfits too,
like cheap but nice looking UI zooming and thumbnailing and
platform independence.
I'm currently working on an opengl user interface for a game I'm writing. Once
you get a scenegraph set up (so child widgets inherit parent transforms etc)
it's not too hard to get something working.
Large applications like houdini use opengl based interfaces to great effect:
http://www.linuxjournal.com/modules/NS-lj-issues/issue66/3522f3.gif
dave
................................. www.pawfal.org/nebogeo
6:42 a.m.
On Sat, Jan 17, 2004 at 12:13:42 +0100, Dave Griffiths wrote:
It would work, XUL + ECMAScript is quite a powerful environment (I've built
some significant apps in it), but it only really makes text based widgets
easy to manipulate, and its sloooow.
A system like
this for describing plugin GUIs using XML, PNGs and OpenGL
(but extensible in C + OpenGL) is on my list of future projects, but
wether it will ever get to the top is another matter. The general
lack of interest in linux UIs, and lack of skilled graphic designers
with time to spare is a bit of a problem.
I don't know it, and it's not opengl, but would something based on XUL work?
They've probably done most of the hard work already. I'm currently working on an opengl user interface
for a game I'm writing. Once
you get a scenegraph set up (so child widgets inherit parent transforms etc)
it's not too hard to get something working.
Agreed. I'm half ported meterbridge to OpenGL and the code is actually
simpler (and /much/ faster, even on my ageing laptop) than the native SDL
drawing code.
I wouldnt want to use OpenGL if you had a lot of things like scrolling
text panes, but plugin UIs are mostly sliders, meters and graph displays
which are all easy to do in OpenGL + pixmaps.
- Steve
9:35 a.m.
Hallo,
Steve Harris hat gesagt: // Steve Harris wrote:
The [...] lack of skilled graphic designers with time
to spare is a
bit of a problem.
I'm not sure if that indeed is a problem. One thing I like in Pd and
similar systems including Gem is, that it allows users to create their
own GUI from very simple building blocks: a square, a line, a
circle... You don't need graphic wizards to design a square. ;)
I'm thinking of things like this here:
http://www.crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s9
where this GUI is explained:
http://www.crca.ucsd.edu/~msp/Pd_documentation/fig9.1.jpg
But I agree: this is highly experimental and probably not *that*
useful for a general modular editor.
ciao
--
Frank Barknecht _ ______footils.org__
11:22 a.m.
On Sat, Jan 17, 2004 at 03:32:05 +0100, Frank Barknecht wrote:
Hallo,
Steve Harris hat gesagt: // Steve Harris wrote:
True enough :) but I think it takes a reasonable ammount of talent to make
really intuative and compact UIs (screen realestate is an issue) even if
if doesnt have a photorealistic interface. Theres a loopbased performace
instrument that I think is a really good example (I cant remeber its
name), it only uses geometric 2-tone widgets, but its got an easy to use
interface and is well disigned. Personally, I dont have design skills
anywhere near that good, and I havent seen anything as good from other LAD
developers.
- Steve
The [...] lack of skilled graphic designers with
time to spare is a
bit of a problem.
I'm not sure if that indeed is a problem. One thing I like in Pd and
similar systems including Gem is, that it allows users to create their
own GUI from very simple building blocks: a square, a line, a
circle... You don't need graphic wizards to design a square. ;)
12:33 p.m.
Hallo,
Steve Harris hat gesagt: // Steve Harris wrote:
True enough :) but I think it takes a reasonable
ammount of talent to make
really intuative and compact UIs (screen realestate is an issue) even if
if doesnt have a photorealistic interface. Theres a loopbased performace
instrument that I think is a really good example (I cant remeber its
name),
Ableton Live, maybe? It has a exceptionally well thought out
interface, IMO.
it only uses geometric 2-tone widgets, but its got an
easy to use
interface and is well disigned. Personally, I dont have design skills
anywhere near that good, and I havent seen anything as good from other LAD
developers.
I also prefer the people who studied design somehow to do design work.
Regarding OpenGL: Although this could be a nice API for doing all
kinds of interfaces, the hardware side on Linux is looking
increasingly worse because of the XFree86 peoples' decision to go
modular and allow closed source drivers for DRI. Now we're in a
situation, where only old chipsets like Matrox G550 or incapable ones
like the Intel graphics chips have open source Open GL drivers. Nvidia
OTOH does provide decent drivers but they are closed source and
reportedly also could have a bad impact on audio performance. Even
most newer ATI cards don't have open source OpenGL drivers anymore,
although there are efforts to write some.
All this is really a problem to be considered when deciding to base a
GUI on Open GL. In most (audio) cases a 2D-interface would suffice,
I'm sure.
ciao
--
Frank Barknecht _ ______footils.org__
4:09 p.m.
On Sat, Jan 17, 2004 at 06:29:46PM +0100, Frank Barknecht wrote:
Hallo,
Steve Harris hat gesagt: // Steve Harris wrote:
Yes, that's it.
True enough :) but I think it takes a reasonable
ammount of talent to make
really intuative and compact UIs (screen realestate is an issue) even if
if doesnt have a photorealistic interface. Theres a loopbased performace
instrument that I think is a really good example (I cant remeber its
name),
Ableton Live, maybe? It has a exceptionally well thought out
interface, IMO. Regarding OpenGL: Although this could be a nice API
for doing all
kinds of interfaces, the hardware side on Linux is looking
increasingly worse because of the XFree86 peoples' decision to go
modular and allow closed source drivers for DRI. Now we're in a
situation, where only old chipsets like Matrox G550 or incapable ones
like the Intel graphics chips have open source Open GL drivers. Nvidia
OTOH does provide decent drivers but they are closed source and
reportedly also could have a bad impact on audio performance. Even
most newer ATI cards don't have open source OpenGL drivers anymore,
although there are efforts to write some.
I think the "one step down from top of the range" ATI cards are
supported, and the NVIDIA drivers dont have any impact on latency, though
the are partly binary, yes.
All this is really a problem to be considered when
deciding to base a
GUI on Open GL. In most (audio) cases a 2D-interface would suffice,
I'm sure.
Thge UI is 2D (you turn off perspective before you draw), its just a way
of loading all the images and stuff onto the card, and making it do the
drawing maths. It saves a /lot/ of cpu. Its more-or-less how the latest
OSX GUI code works, and its very efficient.
- Steve
7:35 p.m.
On Sat, Jan 17, 2004 at 09:06:06PM +0000, Steve Harris wrote:
Thge UI is 2D (you turn off perspective before you draw), its just a
way of loading all the images and stuff onto the card, and making it
do the drawing maths. It saves a /lot/ of cpu. Its more-or-less how
the latest OSX GUI code works, and its very efficient.
In a recent interview, Linus was quoted as saying this is where X
itself is heading. I'm very curious about what he meant more
specifically and if there is beta code available; generic 2D OpenGL
rendering of the whole GUI would be immensely nice.
http://www.linuxworld.com.au/index.php?id=568003838&fp=16&fpid=0
Jesper
11:47 a.m.
On Saturday 17 January 2004 04:52 am, Steve Harris wrote:
Yes, yes, yes. Personally I would be very temped to do
the rendering with
OpenGL, you have to do a bit more work yourself, but if you start with
something like GTK you will do a lot of overrinding and defining your own
behaviours anyway.
[...]
One potential problem with OpenGL is that people
without working hardware
acceleration will find it sluggish, I havent experimented to find out how
bad it will be. For hardware accelerated systems the reduction in CPU
load and memory bandwidth is impressive, and significant for DSP heavy
systems. It has other fringe benfits too, like cheap but nice looking UI
zooming and thumbnailing and platform independence.
"People without working hardware acceleration" includes anyone using more
than one monitor. X refuses to allow hardware acceleration with Xinerama.
Since multiple monitors are central to my working style (and that of many
recording studios), using OpenGL could have serious drawbacks.
|)
|)enji
11:56 a.m.
On Sat, Jan 17, 2004 at 10:45:25 -0600, Benjamin Flaming wrote:
"People without working hardware
acceleration" includes anyone using more
than one monitor. X refuses to allow hardware acceleration with Xinerama.
Since multiple monitors are central to my working style (and that of many
recording studios), using OpenGL could have serious drawbacks.
Yes, thats a serious problem. Any idea if XFree plan to fix that?
- Steve
19 Jan
19 Jan
4:52 a.m.
On Fri, Jan 16, 2004 at 07:18:00PM +0200, Juhana Sadeharju wrote:
Hello.
NMEdit was mentioned in my list. I'm in their devel list but
it has been quite quiet.
I will check Graphviz better in a few days but can one make
Quasimodo or Nord Modular type "graphs" with it? In a quick
look I saw some composite icons (not widgets?), but I feel
Graphviz is not very usable for us.
The discussions go a little astray i think.
can you describe a little more what you are trying to accomplish ?
too me it looks like you want to do a graph editor, because the current
modulars (ams, ssm, gAlan) have crap graph editors.
it looks like you want to go the controls are in the graph way, so
that graph components come with their own control widgets.
i would use libgnomecanvas (does not depend on gnome anymore)
and then every module would export a canvas Item....
the only problem would be determining widget size when you add a widget
to the canvas. gtk behaves sort of strange there.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
7770
days inactive
7773
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
9 participants
participants (9)
-
Benjamin Flaming -
Dave Griffiths -
Frank Barknecht -
Jesper Anderson -
Juhana Sadeharju -
Marcus Andersson -
Steve Harris -
torbenh＠gmx.de -
Vincent Touquet