> OK, so take the construction:
>
> if (variable) {
> output = some_opcode (arg1, arg2, arg3);
> } else {
> output = some_other_opcode (arg3);
> }
>
> and explain to me how to represent this in a "flat" format that is not
> essentially just assembler, i.e.:
i guess this has already been answered.
namely, compute both branches and then
set:
output = variable*branch1output + (1-variable)*branch2output
i think you misunderstood what i
meant by flat. i'm not claiming
the user shouldn't take advantage
of scripting languages. i'm just
saying that the scripting languages
should all compile down to the
same (flat = non-scripted) LADSPA
netlist rather than being imbedded
in the plugins.
> >as i noted before, in a flat model, it
> >API really simple. the alternative
> >would make the scripting language part
> >of the LADSPA api.
>
> I don't think it has to be this way. You can view the process I
> described above as all part of the "initialize" routine of a
> plugin. Thats certainly how I propose to turn Quasimodules into LADSPA
> plugins. The end result is just a pointer to a plugin instance that
> can be passed to the "run" method.
>
> All the above stuff would happen when the host loaded the .so file,
> and ran the "initialize" routine. For all a host could care, the
> plugin may have been written in C++, and dynamically compiled upon
> loading. All we need are the elements in the API: what ports does it
> use/provide, and function ptrs for the standard plugin methods. The
> internals of the plugin are its own business.
>
> Of course, most plugins will be written in C or something like it, and
> won't do any of this stuff. But take a look at say, Cycling '74's VST
> plugins. They come with their own entire script language and GUI, yet
> plug straight into a VST host. Same with DeSPider and ReDSPider for
> TDM.
so this technique is usefull for porting
existing plugins. however, my argument was
that large, opaque plugins are not optimal
from a host/plugin users standpoint ....
instead they should be transparently composed
of smaller, basic, opcode-sized plugins (think
CISC vs. RISC). i think the composition is
possible with nothing more than a netlist.
the advantage:
1. you don't have to carry around multiple
copies of some large chunk of initialization
code with every plugin.
2. you don't have to worry about running
things like compilers or interpreters on
every host (my hypothetical nord-lead
clone)
3. the chance that i'm going to dive
into the source code for some giant
plugin written in C or a custom scripting
language just to fiddle with it is less
likely than if my desktop host lets me view
it as a bunch interconnected opcode-sized
plugins which i already know how to use.
4. for the reason above, transparent,
compositional plugins promote code reuse.
if everyone writes giant, monolithic
plugins rather than reusing more basic
parts, they will spend a lot of time
duplicating each other's efforts.
5. transparency makes possible runtime
optimization. if the three or four
rack-sized plugins you're using are
represented to the host as one big
network of low-leve operations, it
can optimize away redundant computations.
with large, opaque plugins, you could
be computing the FFT of the same signal
inside multiple plugins when you really
should only be computing it once.
charless
