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