On Sat, Sep 27, 2008 at 6:49 PM, Chris Williams <[EMAIL PROTECTED]> 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
