[gmpi] Re: 3.14 UIs
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sat, 5 Jun 2004 14:29:07 +1200
Hi Paul,
> 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.
I'm hoping the same GUI can be run either way.
>... 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.
I agree with your analysis, but there may be a 3rd option....with no
tradeoff.
a) host-initiated in-process GUI
- host loads shared object
- GUI/host communication via a defined function call interface
(setParameter() etc)
No performance penalty. No complex code. Easy as VST.
b) out of process or remote GUI
- mini-host loads shared object
- mini host connects to well-known socket on host(+machine)
- mini host forwards setParameter() calls to 'real' host via network or IPC
The mini host is really not a host at all, it present's the 'facade' of a
host, a handfull of function calls to fool the GUI into thinking it's
talking to the real host. It's just a lightweight translation layer between
plain old function calls, and the network protocol.
The exact network protocol is not important. It is interchangeable. You
could use OSC, you could use a socket, you could use TCP, or any other
inter-process communication method. You just write a new mini host.
The advantage is:
-GUI can run in-process with no overhead.
-GUI can run remotely without re-writting.
-Plugin writer is shielded from complexity.
-inter-process communication method is interchangeable. You could use TCP
on Linux and sockets on Win32 ( hypothetical examples). You could use OSC.
Hope that makes sense.
Jeff.
----- Original Message -----
From: "Paul Davis" <paul@xxxxxxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Saturday, June 05, 2004 12:32 PM
Subject: [gmpi] Re: 3.14 UIs
> >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
>
>
>
----------------------------------------------------------------------
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:
