8 Jun
2004
8 Jun
'04
1:24 p.m.
Hey, I wouldn't mind working on the graphics, I just don't know where to start or
who else is working on it.
Jan
On Tue, 8 Jun 2004 09:18 , Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> sent:
On Tue, Jun 08, 2004 at 11:45:53 +0200, Marek Peteraj
wrote:
VST plugins tend to be rather complex, offering
tons of features and
eyecandish GUIs, while LADSPAs usually offer limited functionality, no
GUI at all(hosts usually provide simple ones to control the parameters).
But what's interesting is that each LADSPA plugin usually implements
exactly one type of DSP technique, for example, an oscillator, or a
delay. This basically leads to a situation where a certain DSP technique
is 'isolated' in a separate plugin.
I think thats down to two factors (and its not a good thing)
1) LADSPA developers are few in number and short in time. The basics are a
good place to start.
2) The lack of a UI standard makes complex plugins a bit pointless.
There are a few counter examples (e.g. my VyNil plugin wraps a lot of
different bits), and infact if you look in many LADSPA plugins you will
see theres really more going on than there appears to be.
[OT] - my canned plugin writing experience - all generalisations and IMHO
of course
Time breakdown: 10% writing code, 10% maths and optimising, 80% tweaking
and tuning.
Mapping the controls 1:1 with DSP parameters makes plugins crap - people
say they want that if you ask them, but they dont mean it ;)
Fewer controls is better.
Affordance, appearance and usability has as much affect on the perceived
sound quality as the DSP code (posivly and negativly). Some of this can
be achieved without a custom UI.
You mentioned JAMin - true that does use LADSPA plugins - but of the total
ammount of code the LADSPA plugins are a tiny fraction. I just reused them
because I hate fixing bugs in two places :)
[OOT] I used to think that a UI spec for LADSPA (to make it competetive
with VST) was a technological problem. I now thinks its a manpower issue
(I think Paul Davis pointed this out a couple of years ago :). Games
develpment has moved to the point where the graphics work is more
expensive than the software development, and I bet its not far off in
plugin / eyecandy app development. We have no, or almost no, graphics
people here.
There are plenty of graphics people working on Free Software projects, but
they all seem to be working on games projects. What a waste. I guess
drawing goblins is more fun than sliders and LEDs. Who knew? ;)
8 Jun
8 Jun
2:45 p.m.
New subject: [linux-audio-dev] Is ladspa actually la-dsp-a? Is JACK the ultimate solution?
On Tue, Jun 08, 2004 at 08:03:39 -0700, eviltwin69(a)cableone.net wrote:
Hey, I wouldn't mind working on the graphics, I
just don't know where to start or
who else is working on it.
Ah, well, thats back to problem A, the technical problem. ;)
I lent the DSSI specification (http://dssi.sourceforge.net/) towards
something that would be applicable to LADSPA too if its successful, but
noones implemnted it in a real LADSPA host yet, so it not useful for
LADSPA.
There have been a few attempts at LADSPA GUI specs in the past, but
they've all been missing that elusive something, and support.
- Steve
4:16 p.m.
New subject: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Tue, Jun 08, 2004 at 05:36:41PM +0100, Steve Harris wrote:
There have been a few attempts at LADSPA GUI specs in
the past, but
they've all been missing that elusive something, and support.
is it possible to summarise the objections to the dssi approach
for ladspa? Its difficult to get an overview from the archives, but
this did seem to be the favourite.
on the surface it looks like a good solution
(gui as separate app, gui -> plugin-host ipc via osclite).
It could free graphic artists to use the tools they are comfortable
with, which is a prerequisite for the emergence of nice gui's.
--
Tim Orford
5:18 p.m.
New subject: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Tuesday 08 Jun 2004 6:59 pm, Tim Orford wrote:
is it possible to summarise the objections to the dssi
approach
for ladspa?
One objection is that it completely avoids addressing the problem of
how to embed the GUI inside the host on-screen. Each GUI is
basically assumed to run up as a separate top-level window.
I could imagine some library support for re-parenting GUIs, but it
certainly isn't intrinsic to the current proposal. The problem is
exacerbated by the fact that GUIs that are most comfortable running
in entirely separate windows are likely to be the more complex ones
that are perhaps less amenable to being hosted plugins in the first
place -- if the GUI can happily run standalone, there's a stronger
argument for making the entire "plugin" a standalone JACK app.
(The upside of this, of course, is that if the GUI crashes it won't
bring down the host. Since the GUI is often the most unstable bit of
a plugin, that could be a very good thing.)
A further conceptual criticism is that it will just encourage people
to produce GUIs that are inconsistent, inelegant, tasteless and hard
to use -- i.e. it doesn't do anything to address the biggest problems
a plugin author might face when writing a GUI, namely what to build
the GUI from and how to design and organise it. A separate library
to help with that by wrapping basic toolkit widgets in forms likely
to be of use to audio plugins might be worth considering.
An implementation disadvantage is the need to produce two separate
object files (the .so and the GUI), to ensure that they can both be
discovered by the host, and to keep them in sync -- for example to
make sure the GUI knows about the most up-to-date set of plugin
ports. Of course the GUI can always load the plugin and query it
itself, but most probably wouldn't want to do that.
Chris
5:43 p.m.
New subject: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Tue, 2004-06-08 at 15:26, Chris Cannam wrote:
On Tuesday 08 Jun 2004 6:59 pm, Tim Orford wrote:
Maybe it's just me personally, but I don't see much of a problem with
this. I think of ams, where the modules themselves are just shown as,
er, little boxes with ports, but you can click 'em to get the gui and
change all the parameters. Ardour is the same way.
All we need IMHO is a way to have that parameter view be a custom GUI.
I can't honestly even think of a case where embedding the plugin UIs
would even be wanted (though I'm sure someone can).. plugin GUIs are
huge and take up a lot of space. I just want to be able to pop the
thing up, fiddle with it, and make it go away.
Maybe if you want to do a reason-like virtual rack type of thing, but..
well, reason's UI is stupid. :)
-Dave Robillard
is it possible to summarise the objections to the
dssi approach
for ladspa?
One objection is that it completely avoids addressing the problem of
how to embed the GUI inside the host on-screen. Each GUI is
basically assumed to run up as a separate top-level window.
5:47 p.m.
New subject: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Tuesday 08 Jun 2004 8:26 pm, Dave Robillard wrote:
All we need IMHO is a way to have that parameter view
be a custom
GUI.
For my part, I'd at least like the host to be able to specify where
the window should appear -- which it currently can't. Maybe that's
something worth considering already for DSSI.
Chris
9 Jun
9 Jun
8:11 a.m.
New subject: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Tue, Jun 08, 2004 at 08:55:09 +0100, Chris Cannam wrote:
On Tuesday 08 Jun 2004 8:26 pm, Dave Robillard wrote:
Maybe. I have no particular objections, but the UI should be free to
ignore it I think. The old-school X11 -geometry seems like a good starting
place. e.g. xclock -geometry +10+10
- Steve
All we need IMHO is a way to have that parameter
view be a custom
GUI.
For my part, I'd at least like the host to be able to specify where
the window should appear -- which it currently can't. Maybe that's
something worth considering already for DSSI. 
10:09 a.m.
New subject: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Wed, Jun 09, 2004 at 11:02:50AM +0100, Steve Harris wrote:
On Tue, Jun 08, 2004 at 08:55:09 +0100, Chris Cannam
wrote:
no this is not sufficient at all.
if i put a plugin onto the galan canvas and scroll it up and down, i
want the plugin to follow the scrolling.
for me its sufficient to get the XID of the window.
Embedding is possible with fluxbox and iceWM.
and i think i know why other window managers dont let me embed windows.
note that galan currently embeds VST windows.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
On Tuesday 08 Jun 2004 8:26 pm, Dave Robillard
wrote:
Maybe. I have no particular objections, but the UI should be free to
ignore it I think. The old-school X11 -geometry seems like a good starting
place. e.g. xclock -geometry +10+10 All we need IMHO is a way to have that parameter
view be a custom
GUI.
For my part, I'd at least like the host to be able to specify where
the window should appear -- which it currently can't. Maybe that's
something worth considering already for DSSI.
11:05 a.m.
New subject: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Wed, Jun 09, 2004 at 02:06:05PM +0200, torbenh(a)gmx.de wrote:
Thats a sligtly different case, but we could add an option for the UI
to announce its XID when it registers with the host (the first thing it
does). Would that cover it?
- Steve
Maybe. I have
no particular objections, but the UI should be free to
ignore it I think. The old-school X11 -geometry seems like a good starting
place. e.g. xclock -geometry +10+10
no this is not sufficient at all.
if i put a plugin onto the galan canvas and scroll it up and down, i
want the plugin to follow the scrolling.
for me its sufficient to get the XID of the window.
Embedding is possible with fluxbox and iceWM.
10 Jun
10 Jun
8:31 a.m.
New subject: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Wed, Jun 09, 2004 at 01:56:13PM +0100, Steve Harris wrote:
On Wed, Jun 09, 2004 at 02:06:05PM +0200,
torbenh(a)gmx.de wrote:
Thats a sligtly different case, but we could add an option for the UI
to announce its XID when it registers with the host (the first thing it
does). Would that cover it?
yes perfectly.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Maybe. I
have no particular objections, but the UI should be free to
ignore it I think. The old-school X11 -geometry seems like a good starting
place. e.g. xclock -geometry +10+10
no this is not sufficient at all.
if i put a plugin onto the galan canvas and scroll it up and down, i
want the plugin to follow the scrolling.
for me its sufficient to get the XID of the window.
Embedding is possible with fluxbox and iceWM.
9 Jun
9 Jun
8:06 a.m.
New subject: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Tue, Jun 08, 2004 at 08:26:21 +0100, Chris Cannam wrote:
An implementation disadvantage is the need to produce
two separate
object files (the .so and the GUI), to ensure that they can both be
discovered by the host, and to keep them in sync -- for example to
make sure the GUI knows about the most up-to-date set of plugin
ports. Of course the GUI can always load the plugin and query it
itself, but most probably wouldn't want to do that.
I'm not convinced this is a problem:
1) its equivalent to having a plugin/library inconsistency, so the build
or packaging system should take care of it
2) plugins with the same UID are supposed to be port-compatible, though
due to developer lazyness this doesnt always happen *cough*
- Steve
8:20 a.m.
New subject: unique IDs etc Re: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Wednesday 09 Jun 2004 10:57 am, Steve Harris wrote:
2) plugins with the same UID are supposed to be
port-compatible,
though due to developer lazyness this doesnt always happen *cough*
DSSI actually identifies the plugin to the UI by .so and label, not by
unique ID. And there's no such requirement for labels, is there?
The whole thing about unique IDs troubles me though, because they're
supposed to be globally unique, right? So what should you do if you
want to write a .so that could instantiate any number of plugins
dynamically, either by generating them according to some
configuration or by wrappering e.g. an existing directoryful of VST
plugins? You can't possibly guarantee global uniqueness if you don't
even know in advance how many plugins you'll be offering.
Chris
8:55 a.m.
New subject: unique IDs etc Re: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Wed, Jun 09, 2004 at 11:28:28 +0100, Chris Cannam wrote:
On Wednesday 09 Jun 2004 10:57 am, Steve Harris
wrote:
Ah, no true, I forgot we used .so + label. Still the packaging system
should take care of it.
2) plugins with the same UID are supposed to be
port-compatible,
though due to developer lazyness this doesnt always happen *cough*
DSSI actually identifies the plugin to the UI by .so and label, not by
unique ID. And there's no such requirement for labels, is there? The whole thing about unique IDs troubles me though,
because they're
supposed to be globally unique, right? So what should you do if you
want to write a .so that could instantiate any number of plugins
dynamically, either by generating them according to some
configuration or by wrappering e.g. an existing directoryful of VST
plugins? You can't possibly guarantee global uniqueness if you don't
even know in advance how many plugins you'll be offering.
The UID is not globally unique - I think the way it was defined was just a
mistake.
- Steve
9:07 a.m.
New subject: unique IDs etc Re: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Wednesday 09 Jun 2004 11:46 am, Steve Harris wrote:
The UID is not globally unique
Well, I would prefer that it wasn't, but unfortunately that does
contradict what ladspa.h specifies and what real hosts expect.
(jack-rack and Rosegarden at least currently use the unique ID to
index plugins and will reject plugins with duplicate IDs.)
Chris
9:17 a.m.
New subject: unique IDs etc Re: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Wed, Jun 09, 2004 at 12:16:14 +0100, Chris Cannam wrote:
On Wednesday 09 Jun 2004 11:46 am, Steve Harris
wrote:
Nothing in ladspa.h says that UIDs are globally unique - just the .so +
label combination is guaranteed to be (system) unique.
The UID is not globally unique
Well, I would prefer that it wasn't, but unfortunately that does
contradict what ladspa.h specifies and what real hosts expect. (jack-rack and Rosegarden at least currently use the
unique ID to
index plugins and will reject plugins with duplicate IDs.)
Yep, and I think thier not alone. I only realised that UIDs were not
globally unique recently myself. Its kinda obvious when you think about
gnerated plugins, but its very confusing.
Using some kind of self-authorising, URI-like scheme would have been a
much better idea, but hey. Its a bit late now.
- Steve
9:21 a.m.
New subject: unique IDs etc Re: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Wednesday 09 Jun 2004 12:09 pm, Steve Harris wrote:
Nothing in ladspa.h says that UIDs are globally unique
I think "Plugin programmers may reserve ranges of IDs from a central
body to avoid clashes" pretty strongly suggests it, don't you?
Chris
9:41 a.m.
New subject: unique IDs etc Re: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Wed, Jun 09, 2004 at 12:29:35PM +0100, Chris Cannam wrote:
On Wednesday 09 Jun 2004 12:09 pm, Steve Harris
wrote:
eah, except that not all plugins are created by programmers, some are
created by programs. I also read may as in the IETF's SHOULD - which
doesn't have that strong a meaning, that would be MUST I think.
- Steve
Nothing in ladspa.h says that UIDs are globally
unique
I think "Plugin programmers may reserve ranges of IDs from a central
body to avoid clashes" pretty strongly suggests it, don't you? 
11:24 a.m.
New subject: unique IDs etc Re: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
--- Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote: > On Wed, Jun 09, 2004 at
12:16:14 +0100, Chris Cannam wrote:
/* This numeric identifier indicates the plugin type
uniquely. Plugin programmers may reserve ranges of IDs from a
central body to avoid clashes. Hosts may assume that IDs are
below 0x1000000. */
unsigned long UniqueID;
/* This identifier can be used as a unique, case-sensitive
identifier for the plugin type within the plugin file. Plugin
types should be identified by file and label rather than by index
or plugin name, which may be changed in new plugin
versions. Labels must not contain white-space characters. */
const char * Label;
leaves host authors with a choice - use UniqueID or filename+label to index
plugins. unsigned longs are easier to manipulate than char *'s, so it's likely
that using the UniqueID has been preferred.
and..
http://www.ladspa.org/ladspa_sdk/unique_ids.html
Not that I'm advocating the continuation of this scheme for reasons already
discussed, but I believe this may be the reason for the confusion!
Hopefully this can be fixed with LADSPA v2...
-
Myk
____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
On Wednesday
09 Jun 2004 11:46 am, Steve Harris wrote:
Nothing in ladspa.h says that UIDs are globally unique - just the .so +
label combination is guaranteed to be (system) unique.
The UID is not globally unique
Well, I would prefer that it wasn't, but unfortunately that does
contradict what ladspa.h specifies and what real hosts expect. (jack-rack and Rosegarden at least currently use
the unique ID to
index plugins and will reject plugins with duplicate IDs.)
Yep, and I think thier not alone. I only realised that UIDs were not
globally unique recently myself. Its kinda obvious when you think about
gnerated plugins, but its very confusing.
16 Jun
16 Jun
10:13 a.m.
New subject: unique IDs etc Re: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
[old thread]
On Wednesday 09 Jun 2004 12:16 pm, Chris Cannam wrote:
On Wednesday 09 Jun 2004 11:46 am, Steve Harris
wrote:
And call me slow on the uptake, but doesn't LRDF require that the
unique ID be unique as well?
Chris
The UID is not globally unique
Well, I would prefer that it wasn't, but unfortunately that does
contradict what ladspa.h specifies and what real hosts expect.
3:13 p.m.
New subject: unique IDs etc Re: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Wed, Jun 16, 2004 at 01:23:46 +0100, Chris Cannam wrote:
[old thread]
On Wednesday 09 Jun 2004 12:16 pm, Chris Cannam wrote:
Yes, its a bug, caused by my general state of confusion. In practice it
means that gnerated plugins can't have RDF descriptions, but thats not a
huge issue for LADPSA 1.0
- Steve
On Wednesday 09 Jun 2004 11:46 am, Steve Harris
wrote:
And call me slow on the uptake, but doesn't LRDF require that the
unique ID be unique as well? The UID is not globally unique
Well, I would prefer that it wasn't, but unfortunately that does
contradict what ladspa.h specifies and what real hosts expect.
9 Jun
9 Jun
9:15 a.m.
New subject: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
thanks for your good answer, Chris!
at the risk of repeating old discussions here are some uninformed comments:
On Tue, Jun 08, 2004 at 08:26:21PM +0100, Chris Cannam wrote:
thereby remaining flexible and avoiding some extremely thorny issues
over differing toolkits and x event loops.
sure it would be nice to have the embedding option, but in
how many situations is that really neccesary? (Especially as
the gui is optional anyway)
and given that we have an unknown quantity of windows of varying
size, i cant see how that would work. But I personally have no user
experience of embedded plugin windows.
(I think galan does this, but i cant compile it)
is it possible
to summarise the objections to the dssi approach
for ladspa?
One objection is that it completely avoids addressing the problem of
how to embed the GUI inside the host on-screen. Each GUI is
basically assumed to run up as a separate top-level window. I could imagine some library support for re-parenting
GUIs, but it
certainly isn't intrinsic to the current proposal. The problem is
exacerbated by the fact that GUIs that are most comfortable running
in entirely separate windows are likely to be the more complex ones
that are perhaps less amenable to being hosted plugins in the first
place -- if the GUI can happily run standalone, there's a stronger
argument for making the entire "plugin" a standalone JACK app.
surely standalones and plugins both have their place? I dont buy
the argument that complex fx should be standalones.
A further conceptual criticism is that it will just
encourage people
to produce GUIs that are inconsistent, inelegant, tasteless and hard
yes giving people freedom will cause "inconsistent, inelegant, tasteless
and hard to use" things to arise but it will also cause good things
too:-) As long as the gui's are optional, this surely cannot be a
problem. I'm also assuming that multiple alternative gui's can be made
available.
to use -- i.e. it doesn't do anything to address
the biggest problems
a plugin author might face when writing a GUI, namely what to build
the GUI from and how to design and organise it. A separate library
to help with that by wrapping basic toolkit widgets in forms likely
to be of use to audio plugins might be worth considering.
not from my point of view. Any special library is going to be very
limiting. I would hate to see linux hobbled by this in the same way as
vst is. I dont think anyone has mentioned in this thread that
presumably libvstgui is a significant factor in encouraging the use of
those cheesy bitmaps that most of us find unusable even if we can stomach
the looks.
and i dont think the plugin author should _have_ to worry about guis
at all. People who can do dsp code _and_ user interfaces are the
exception rather than the rule.
i would rather some ladspa template gui apps were made which encouraged
artists to use whatever tech they wanted. Eg Gtk, Qt, Svg, Flash,
GnomeCanvas, SDL, XUL, DHtml, OpenGl etc...
An implementation disadvantage is the need to produce
two separate
object files (the .so and the GUI), to ensure that they can both be
discovered by the host, and to keep them in sync -- for example to
make sure the GUI knows about the most up-to-date set of plugin
ports. Of course the GUI can always load the plugin and query it
itself, but most probably wouldn't want to do that.
cheers
--
Tim Orford
3:36 p.m.
New subject: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
On Wed, Jun 09, 2004 at 12:58:21 +0200, Tim Orford wrote:
Yes (though the current hosts dont give you a way of choosing between
them). 3rd party developers can easily code thier own UIs for plugins, and
you can always uninstall tasteless ones with the power of rm :)
You aren't forced to use libvstgui in VST, many people dont. I can see
that a toolkit specially designed for plugins UIs would be useful, but I
doubt anyone would bother to make it, an its likly to not fit enough
peoples tastes in APIs get get traction.
surely standalones and plugins both have their place?
I dont buy
the argument that complex fx should be standalones.
Agreed.
A further
conceptual criticism is that it will just encourage people
to produce GUIs that are inconsistent, inelegant, tasteless and hard
yes giving people freedom will cause "inconsistent, inelegant, tasteless
and hard to use" things to arise but it will also cause good things
too:-) As long as the gui's are optional, this surely cannot be a
problem. I'm also assuming that multiple alternative gui's can be made
available. to use -- i.e.
it doesn't do anything to address the biggest problems
a plugin author might face when writing a GUI, namely what to build
the GUI from and how to design and organise it. A separate library
to help with that by wrapping basic toolkit widgets in forms likely
to be of use to audio plugins might be worth considering.
not from my point of view. Any special library is going to be very
limiting. I would hate to see linux hobbled by this in the same way as
vst is. I dont think anyone has mentioned in this thread that
presumably libvstgui is a significant factor in encouraging the use of
those cheesy bitmaps that most of us find unusable even if we can stomach
the looks. and i dont think the plugin author should _have_ to
worry about guis
at all. People who can do dsp code _and_ user interfaces are the
exception rather than the rule.
i would rather some ladspa template gui apps were made which encouraged
artists to use whatever tech they wanted. Eg Gtk, Qt, Svg, Flash,
GnomeCanvas, SDL, XUL, DHtml, OpenGl etc...
Yup. In the DSSI scheme all it needs is a tiny bit of wrapped code to bind
OSC messages to GUI elements. Its dead easy in GTK*, and from what I've
seen of Qt, its simple there too.
* infact its automatable, I plan to write a function that will bind the
Adjustment called "MYPLUGIN_GAIN" or whatever to the appropraite OSC
messages when the GUI is created, which would make it possible to spit out
nearly completed GUIs from glade.
- Steve
7261
days inactive
7269
days old
linux-audio-dev@lists.linuxaudio.org
21 comments
7 participants
participants (7)
-
Chris Cannam -
Dave Robillard -
eviltwin69＠cableone.net -
Mike Rawes -
Steve Harris -
Tim Orford -
torbenh＠gmx.de