15 Jan
2004
15 Jan
'04
11:38 a.m.
On Thu, Jan 15, 2004 at 04:21:29PM +0100, Alfons Adriaensen wrote:
The sperate binary is host neutral, but the .so would have to be host
specific (well, host toolkit specific) to some extent.
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.
No, but theres a lot of comlexity in handling that.
- Steve
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. 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? 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.