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