[gmpi] Re: Reqs draft
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 10 Nov 2003 17:25:48 +0100
On Monday 10 November 2003 15.28, Vincent Burel wrote:
> ----- Original Message -----
> From: "David Olofson" <david@xxxxxxxxxxx>
> To: <gmpi@xxxxxxxxxxxxx>
> Sent: Monday, November 10, 2003 2:58 PM
> Subject: [gmpi] Re: Reqs draft
>
> > On Monday 10 November 2003 14.49, Vincent Burel wrote:
> > [...wrappers wrapping wrappers...]
> >
> > > :-) yes and if there is a GMPI to VST wrapper you make an
> > > : infinite loop -))))
> >
> > Yeah, that's an interesting problem. :-)
> >
> > I suppose other plugin APIs have solved this already (and if not,
> > we can't fix that anyway, as it's down to the respective wrapper
> > plugins), so we only have to define a stop condition for GMPI
> > wrapper plugins. "GMPI wrapper plugins should not wrap GMPI
> > wrapper plugins" sounds nice, but requires that wrapper plugins
> > are hinted as such in one way or another.
>
> wow ! :-) this is a little bit ridiculous, why the GMPi host would
> have to list the plug-ins managed by wrapper !? this makes no sens.
The GMPI host would just list installed plugins available to the user,
wrapped as well as native. How does it *not* make sense to just list
all of them, regardless of native API?
> Only the wrapper is able to make the list of plug-in dedicated to
> him , this can be audio proprietary plug-in as well than completely
> different plug-in not related to audio stuff.
Sure, and of course, there are cases where the wrapped plugins are too
different from GMPI plugins for it to make sense pretending that
they're native GMPI plugins. In such cases, it may be more
appropriate if the wrapper plugin acts more like a modular synth,
where the "internal" plugins and net building is invisible to the
GMPI host. Of course, then the wrapper needs a net building GUI and
internal project management and stuff as well. And, the wrapper must
obviously be able to store it's internal net and configuration as
part of a project, just like other GMPI plugins store their settings.
> Well, GMPI host list
> GMPI plug-ins (wrapper or not) and that's all...
If a wrapper plugin simply pretends to be a normal GMPI plugin DLL
with multiple plugins; one for each wrapped plugin; the GMPI host
won't even know it's running wrapped plugins, as far as
instantiating, running, controlling and destructing plugins is
concerned - and that could include detecting the plugins.
Now, I'm having some trouble seeing how it makes sense *not* to list
the wrapped plugins...
It's easy to dream up examples of wrappers where this breaks down, but
I'm quite sure most people first of all will want to run their old
VST and DX plugins in new applications. If those plugins are not
sufficiently similar to GMPI plugins, WTF are native GMPI plugins
supposed to be like...? :-)
That is, of course, assuming that we don't have a hidden agenda where
we intend to "gently" force all users to upgrade all foreign plugins
to new GMPI versions ASAP. ;-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
