2007/1/24, Jay Vaughan <jayv@email-addr-hidden>:
> At 20:08 +0100 22/1/07, Stefano D'Angelo wrote:
> >What I'd like to work on is a sound processing architecture (LADSPA,
> >VST, DSSI, etc.) wrapper, which hides the details of a particular
> >implementation to audio program developers.
>
> Nice idea. Already done:
>
> http://teragon.org/products/PluginCore/
>
> >What do you think about it?
>
> Would be nice if there were a GPL effort in the same way ..
>
> --
>
> ;
>
> Jay Vaughan
>
>
Well, it seems like LV2 can do (at least theorically) all of these
already, altough some things might be a bit tricky (read the rest of
the conversation).
Now I'm seeking whether this approach (LV2 bridges plugins) can
present practical problems and, in such case, I think it's better to
solve them in LV2 than restart from scratch.
To be true, there are two things I'm concerned about: one (less
relevant, maybe) is RDF files... a bridge plugin should generate them
for all installed plugins when it is loaded, and so it has to contain
(or link to) code that can handle such syntax (I really don't
understand why LV2 developers choose such language instead of XML,
which is much more known and supported).
The other one is more serious (but should have been also faced by
vstserver, fst and dssi-vst): I'm talking about logical compatibility
beetween LV2 and other standards (VST in this case) in handling some
tasks (settings and session storing, banks/effects/programs metaphor,
etc.). Does anyone know about these matters?
Then I think that it would be nice if some GUI programs could take
advantage of trapping Xlib (or whatever) functions (LD_PRELOAD?) in
order to embed plugin GUIs inside the app and/or have a library that
autogenerates GUIs for non GUI-plugins (well... the XML GUI
specification for LADSPA has been dropped in LV2 in favour of
extensions?).
... it's such a complex matter :-P
Regards,
Stefano
Received on Wed Jan 24 20:15:04 2007
This archive was generated by hypermail 2.1.8 : Wed Jan 24 2007 - 20:15:04 EET