[LAD] Specification issues in open systems

Chris Cannam cannam at all-day-breakfast.com
Mon Sep 29 09:32:42 UTC 2008


On Sat, Sep 27, 2008 at 6:49 PM, Chris Williams <yikyak at gmail.com> wrote:
> I can't see this as being anything other than a specification bug. I
> don't think the rosegarden developers have implemented the spec
> correctly, necessarily, but the spec gave them ample room to do what
> they did.

So if I understand correctly, the original requirement is to have a
single plugin receive a single MIDI stream, and then output multiple
audio channels which the user can treat separately with different
effects in the host (according to his or her whim).  And Rosegarden
will not do this because, although your plugin can declare that it has
any number of output channels, Rosegarden will not handle more than
two; it will merge them in an undocumented and externally
unpredictable way.  And it doesn't allow the user to route the
channels to separate effects anyway, even if there are only two.

I would have said this was squarely a limitation of Rosegarden.  It's
one that is likely to remain, as well.  The DSSI spec of course
permits this -- at the moment it's basically a user problem (this
plugin will not work properly in this host).  If the DSSI spec was
changed so as to require the host to support the behaviour you want,
then Rosegarden would simply change from being a technically complete
but limited DSSI host to being an incomplete or non-conformant DSSI
host; its actual behaviour would not change unless some new enthusiast
with lots of spare time happened to step in to completely rewire its
audio architecture.  (Fons is quite right to say that the Rosegarden
project has suffered from worrying about audio too much already.)

I think that this limitation is quite defensible -- Rosegarden just
isn't a good host for any task where the words "audio" and "routing"
might both appear, and that's simply the way it is.  You'd surely be
better off doing it in something like Ingen and just driving the
resulting graph from Rosegarden if desired (unless I misunderstand the
goal here).

But I guess you're right that what's not really defensible is in the
failure to provide any way in the protocol to negotiate this, or for
the plugin to determine itself whether its host is capable.  You're
probably right about the cause of this as well (basing the protocol
off a simplistic effects protocol -- although I think "simplistic" is
the point rather than "effects" -- many effects call for more
sophisticated output classification as well -- try running the Bode
frequency shifter LADSPA plugin on a mono track in Rosegarden some
time).

My guess is that this situation -- in which a plugin may be capable of
something, but just mysteriously fails in a given host -- will get
worse with LV2, as well, given the potentially huge range of optional
extensions that may or may not be available.  I agree, it's not a very
promising situation: who would want to write plugins that only "might"
work?

(Well, hey, DSSI is still at v0.9.  Plenty of time!)


Chris



More information about the Linux-audio-dev mailing list