[gmpi] Re: Topic 4: Host Interface
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 24 Mar 2003 11:35:37 -0800
1. Are plugins run in-process or out-of-process?
I've never written a plug-in host, so this question may seem naive,
but: How explicit does this really need to be? Would there be a
significant downside to just making the rule that the DSP
gmpi::process() function needs to be thread-safe with respect to the
plug's other functions (control & GUI )? Seems like then the host
can run the process() thread either in-process or out-of-process
(with respect to its main thread) however it likes. Enlighten me?
2. What kinds of special needs are there in events to/from a plugin?
I would like to see the work include an investigation into the idea
(previously suggested by many) that GUI (including perhaps GUIs
distributed across machines, networks, or processes) could perhaps be
handled in part via a message/event interface (not only a
VSTGUI-style API). If this turns out to be too much of a
complication then it should not be included, at least not in the 1.0
spec. But if it can be done in a simple yet powerful enough way,
there may be worthwhile advantages in terms of system architecture
flexibility.
3. Is the host a plugin too?
Agree that we should preserve the possibility of plugs-within-plugs
until and unless a compelling reason to do something to preclude that
arises. Guess this depends in part on whether there's a requirement
to send parameter-setting commands to an 'inner plug' from anywhere
outside of its 'outer plug', and similar GUI issues. I mean, it's
hard to see how you could prevent a plug from calling the ::process()
functions of a bunch of sub-plugs it's decided to manage on its own.
4. Can the host be a chain of simpler plugins (sequencer, timeline,
automation)?
This is interesting and would IMHO need to be looked at more closely
before we could make a good decision about whether this is a
requirement we really want. It may introduce non-obvious design
requirements. In other words, it would mean that plug-ins would have
to be able to act as sources for all system-control information that
plug-ins can consume, at least to the degree necessary to assemble a
complete basic SW music system.
5. Does the host interface provide transport control, UI updates, track
information?
Can I get some clarification here? Does this mean that the plug-in
would be able to control these things, or query them, or that the
plug-in would get (or be able to ask to get) events? Probably some
mix of the above, yes? NB, this relates to #4 as well.
-- Chris
----------------------------------------------------------------------
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:
