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
Received on Tue May 2 04:15:02 2006
This archive was generated by hypermail 2.1.8 : Tue May 02 2006 - 04:15:03 EEST