[gmpi] Re: Topic 4: Host Interface
- From: "chris" <kjbeak@xxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Mon, 24 Mar 2003 20:04:12 -0000
On the topic of Rewire is there any reason GMPI cant define a seperate API
for inter application comunication? At least for syncronization and media
streams. It seems the main reason for Rewire and the need for 'out of
process' is for people to use two hosts at the same time, and i dont see
that the needs of that realy corelate with the needs of a plugin so to have
them both facilitated through the same interface seems stupid. It would make
more sense for the coexistant hosts to negotiate the number and direction of
streams between them via a seprate interface rather that having to design
the plugin interface to facilitate it.
Posibly almost the same functionality could be achived if hosts could host
other hosts? And mabey it would be cleaner this way?
At least GMPI should do whatever is practical to help 'out of process'
comunication. Although plugins should be in process simply for performance
reasons.
chris
----- Original Message -----
From: "Silver Blade" <lists@xxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Monday, March 24, 2003 5:36 PM
Subject: [gmpi] Re: Topic 4: Host Interface
> > 1. Are plugins run in-process or out-of-process?
> >
> > In-process, but they are allowed to be a proxy for an out-of-process or
> > network implementation.
>
> In an ideal world, I'd like to see out-of-process plugins. But we don't
live
> in an ideal world, so I'd say all plugins should be in-process.
>
> For networking, GMPI should provide means of communication over the
network.
> While this, in a sense, out-of-process, the only out-of-process thing
about
> it is that we're using the platform's networking functions, and the plugin
> is on a different computer.
>
> I mentioned a while ago on the vst-plugins list an idea I had about
creating
> a shared library that manages plugins and audio I/O for the entire system.
> Take WinSock, or the WinMM/mmsystem APIs of Windows as an example (or even
> the basic APIs for graphics/window management)... These must share data
with
> each other, otherwise how would EnumWindows() work?
>
> If we could implement a plugin architecture which could be shared among
> several processes at the same time, that would be brilliant - you'd be
able
> to use the same devices for several applications at the same time, as long
> as they used GMPI. Plugins, too, could be used this way - and of course
user
> interfaces.
>
> While I know technologies such as ReWire already allow communication
between
> separate processes, there must be a way of creating a library which can be
> loaded by the system and used by many processes - like a daemon/server.
>
> I'm not too hot on the technicalities of this though, so I might be
> completely wrong and this might just be impossible. But it's an idea, and
if
> it works, the results should be good.
>
>
>
> > 3. Is the host a plugin too? AND 4. Can the host be a chain of simpler
> > plugins (sequencer, timeline,
> > automation)?
> >
> > The host should be a plugin, plugins should be able to host plugins, and
> in
> > general the host and each plugin should be considered a node in a
> > synchronous data flow graph. In my view this is one of the most critical
> > requirements of the protocol, together with control data.
>
> As well as the host being a plugin, it should be allowed to run
stand-alone
> (goes without saying, really!)
>
> Plugins that have their own plugins could also be a possibility, although
> I'm not sure where this could be useful (perhaps an effect unit which
hosts
> other effects and provides a common front-end for them?)
>
> -SB
>
>
> ----------------------------------------------------------------------
> 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
----------------------------------------------------------------------
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:
