[gmpi] Re: 3.14 UIs
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 10 Jun 2004 10:12:42 -0700
On Thu, Jun 10, 2004 at 09:02:58AM -0400, Paul Davis wrote:
> 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
That's an exageration. The problem today is beyond that - poorly defined
de facto standards lead us to slighlty differing implementations, unclear
details and single vendors with too much control.
GMPI solves a LOT of those without ever going out of process.
> >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
First, I don't want to sound like I don't want this to happen. I do. I
want GMPI to take over the audio world. I want to have a render farm. I
want to control everything from everywhere. But let me ask a different
question.
WHat we need, if we want to define this remote mechanism is to define an
OSC-based protocol which addresses how to communicate with a GMPI graph,
right? Once it hits the edge of the GMPI graph, it becomes GMPI, right?
This specification, if I understand correctly, could be developed
ENTIRELY independantly of GMPI, couldn't it? So let's do that. I think
that it SHOULD be done, and that maybe this is the right bunch of people
to DO it. But I don't feel like it is part of GMPI directly.
In fact, it could be done today. It doesn't need GMPI. You could be
defining this protocol for all VST/AU/TDM/MAS/whatever hosts.
Let's do it, simultaneously, schedule the release for the same day, etc.
But it's a separate project.
> >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.
Sorry, I meant to imply that if an OSC-protocol is the right answer, why
don't we use that internally to GMPI hosts, much like X uses a socket
protocol, even locally. We can just be up front about the fact that all
plugins are using OSC. We don't need to make the host translate from
OSC->GMPI, we can just use OSC directly for all the inter-plugin comms.
VST used MIDI in much this manner, though they bumped into all of MIDI's
limits and added VST Automation and things like that...
----------------------------------------------------------------------
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:
