29 Apr
2006
29 Apr
'06
3:42 p.m.
On Sat, Apr 29, 2006 at 12:40:11PM -0400, Dave Robillard wrote:
On Sat, 2006-04-29 at 15:09 +0100, Chris Cannam
wrote:
I think that's Chris's point though. LADSPA2 has a lot of potential, but
why will the users care?
However I know that at least one plugin developer will port all his
plugins as soon as its finalised, and all the pent up addiditons to LADSPA
people have been wanting for ages, but were just to painful to add can be
applied. I think the promise of the new features (better auto-built UIs
and control randomise are good examples) is enough to make users request
support from host authors.
These things take time, and I'm not expecting it to be an overnight
success, but there are so many cool things that could be done with a more
capable, but still fundamentally simple spec.
As to DSSI, I regard it as a quiet sucess, theres a fair few pieces of
software that wouldn't have existed without it, and it was a good learning
experience. Plus we showed that its possible to have plugin UIs on linux
without crazy X hacks :)
As to wether LADSPA2 can replace DSSI, well, hopefully at some point (we
never intended DSSI to be a permenant solution, D right), but its not so
urgent. The problems with LADSPA dont affect DSSI so much because it has
custom UIs and configure(), which cover a multitude of sins.
- Steve
I haven't posted to this thread yet, for a
couple of reasons besides the
usual lack of time.
One reason is that on a technical level I don't have any argument with
most of what Steve says. Removing descriptive data from the plugin I
think is a good principle. I'm not fond of this Turtle format, it is
complicated and I don't find it easily "visually parseable" but it's
still better than XML RDF, and so long as you can easily hack someone
else's .ttl file to make your own, it probably isn't much of an issue.
Technically it all looks pretty much OK.
But the other reason is that I don't find much to make me care about the
outcome at this stage. This may be a technically better way to design
a LADSPA-like plugin API, but until it offers something significantly
more useful than LADSPA, that's rather irrelevant to anyone outside
this thread. A LADSPA 2 that is the same as LADSPA 1, "technically
superior" but incompatible will probably fail. Authors of existing
hosts won't want the trouble; plugin authors will put up with the
potential extra work of doing LADSPA 1 to get better host coverage. So
the aim is to do more interesting things with it afterwards. But what?
The idea is to make LADSPA2 such that new, interesting things can happen
as extensions without breaking things. LADSPA1 can't do this.
As an example, LADSPA2 of course does not specify anything about MIDI,
but MIDI processing LADSPA2 plugins can be built if someone defines an
extension to do so.
Even with major improvements like that aside, the ability to add new
handy pieces of metadata at will is enough of a win to make it
worthwhile, IMO.
LADSPA2 itself isn't very exciting, true. But what LADSPA2 will allow
is the most exciting linux audio thing to happen in a while, if you ask
me..