Re: [LAD] Specification issues in open systems

This isn't entirely addressed to Paul; I've just used his
comments as a jumping point.

Paul Davis wrote:
> Chris Williams wrote:
>> As regards the merits or not of writing an instrument as
>> a plugin, that's been addressed by some other respondents.
>> The fact is that an instrument does *not* need OS-levels
>> of interaction; it needs timing and midi data and output
>> audio buffers, and optionally some facility for providing
>> a GUI -- that's about it.
>
> You're thinking small :) File I/O, network interaction,
> interactions with different sorts of input devices ...
> there's more.

Point taken, but there's nothing inherently "non-plugin"
about doing this. There are plugin architectures in dozens
of other application areas that do these things. Add file
I/O to my original list and you've covered a very large
chunk of use cases (but not all, I concede).

> JACK exists primarily because there was not a suitable
> plugin API on linux and because several of us felt it
> unlikely that there ever would be one.

I think this is partly where my issues stem from. Nothing
will ensure this happens faster than a half-dozen bad specs.
LADSPA was good in the sense that it was brief, tightly
defined, *relatively* simple to implement from the host
side (provided the host-supplied GUI generator was up to
scratch); *very* simple to implement from the plugin side.
I've spent some of today reading LV2 in more detail. I'm
honestly not sure what to make of it at this point. My
first reaction was that it's attempting to solve certain
problems by introducing worse ones, but I haven't thought
it through fully yet.

> The biggest obstacle of all was the still-unsolved issue
> of GUI toolkit compatibility.

LADSPA tried to cope with the GUI issue largely by handing
it off to the host. This facilitates a large set of effects
and a smaller set of instruments but by no means all.

LV2 seeks to solve this via the extension mechanism. This
is one of the areas I'm really not happy about, especially
the current (admittedly tentative) extension mandating not
only a gui toolkit (gtk), but also the idea that the plugin
should implement the Widget interface while the host should
already be running the gtk main loop. Ouch. The problem
with the extensibility argument is that no host is going to
implement it fully, properly or consistently (as mentioned,
it's hard enough for this to happen with a tightly-defined,
compact spec) which leaves client developers still not
knowing what they are dealing with.

DSSI, IMO, *attempted* to get this right. Implicit in the
DSSI spec is an acknowledgment that a plugin spec can't be
in the business of mandating gui solutions on a platform
with many to choose from, so they tried to find a way
around it using a remote gui which communicates with the
host via OSC. I'm not sure this is entirely correct,
either, but it's at least "more right" than several other
ways of doing it (*cough* LV2), especially the central idea
of trying to abstract the gui away from the architecture.

Incidentally, the idea that this is necessarily easier
on other platforms with a single widget set is, at best,
only half-true. I was intimately involved for a few
years with the development of three products at a company
with modest fame in this area. What the Windows developers
overwhelmingly tend to do (I spoke with devs at other
outfits that did this too) is use the native windowing
system to get a Frame and a graphics context -- nothing
else. They then end up drawing directly on the graphics
context "manually" (thus effectively developing their own
gui-toolkit-lite). This frees them (to an extent) from
issues involving implementing their plugins in other
OSs, as you can generally always get at least a Frame and
a GC, and any differences in coordinate systems can be
overcome with a trivial spacial translation.

Chris Williams
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Sep 29 00:15:02 2008