[LAD] Specification issues in open systems

The following is a cross-post of an exchange that took place on the rosegarden-devel mailing list. I'm posting it here because I think it hints at something fairly serious with the current state of open audio specifications and issues with their implementation. It is not my intent to start a flame war. I come at this with over twelve years of involvement (albeit chiefly at a hobbyist level) with audio development and production on windows system (predominantly VSTis). I've used linux since the late nineties, but these issues have become more important to me since fully ditching Windows about 18 months ago. The open source philosophy has always been that, if something were not to your tastes, you were completely free to build it, or alter something else. This is true, and one of the things greatly appreciated about the system. The key issue, though, is the ability to use that facility; sometimes it is not as available as it appears. There are a great many people who would offer much more to open audio, I feel, but issues like the following need to be addressed. all the best, Chris Williams Chris Williams <yikyak> wrote: I've been thinking about this some more, and can't let it lie. It seems to me that there's definitely a bug or broken implementation involved somewhere. Under jack-dssi-host, if I request n outputs, I get n outputs, any one of which is routable to wherever I wish to send it using jack_connect or qjackctl. Under rosegarden, if I request n outputs, I always get either one or two, depending on the stereo settings of the host- ascribed audio channel. This is a problem, because any summing rosegarden does *could* have been done internally in the plugin. What's the point of requesting, configuring and filling >2 output ports if the client is never *effectively* going to get them? If the client wanted them bumped down to one (or two) buffers, it could -- would -- have done this itself and needn't have requested and configured >2 outputs in the first place. Now, one way of approaching this is to say, "Oh, well; it's an implementation bug in rosegarden and there's nothing that can be done". That's OK as far as it goes, but it doesn't actually solve the problem / ambiguity and it's questionable as to whether it's true. Another approach is to say that rosegarden implements the DSSI spec correctly and the bug is actually in the spec itself. This is *far more serious* -- and it's far more serious for two reasons. Firstly, rosegarden is currently the only fully-featured standalone DSSI host. How are the other hosts currently implementing it (MuSE etc.) going to behave? Are they going to implement rosegarden's behaviour, or are they going to implement jack-dssi-host's behaviour? In either case, you have a situation where plugin developers simply don't know what the host is going to do, which kind of defeats the point of a specification. At this point a cynic might say that the uptake of DSSI is such that it doesn't matter too much and that the likes of LV2 will solve this problem anyway, but this brings us to the second serious problem (which the more well-versed among you will already have realised): If this ambiguity isn't specific to rosegarden but is inherent in the spec, then *LV2 doesn't solve it either*. Part of the problem with DSSI, if this is where the problem lies, is that it encourages host developers to treat synth / sampler plugins as extensions of effects plugins for the sake of simplicity. This works to an extent, but there's a subset of functionality that they do not have in common (the ability to leverage other effects plugins and host capabilities for two). There is no output-negotiation scheme in either LV2 *or* DSSI beyond the output port request and instantiation stage, and neither spec makes clear what a plugin can expect having acquired those outputs, or, from the other side, what a host is fully expected to provide in response to a given request. The assumption goes unstated, which is why there is this problem to begin with. Perhaps an extra negotiation is required, so that both the host *and* the plugin know unambiguously the contexts in which they are operating. It's not reasonable to expect a host to grant any and all resources that a synth plugin might request (2^32 outputs, for example), but at the same time the *plugin* needs to *know* the context in which it's operating, and not have to guess it based on external knowledge of specific host implementations. Anyway, I appreciate that the rosegarden developers are not fully responsible (if at all) for this situation, but it is a major issue, I feel, when it comes to standard adoption and plugin development with open systems. I may cross-post this to the LAD list as it seems just as relevant to them as to you. Thanks for your time, Chris Williams