[gmpi] Re: 3.14 UIs
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 04 Jun 2004 20:32:58 -0400
>I think we enforce DSP/GUI separation, but we design the interface
>boundary in such way to be remoteable, yet efficient when running in
>process. Maybe we can include an IPC toolkit as part of the GMPI
>deliverable to do the remoting for applications that want it.
if you write the GUI to run in-process, you can't remote it. if you
write it to run remotely, you can't run it inprocess. well, sort of ...
if the GUI is in-process its started by the host (ie. loaded and then
executed via some kind of startup entry point). if its out-of-process
the host *might* start it, but by forking a new process and execing
the GUI code in that new process. if its remote, the host has nothing
to do with it, essentially.
i don't think you can create a GUI that can be used in each of these
situations.
otoh, we obviously want the simple case to just work: host loads
plugin, host starts GUI, bingo. so what does that mean? what does the
host do when this happens?
well, the obvious approach is something like this:
a) host-initiated in-process GUI
host loads shared object
calls well-known entry point
GUI/host communication via a defined communication
mechanism (e.g. a socket using OSC)
b) non-host-initiated GUI
host does *not* load shared object
user starts GUI (same machine, or different), using
some platform-dependent approach (e.g. cmdline,
mouse click on icon, whatever)
GUI connects to a well-known socket on host(+machine)
host tells GUI how to address the DSP
GUI/host communication proceeds using same defined
mechanism as in (a)
is everybody happy with that? it violates ron's goal of "efficient in
the in-process case" - nothing will be as efficient as assuming you
share address space with the DSP and so can just access its variables
etc. and nothing will even be as efficient as using a defined function
call interface for the DSP/GUI communication. so there is going to be
a tradeoff here. either we have a mechanism in which the
remote/out-of-process GUI falls out naturally, or we don't. using any
kind of abstract interface that can be rendered using network
communication inevitably has a real (though in practice, extremely
small) cost. the benefit is scalability, flexibility, robustness, and
portability. want to run a 50 disk-based sampler instrument plugins on
a render farm of cheap headless linux systems but have the GUIs popup
on your windows/macosx box? no problem. want to run just one instance
of the same plugin in a DAW, and have the GUI come up on the same
system, without any new version of the plugin?
*that* is a future that interests me ...
--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
Other related posts:
