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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
