[LAD] Specification issues in open systems

[Chris Williams]

Paul Davis wrote:
> i ran into quite a lot of really significant problems
> which could only be solved using google-fu

As is natural. I have no problem with this and did a great
deal of it myself. When I say the information wasn't
mentioned anywhere, I mean *anywhere*. I suspect that,
because of the minimal take-up of DSSI, both in host and
plugin terms, I was the one of the first people to unearth
it, as I was among the first to try doing what is a fairly
standard operation in the Windows / Apple worlds and
noticing that one host didn't behave as expected. Having
scoured the web and especially rosegarden's own site both
before and after finding the issue, the only thing
Rosegarden's docs have to say is expressing full support
for DSSI. If nothing else -- and part of the reason for
doing this -- this series of posts will provide some
google feedback for any people who hit the issue in future.

> i am really not taking you to task for your observations
> on DSSI - from what you've written it really does sound
> like a bit of mess in this repsect, and quite possibly
> LV2 as well. but .. i am not entirely clear why you've
> approached the problem in the way you have.

I claimed an implementation issue was intimately bound up
with a problem inherent to certain specifications, then
backed it up with facts when you called me on it. Perhaps
my tone was overly irritated, and for that I apologise.

To the general conversation ...

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. Implementing it as a plugin
allows the instrument to take advantage of a host's
facilities. For example, a non-trivial synth or sampler can
use the host's ability to host effects plugins; otherwise,
the instrument has to host them itself, thus also having to
provide an effects GUI generator. A second reason is that
the plugin host can behave as an input mediator / sequencer
for the plugin. A third reason is that, by developing an
instrument as a plugin, the developer can *also* develop a
"stub host", thus allowing the instrument to run either as
a plugin or as a standalone app, which is what NI have done
with a lot of their instruments. Doing it *solely* as a
standalone app means you're stuck with that model forever.
Fourthly, as mentioned, there's session state saving.

There's a reason that ReWire (*loosely* a jack equivalent)
slowly became deprecated in favour of VSTIs on Windows. The
prevalence of "using the OS" in the linux world is more to
do with with the disparate and divided state of DAWs, host
support for instruments, and the (quite wonderful) state of
jack than it is to do with it being inherently the best
solution. Everyone writes to jack (or ALSA) because they
know it's a common denominator that's guaranteed to work
well (as well as the fact that jack's architecture can
replicate host provision to an extent) not because it's
necessarily the best model for doing it a priori.

As to session state saving, it's not something that
*personally* concerns me all that much, provided each
component allows the facility for saving its own
configuration. Paul's right, though; it really is a big
deal on the other OSs. Users are used to saving their
project in their DAW of choice and having the DAW
remember it, rather than them having to be responsible for
saving each piece individually. DSSI provided some
capability for this with the 'configure' function / OSC
call. It gave the host some handle on how to reconfigure
the instrument in question when loading a project. LV2
doesn't even do that from what I can see.

Chris Williams