you can think
all you want. unless there a plugin->host callback that
allows the plugin to determine its operating environment in huge detail,
this kind of idea is pretty impossible to make use of.
What?
Once again: misunderstood! These optimizations involve that the
"wrapper" (I should stop calling it this way) knows about the network
of processing objects (read: plugins) and that these last ones contain
"generic" information on their functionality (ex. STFT for LTI proc.
objects).
Then the wrapper takes care of optimizing the net.
find me a host author who would want to use such a thing... managing
plugins is a central task of a host, and handing that over to some
"wrapper" that hides information from the host doesn't make the host's
life easier, it makes it more complex.
In fact you wouldn't have to.
You could just use it as a plugin wrapper, network representation and
optimizazion would be of some use only for some (experimental?
advanced? strange?) hosts.
Personally, I would use such thing for my project.
Then, who said that it has to hide such informations to the host?...
It is definitively not a plugin arch wrapper, but a kind of
"inter-application jack-like connectivity tool for processing objects
with already existing plugin archs wrapping and network optimization
capabilities".
As it goes when you build a GTK app, you don't have to use each
library function, and so it would become just a plugin wrapper.
Maybe the two things can be split, but maybe optimization could hardly
depend on each processing object interface (aka plugin format).
Well, I thought about it last night, and maybe the whole thing could
be split in three parts:
1. A modular processing object format wrapper (one module for each format)
2. A GUI generation and handling (and maybe embedding? XEMBED?)
wrapper with format-specific modules and toolkit-specific modules
3. A library with network representation, optimizing and processing
capabilities.
What do you think about it?
Stefano
