Re: [linux-audio-dev] Todays changes to "LADSPA2" strawman

From: Dave Robillard <drobilla@email-addr-hidden>
Date: Sun Apr 30 2006 - 02:01:30 EEST

On Sat, 2006-04-29 at 18:42 +0100, Steve Harris wrote:
> 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 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..
>
> 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.

Users /don't/ have any reason to be excited about getting LADSPA2
directly. That's irrelevant though.

We need a better API with which to build good, useful things. Having
that API will allow those good, useful things to be built, which of
course benefits users. There are many, many plugins I've been itching
to write but LADSPA1 wasn't up to the task (there are still some gaps in
LADSPA from what SSM provided natively I intend to fill, for example).
Users get their benefit from these new plugins being written.

I don't care whatsoever if users care directly about LADSPA2 at this
point - I want to build things with it. It's a plugin API, of course
users don't care. Users aren't the.. uh, users of API's, developers
are.

We should build what we as developers would like to use. Screw the
users, they'll care later when the benefits trickle down :)

-DR-
Received on Sun Apr 30 12:15:04 2006

This archive was generated by hypermail 2.1.8 : Sun Apr 30 2006 - 12:15:04 EEST