28 Jan
2006
28 Jan
'06
1:45 a.m.
Reuben Martin:
No no, you misunderstand. I said "spawning of a gui process" (I should
rather have said "spawning off a gui process", but I didn't. :-) ).
Well, I guess the question was more retorical. I personally think reason
is that linux programmers aren't that much into bells and whistles as
windows programmers.
(Why
hasn't anyone made a ladspa plugin with a GUI by the way? Its
really simple just spawning of a gui process program.)
Because you have no way of knowing if the platform you are running it
on will have support for the toolkit needed by the GUI.
It would be
nice to append the LADSPA spec to allow for a simple markup language
to describe the GUI, and then depend on the host to render that markup
language into a GUI. It would make it toolkit independent.
No, that would not be nice at all. Far too complicated for the hosts, and
guis would be different from host to host, and limited by the markup
language
What would be nice was if we used a common gui-designer like qdesigner
or glade, so that someone could make an automatic gui-spawner library
that used the xml-files from qdesigner or glade to make guis. That way,
anyone could make/edit gui's quite easely. The idea was proposed some
years ago, but no one has picked it up. Its not much work to do, but I
guess no one has got the time. It must be a community project as well,
because it would be useless if no one bothered to make guis for the
various plug-ins or the hosts didn't support it. (well, the host-problem
could be fixed automatically by making a wrapper ladspa plugin, but its
not the ideal solution)
28 Jan
28 Jan
2:57 a.m.
Kjetil S. Matheussen wrote:
Reuben Martin:
No no, you misunderstand. I said "spawning of a gui process" (I should
rather have said "spawning off a gui process", but I didn't. :-) ).
Well, I guess the question was more retorical. I personally think
reason is that linux programmers aren't that much into bells and
whistles as windows programmers.
That sounds very interesting. I'm just now getting into talking with
profs on my campus about GUI development. Mainly, I'm inexperienced, but
more than willing to learn how to do stuff. I'll finish my last
programming class (the most advanced available at this university...
which actually isn't all that advanced) this semester, so rather than
let the info rot from want of use, I want to play with creating stuff
like GUI's. I'll chat with them about this then, and see if we could
work something out. It'd be interesting to see what they say about the
difficulty. I like the idea, and as you said... it would be rather well
used. *shrug* We'll see. Any suggestions on a language I would want to
put forth for this (RUBY, Python, etc.). And thanks for the idea.
~J
P.S. I'm also from the windows crowd, but I used FLStudio. Mainly
because I just can't find the time to learn CSound yet. I'm dead in love
with algorithms, so if anyone has any cool sites on methods of
programming synths in CSound, I wouldn't mind at all you sharing it with
me. That said, I do google a good bit, so no worries if it's something
that's easy to search for. Otherwise, I'd love to see what you people
could throw at me.
(Why
hasn't anyone made a ladspa plugin with a GUI by the way? Its
really simple just spawning of a gui process program.)
Because you have no way of knowing if the platform you are running it
on will have support for the toolkit needed by
the GUI. It would be
nice to append the LADSPA spec to allow for a simple markup language
to describe the GUI, and then depend on the host to render that markup
language into a GUI. It would make it toolkit independent.
No, that would not be nice at all. Far too complicated for the hosts,
and guis would be different from host to host, and limited by the
markup language
What would be nice was if we used a common gui-designer like qdesigner
or glade, so that someone could make an automatic gui-spawner library
that used the xml-files from qdesigner or glade to make guis. That way,
anyone could make/edit gui's quite easely. The idea was proposed some
years ago, but no one has picked it up. Its not much work to do, but I
guess no one has got the time. It must be a community project as well,
because it would be useless if no one bothered to make guis for the
various plug-ins or the hosts didn't support it. (well, the
host-problem could be fixed automatically by making a wrapper ladspa
plugin, but its not the ideal solution)
6:03 a.m.
New subject: [linux-audio-dev] Ladspa GUIs (Was Re: [linux-audio-user] Acid type program
On Fri, Jan 27, 2006 at 09:45:35 -0800, Kjetil S. Matheussen wrote:
That is certainly true.
...
I did consider that quite hard, but its really hard to come up with a 90%
solution that is even vaguely practical, and doesn't limit implementation
choices too much.
The DSSI solution is quite neat because using only glade (or the Qt
equivalent), an OSC library and a tiny bit of glue code you can build a
GUI. For the kind of simple UIs youre talking about the glue code could be
autogenerated. Also, the impact on the host is minimal.
- Steve
Reuben Martin:
>>(Why hasn't anyone made a ladspa plugin with a GUI by the way? Its
>>really simple just spawning of a gui process program.)
They have, it can be done via the DSSI API.
Because you
have no way of knowing if the platform you are running it
No no, you misunderstand. I said "spawning of a gui process" (I should
rather have said "spawning off a gui process", but I didn't. :-) ).
Well, I guess the question was more retorical. I personally think reason
is that linux programmers aren't that much into bells and whistles as
windows programmers. on will have
support for the toolkit needed by the GUI. It would be
nice to append the LADSPA spec to allow for a simple markup language
to describe the GUI, and then depend on the host to render that markup
language into a GUI. It would make it toolkit independent.
No, that would not be nice at all. Far too complicated for the hosts, and
guis would be different from host to host, and limited by the markup
language
What would be nice was if we used a common gui-designer like qdesigner
or glade, so that someone could make an automatic gui-spawner library
that used the xml-files from qdesigner or glade to make guis. That way, 
11:16 a.m.
Many winblows pt/nuendo/sonar users would be turned on by a little more
ladspa eye-candy... more attention is a good thing.........
Reuben Martin:
No no, you misunderstand. I said "spawning of a gui process" (I should
rather have said "spawning off a gui process", but I didn't. :-) ).
Well, I guess the question was more retorical. I personally think reason
is that linux programmers aren't that much into bells and whistles as
windows programmers.
--
Timothy Alan Gorman
Petr-all Petroleum
6567 kinne rd dewitt ny 13214
cell 315 415 8108
office 315 446 0125 x 126
(Why
hasn't anyone made a ladspa plugin with a GUI by the way? Its
really simple just spawning of a gui process program.)
Because you have no way of knowing if the platform you are running it
on will have support for the toolkit needed by the
GUI. It would be
nice to append the LADSPA spec to allow for a simple markup language
to describe the GUI, and then depend on the host to render that markup
language into a GUI. It would make it toolkit independent.
No, that would not be nice at all. Far too complicated for the hosts, and
guis would be different from host to host, and limited by the markup
language
What would be nice was if we used a common gui-designer like qdesigner
or glade, so that someone could make an automatic gui-spawner library
that used the xml-files from qdesigner or glade to make guis. That way,
anyone could make/edit gui's quite easely. The idea was proposed some
years ago, but no one has picked it up. Its not much work to do, but I
guess no one has got the time. It must be a community project as well,
because it would be useless if no one bothered to make guis for the
various plug-ins or the hosts didn't support it. (well, the host-problem
could be fixed automatically by making a wrapper ladspa plugin, but its
not the ideal solution)
1:48 p.m.
On Sat January 28 2006 10:01, timg(a)expressmart.com wrote:
Many winblows pt/nuendo/sonar users would be turned on
by a
little more ladspa eye-candy... more attention is a good
thing.........
I've been thinking for a couple years now that something similar
to what other people have suggested (some kind of markup
associated with the plugin, describing a UI) is the way to go,
but leave it to the host app (or the wrapper, or whatever) to
implement the controls since LADSPA is unidirectional.
Of course, that makes it harder to fully support LADSPA so it may
be self-defeating.
Rob
2:54 p.m.
timg(a)expressmart.com escribe:
Many winblows pt/nuendo/sonar users would be turned on
by a little more
ladspa eye-candy... more attention is a good thing.........
PT eye-candy? It must have changed a lot... :o)
Cordially, Ismael
--
Tout fourmille de commentaries, d'auteurs il en est grande chert�
http://lamediahostia.blogspot.com/
http://www.flickr.com/photos/ivalladt/
3:35 p.m.
I suppose that the plugins are more of what I'm talking about.
timg(a)expressmart.com escribe:
--
Timothy Alan Gorman
Petr-all Petroleum
6567 kinne rd dewitt ny 13214
cell 315 415 8108
office 315 446 0125 x 126
Many winblows pt/nuendo/sonar users would be
turned on by a little more
ladspa eye-candy... more attention is a good thing.........
PT eye-candy? It must have changed a lot... :o)
Cordially, Ismael
--
Tout fourmille de commentaries, d'auteurs il en est grande cherté
http://lamediahostia.blogspot.com/
http://www.flickr.com/photos/ivalladt/
4:23 p.m.
On Sat January 28 2006 14:21, timg(a)expressmart.com wrote:
I suppose that the plugins are more of what I'm
talking about.
The weird, non-standard GUIs of VST plugins have always been a
pet peeve of mine. They're always either emulative of a
physical piece of equipment (which without the tactile feedback
and instant response is useless) or look like they've been
designed by a 12-year-old boy doing UI design for the first
time, or most often both.
I want my interfaces to use standard widgets so that my own
choice of desktop themes, accessibility factors, my scroll
wheel, etc. apply to them and not someone's weird bitmapped idea
of what a synth or reverb control panel is supposed to look
like.
Rob
4:38 p.m.
Rob wrote:
On Sat January 28 2006 14:21, timg(a)expressmart.com
wrote:
Oh Yes please!!!!!
Standards ??
Don't we all have one each!
cheers
Bob
I suppose that the plugins are more of what
I'm talking about.
The weird, non-standard GUIs of VST plugins have always been a
pet peeve of mine. They're always either emulative of a
physical piece of equipment (which without the tactile feedback
and instant response is useless) or look like they've been
designed by a 12-year-old boy doing UI design for the first
time, or most often both.
I want my interfaces to use standard widgets so that my own
choice of desktop themes, accessibility factors, my scroll
wheel, etc. apply to them and not someone's weird bitmapped idea
of what a synth or reverb control panel is supposed to look
like.
Rob
29 Jan
29 Jan
3:20 a.m.
I suppose that after me sitting infront of a linux console all
day at the office it's just nice to see a little color on the screen....
...or perhaps it the feeling that I'm really tweeking a knob or two....
That's not a bad thing to me.
Rob wrote:
--
Timothy Alan Gorman
Petr-all Petroleum
6567 kinne rd dewitt ny 13214
cell 315 415 8108
office 315 446 0125 x 126
On Sat January 28 2006 14:21, timg(a)expressmart.com
wrote:
Oh Yes please!!!!!
Standards ??
Don't we all have one each!
cheers
Bob
I suppose that the plugins are more of what
I'm talking about.
The weird, non-standard GUIs of VST plugins have always been a
pet peeve of mine. They're always either emulative of a
physical piece of equipment (which without the tactile feedback
and instant response is useless) or look like they've been
designed by a 12-year-old boy doing UI design for the first
time, or most often both.
I want my interfaces to use standard widgets so that my own
choice of desktop themes, accessibility factors, my scroll
wheel, etc. apply to them and not someone's weird bitmapped idea
of what a synth or reverb control panel is supposed to look
like.
Rob
3:32 a.m.
On Sun January 29 2006 02:05, timg(a)expressmart.com wrote:
...or perhaps it the feeling that I'm really
tweeking a knob
or two....
See, I have knobs on my MIDI controller.... none of which can be
used to tweak the fake knobs on VST's or VSTi's as far as I
know, despite their use of standard MIDI events. I love
tweaking knobs and sliders and stuff.... just not with my mouse,
especially since then you can only tweak one at a time.
I'd love for a paradigm like Ardour's to get standardized
somehow.... where a whole bunch of keys become essentially mouse
buttons so you can quickly adjust "sliders" and "knobs", or gang
them if that's what you want to do.
Interfaces where the "knobs" and "sliders" are just eye candy,
though.... where you can't resize or maximize the window, where
the standard keyboard shortcuts (e.g. tab, space for button
presses, etc.) don't exist, where even the fonts are bitmapped
so you can't blow them up by changing your system fonts....
belong back in 1993 when they were an improvement over the
status quo, or at least no worse.
Rob
8:18 a.m.
On Sunday 29 January 2006 07:27, Rob was like:
On Sun January 29 2006 02:05, timg(a)expressmart.com
wrote:
Using a mouse for all this really isn't good enough for serious work. Hardware
knobs, sliders, push buttons, drum pads and MIDI keyboards are all fairly
standard kit these days. These ideally would be dealt with on an OS level
rather than having different implementations for every application. This
surely is the Linux way of doing things?
...or perhaps it the feeling that I'm really
tweeking a knob
or two....
See, I have knobs on my MIDI controller.... none of which can be
used to tweak the fake knobs on VST's or VSTi's as far as I
know, despite their use of standard MIDI events. I love
tweaking knobs and sliders and stuff.... just not with my mouse,
especially since then you can only tweak one at a time. I'd love for a paradigm like Ardour's to get
standardized
somehow.... where a whole bunch of keys become essentially mouse
buttons so you can quickly adjust "sliders" and "knobs", or gang
them if that's what you want to do.
Oh good, I'm glad someone has mentioned Ardour in this conversation, and what
about the way Hydrogen does it? One is GTK and the other QT based.
Standardise this approach for all apps and provide a straightforward way of
mapping controllers to hardware sliders/keys. Surely this is the way to go.
Eye candy MUST be functional (otherwise it causes truth decay ;) The last
thing I'd want to see is a whole load of varied interfaces where the visual
impression overrides the functionality.
Interfaces where the "knobs" and
"sliders" are just eye candy,
though.... where you can't resize or maximize the window, where
the standard keyboard shortcuts (e.g. tab, space for button
presses, etc.) don't exist, where even the fonts are bitmapped
so you can't blow them up by changing your system fonts....
belong back in 1993 when they were an improvement over the
status quo, or at least no worse.
Aye.
--
cheers,
tim hall
http://glastonburymusic.org.uk/tim
6902
days inactive
6903
days old
linux-audio-user@lists.linuxaudio.org
11 comments
8 participants
participants (8)
-
Ismael Valladolid Torres -
Jeremy White -
Kjetil S. Matheussen -
Rob -
Steve Harris -
studio64 -
tim hall -
timg＠expressmart.com