On Thu, Jan 15, 2004 at 04:21:29PM +0100, Alfons Adriaensen wrote: > > I was thinking that the UI code would be a piece of software, not just a > > description, that would be run my the host - either a seperate binary or a > > part of the plugins .so file. > > That's a solution, but outside the current LADSPA specs. And the separate > binary would be specific for a particular host.
The sperate binary is host neutral, but the .so would have to be host specific (well, host toolkit specific) to some extent. > > > OTOH, we could introduce the reverse: a bit in the hints requesting the host > > > *not* to connect a dummy buffer, but instead to set the pointer to NULL if > > > the port is unconnected. This would be backwards compatible, AFAICS. > > > > Yes, but why not just have some way of telling if its the dummy buffer? > > Because passing NULL is the obvious way to do it, and there is no need to > introduce a new mechanism. And since no existing plugin will request this, > it's perfectly compatible. If you prefer simplicity, why make it more > complex ? It doesnt make it more complex. Instead of comparing to NULL you're comparing to a known constant - the difference is that it makes the plugin logic, for 95% of plugins, much simpler. I agree that its a slight deviation from the traditional C cliche, but I think the advantages are very significant. > > I agree about diversity, but disgree totally about the other points. In my > > experieince complex systems are generally failures - they rarely offer > > anything thats a significant advantage over (comparativly) simple systems, > > and modular synth modules are simple systems - if there not then youre > > doing something wrong. > > I'm not advocating complexity for its own sake -- things should be as simple > as they can be, *but not simpler*. Anyway, there is nothing complex in setting > a bit in a constant hints value. No, but theres a lot of comlexity in handling that. - Steve
