[gmpi] Re: R: Re: Topic 4: Host Interface

It seems to me that in Topic 2 plug-in flavors, we didn't raise the possibility of using GMPI to connect standalone applications. I'm not against this, but I think it's a new direction in the discussion. If we restrict ourselves to plug-ins in the classic sense, then the "master" is implicitly the host, i.e. the application that creates and destroys the plug-in. The plug-in can query the master for different interfaces to do different tasks (gosh is this sounding too much like DirectX?). A plug in the classic sense would not be able to control data flow in the graph, so it would never have a transport control for example. If we want something like this, maybe we should lose the "P" in GMPI :-)

Bill

At 11:54 AM 3/27/03 -0500, you wrote: 
>Maybe the question "is the host a plugin", is the wrong question to ask.
>
>Instead, let's try considering the notion of a "masters" and "slaves" in a
>plugin environment.  In a traditional sequencer app, the host is the master
>and the plugin is the slave, which seems to imply that some control is doing
>unidirectionally, ie, tempo rate control.  Protocols such as Rewire are a
>bit more bidirectional, in that either participant can trigger the start of
>playback, or can request loop points, etc.
>
>So:  what kind of functionality is "master" functionality as opposed to
>"slave" functionality?  Should GMPI provide a way to designate that one
>component in its graph is the master?

this is an interesting question, but it seems to be on quite a
different level than the one originally posed.

controlling transport state is really entirely separate from the
host/plugin relationship(s). there seems to me to be no reason for any
participant in those relationships to have any priviledged access to
transport state - that should be defined by the user.

but the host will always have a priviledged position w.r.t. actual
execution; if you consider the host to be driven by an audio interface
interrupt (which is an extremely common though not universal
arrangement), then there is only ever 1 host because there is only
ever 1 point of entry for the interrupt into the entire host/plugin
network.

it seems to me there are two questions:

   * what controls transport state?
   * can a host be loaded as a plugin?

my answers:

* any plugin or the host, at the request of the user

   * for the host to be used a plugin, audio i/o has to be
      modularized ("plugin-ified") so that any given host
      can avoid requiring that it has access to audio interface
      h/w. that is, you have to be able to start a host
      in a way that tells it "don't try to use h/w, just
      run as a plugin". nothing wrong with this, but
      its a very specific requirement for host designers.

FWIW, over on the jackit-devel list right now, we've been thrashing
out what the shared transport state object should look like. any
participant in a JACK setup can be designated as the transport/time
master, and others are free to follow its "instructions", ignore them,
or just not care. working out what should be in this struct is
non-trivial, particularly for handling sync with other non-audio media
and non-linear motion (locates, loops, etc.)

--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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe


----------------------
Bill Gardner
Wave Arts, Inc.
99 Mass. Ave., Arlington, MA 02474
Tel: 781-646-3794   Fax: 781-646-7190
billg@xxxxxxxxxxxx


----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: