On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote:
IMHO, thats
not the way to do any of those things:
mono/stereo is best done with dosconnected ports IMHO. That way you can
change the connected state and have the plugin react.
mono/stereo isn't the best example. I'm thinking of things like an n->1
mixer plugin.
I'd like to not even think about cases like that, it's conceptually quite
complex, and there aren't many examples of when it's needed. Like you said
below it can be done with complex control ports for example. That's not
great either, but for the small number of cases it's needed it doesn't
bother me personally.
Adding complex features to make certain corner cases easier is what ruins
most APIs IMHO.
I guess the port things aren't a good
justification for the creation
parameters, you're right. The question, then, is what is the
recommended way for the host to provide functions to the plugin? That's
what Lars was originally seeking (and solves the above allocation
problem as well)
I think that if it's provided as part of a HostFeature (so the plugin
knows it exists and what it's called) it can be obtained using the OS's
normal dynamic linking functions. I've not tried though.
- Steve