From: Sean B. <smb...@jp...> - 2004-11-18 17:38:35
|
On Nov 18, 2004, at 1:20 AM, Chris Cannam wrote: > Hmm, I get a crash on instantiate. Doh, that's embarrassing. I'm guessing I forgot 'make install' before I tested it, and actually 'tested' a previous *.so.... > dssi.h does say (and has always said): > > * A plugin is not required to select any particular default > * program on activate(): it's the host's duty to set a program > * explicitly. The current program is invalidated by any call to > * configure(). > > So perhaps it's simply the wrong thing to try to set any program or > port > values from either instantiate or activate. Yeah, I agree it's wrong in our current understanding of things. (And the above text shouldn't imply program selection is legitimate within activate()). > Although, given the notorious inadequacy of LADSPA port defaults, this > isn't likely to be very satisfactory either. The last thing we want is > to encourage plugins to start up in a stupid-sounding state. ... > I think I'd like > your view on how Xsynth, Hexter etc would actually cope with a regime > like the one I described in the email quoted above, first, though. Xsynth uses ports for its patches, so until a host sent a program change, it would use the port defaults, and probably sound stupid. By fiddling with the defaults, I think I could get it from 'stupid' to just 'lame' or better, but you're right, it's an awkward situation not to be encouraged. hexter uses configure info for patches, not ports, so I can (will) have it set a default program in instantiate(). > Perhaps > that is the fatal flaw in my argument about activate: that a plugin > might have a legitimate need for a place to do some first-time setup > that it can't actually do in instantiate. > Perhaps that does imply a need for another API call. But the only thing not available to a plugin in instantiate(), that would be available at first activate(), is the ports. If we more clearly specified that a host should always do a select_program() after the first activate() (or more precisely, after the the ports are initially connected but before the first run_*()), to give the plugin a chance to set ports if needed, wouldn't that be enough? The plugin might have to remember whether it was the first select_program() or not, and act accordingly, but I can't think of any reason why this wouldn't be sufficient. (<grin> Now _I'm_ arguing against an API change! But this is a separate issue from my continuing belief that an API change could be more elegant, make life easier for host authors, and not much more difficult for plugin authors.) -Sean |