[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. 

not coming from me, that's for sure. i've made it clear that although
i think out-of-process connectivity is cool, i don't support it as
part of GMPI.

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

transport control has nothing to do with controlling the flow
graph. thats why i responded to ron's message in the way i
did. transport control determines what transport-aware nodes do when
they are executed. it does not control when they are executed or in
what order: that's the job of the host.

however, i think that any graph node can be the transport master.


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