[gmpi] Re: 3.9 (draft) use cases and stuff

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 27 Feb 2004 18:05:43 -0800

On Fri, Feb 27, 2004 at 05:15:14PM -0500, Ron Kuper wrote:
> This is great, Tim.  You are showing incredible tenacity on driving this
> discussion home, I really appreciate it.   I've been reading the thread

Somebody has to, and I seriously get excited by all this sort of stuff :)

> >>>
> * It is REQUIRED that GMPI allow a plugin to control the tempo of other
>   plugins.
> <<<
> 
> Can the requirements stipulate that the host be the multicaster of
> tempo/meter changes?  If we do that, though it probably means limits 1
> tempo/meter context for the world, the host can coordinate when updates
> happen, simplifying implementation.

Can you go a bit deeper?  You seem to have something more specific in mind -
some issue or potential difficulty?

> >>>
> MODEL 1: Traditional-ish
> <<<
> 
> I personally would be satisfied if GMPI's model was the best of (VST(i),
> DX(i), Rewire).  For this reason, model 1 is mostly it.  The one missing

I originally would settle for no less than a fully-modular solution.  Having
discovered some of the complexities, I think I am now on the fence.  I
certainly see the benefits of being totally modular, but some part of me
nags that very few hosts will truly support it, and those that do not will
probably be the big boys.  And if only "fringe" hosts support it, is it
worth the effort?  Assuming the effort is, in fact, significant.

> element is something Rewire provides, namely the ability for a plugin to
> "request" reposition events, tempo changes, and transport control.  Note
> that this is a request that the host needn't obey.  The Rewire data pump

So this would add locate and transport controllability to plugins, in the
same manner that I described tempo and transport?  I don't see that as a big
problem, if this is the model we run with.  The biggest problem I see is the
whole bit about optional features.  We already have a case where some class
of tempo-controlling plugins are basically left without a market because the
big boys don't care to honor tempo-change requests.  If that is what we're
going to do again, why bother?

> >>>
> MODEL 2: Modular
> <<<
> 
> I think 1 and 2 might not be mutually exclusive.  If the host is the
> ultimate arbiter of tempo/meter/time and multicasts changes to all
> plugins, maybe it's possible to build a modular environment.

That is only partially modular then, probably.  The host supports 1 tempo
controller per "graph".  The host can bridge graphs if it wants to allow
that.  Is that really useful?  It allows you plug in your favorite
sequencer plugins, I guess.

I think the biggest differentiator between the models is conceptual
complexity more than actual complexity.  There are still the same number of
signals flying around in the same setup.  But the modular method allows you
to do things that result in awkward edge cases.  By cutting out the
flexibility we eliminate the need to handle those edge cases.

I'm trying to find an illustration (I work visually) that really shows me
where the problems are.  Meantime, I'm looking for strong opinions to help
me figure it all out :)

-- 
Tim Hockin
thockin@xxxxxxxxxx
Soon anyone who's not on the World Wide Web will qualify for a government 
subsidy for the home-pageless.

----------------------------------------------------------------------
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: