[gmpi] Re: 3.14 UIs
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 10 Jun 2004 09:02:58 -0400
>I agree completely that we can do a wonderful protocol, I still think
>it's not ours to do. OSC exists. Any host which wants to allow
>OSC remote control can do it today. Piggy-backing this on top of GMPI is
>not going to help GMPI nor will it help OSC, I think.
Nobody is trying to help OSC.
Part of the original meta-cloud surrounding the efforts to define GMPI
was to design a plugin API that was capable of surviving the
transition to "the next generation" of audio environments. It hasn't
been disputed that things like render farms and other related designs
that run the DSP on devices without monitors are a part of such
future (and even present-day) environments.
Defining the relationship between the plugin and its GUI is clearly a
part of defining a plugin API that can handle such environments. If
you want to punt on this, and simply say "we define the relationship
between the host and the plugin, the GUI interacts with the host
*only*", then that's certainly an approach to the problem.
The result, however, will likely be an exact mirror of the major
reason why this effort on GMPI was started: fragmentation, duplication
of effort, etc. etc. There will be UIs that only work as remote
controllers with hosts X and Y. There will be hosts that only work
with a specific class of UIs. So great - the DSP part is all in
common, and we get rid of the "oh, we haven't done an MAS version of
our plugin" (yeah, sure it does - "oh, we haven't done a GMPI version
of our product - but thats a business issue, not a technical one). But
the UI/control element implicit in "next generation" audio will be
left up to individual host developers to figure out.
I think that's a needlessly useless outcome. And to be honest, I must
admit my complete lack of patience with this "host differentiation"
argument. I am in this for *users*, not company benefits. Designing a
scheme in which its not implementation quality but actual features are
left (un|ill)-defined in order to allow companies to differentiate
their offerings from one another ... this leads us to precisely where
we are today with plugins (and a lot of other stuff).
>My point is that OSC already exists. If it hasn't taken off on it's own
OSC *has* taken off on its own merits. Its biggest problem for years
has been the appallingly terrible "reference implementation" that put
off a lot of developers from using it. But its now used by several
significant pieces of commercial software, and a similar number of
libre software as well. There is at least one clean independent
implementation (liblo - nods to steve harris), and I imagine that
Native Instruments and others have their own.
>merits, then ladening GMPI with it is not going to help our cause - which
>is a cross-platform IN-PROCESS plugin API.
See above.
>Further, if we *did* decide that OSC (or something) is the remote control
>API, then why are we spending so much time on GMPI? Just mandate that
>same API for all plugins and be done with it. We can provide some simple
>API for plumbing audio data, and the rest is done.
Because you know as well as I do that such designs (JACK) don't work
well on Windows, and that even on OSX and Linux they incur a small but
not insignificant overhead that makes large networks of "plugins"
impractical.
>http://www.gmpi-plugins.org/gmpi/requirements.php#sec_3.14
It captures the general mood of what has been said here, yes.
--p
----------------------------------------------------------------------
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:
