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


Simple, obvious, example: in Cubase VST, the "graph" (really just the
audio engine and a MIDI front-end) is running even when the transport is
stopped.

Good example, thanks. I'm on board with the idea that transport control can be given to a plug either via an interface or via some event protocol.

I'm understanding correctly, a plug would communicate to the rest of the world in three ways: a number of synchronous pins for sample data, a number of asynchronous pins for events, and a direct connection to a single host for access to interfaces. All of this is done in a single process address space. The host would be responsible for maintaining the graph state and providing interfaces. So a plug attaches to the graph by getting some interfaces from the host, and the interfaces are used somehow to attach the pins to the graph, all mediated by the host.

I have a question about what functionality should be provided via event streams versus interfaces. For example, automation data could be events sent on pins (and thus plugs could be sources of automation data), or it could be done via an interface. One important issue is buffering, events can sit in buffers whereas interfaces are immediate. Another is the duplex issue, if you want an immediate response an interface seems to be the way to go. So for automation, I can imagine having both a parameter interface that describes parameters, converts from values to text, etc., and having the automation data sent to the plug via an asynchronous pin.

Bill

At 07:20 AM 3/28/03 -0500, you wrote:
On Thu, 27 Mar 2003, Bill Gardner wrote:

> I must be missing something. I have a very centralized view of the host as
> the master of timeline, data flow, and external I/O devices. The host is
> often the source of time ordered content such as sample data, musical
> events, automation. How can transport control (stop, rewind, play) not be
> related to controlling the data in the flow graph?

Simple, obvious, example: in Cubase VST, the "graph" (really just the
audio engine and a MIDI front-end) is running even when the transport is
stopped. It's easy to envisage a Reaktor-style environment where there
may be several different transport masters existing within a single
synchronous signal flow graph.

> In my centralized view, this could only happen if the host provides an
> interface for a plug to control the transport.

Plug-ins can advertise their ability to be transport masters, and their
requirement for receiving transport information. It's up to the host to do
what it likes with that.

Regards,
        Angus.


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