Re: [linux-audio-dev] Sound processing objects architecture, is it possible?

2007/1/22, Dmitry Baikov <dsbaikov@email-addr-hidden>:
> On 1/23/07, Stefano D'Angelo <zanga.mail@email-addr-hidden> wrote:
> > Good point! This is true, but there are lots of sound processing
> > plugins around, so maybe instead of creating a new API and then apply
> > some "compatibility layer", it should be better to create a wrapping
> > tool natively. I think it should be also easier to expand.
>
> Then, embrase LV2 and create LV2 plugins that will load VSTs, LADSPA
> and anything you want.
> Or if you want something not possible with LV2, write an extension proposal.
>
> I think LV2 was designed as a very extendable API.
> If it is not, in your opinion, then help the guys to improve it.

That could be a very wise solution, but there's one big problem with
it: when you load a LV2 plugin, you load only one plugin!
To be clearer I make an example: I have 10 VST plugin, and I want to
write a LV2 plugin which loads VST plugins. When the LV2-aware
application asks me which plugin I want to load I should specify the
VST plugin loader... but then? There's no way for my LV2 plugin to
determine which VST plugin it should load.
But also if this is an overcomeable problem, for each VST plugin I
load I have to waste memory space with a new instance of the LV2 VST
loader plugin.
Then, it is quite absurde from the user point of view to open a plugin
which lets you open other plugins... it's just illogical!
Don't misunderstand me, LV2 is great, I think that it's the best
processing architecture out there, but it's designed with a 1:1
relationship in mind (one plugin = one effect). That's absolutely not
an LV2 weakness, it just does its job and nothing else (as it should
be).
Here I'm talking about a different problem: interoperability beetween
different processing paradigms, letting the user choose what he likes
more.

Regards,
Stefano
Received on Tue Jan 23 00:15:07 2007