search

Houston4444 / RaySession

Session manager for linux musical programs
GNU General Public License v2.0
166 stars 18 forks source link

add a remote-gui capability #43

Open Houston4444 opened 4 years ago

Houston4444 commented 4 years ago

I think to add ':remote-gui:' capability to the server capabilities.

NSM can hide/show GUIs client if client has :optional-gui: capability, but it is not enough I think. In this existent case both GUI and engine of the client run on the same machine, and in almost case, show/hide GUI in NSM server only show/hide the main window (and doesn't stop GUI process).

The main goal of this new feature is to have a remote GUI for an NSM client running on another machine.

The idea is that client should have :remote-gui: capability. In this case, after NSM server registration, client will send to server an executable as argument to OSC path /nsm/client/remote_gui_executable (for example). Then, a new "remote" button will be available on RaySession window (or other NSM server GUI) similar to the 'GUI' client button. When user click on it, RaySession's GUI will start a process with the given executable and the client OSC port as argument.

Example with carla (supposing a carla_engine NSM compatible executable exists).

add NSM client carla_engine (executable) carla_engine -> NSM server : announce with ':remote-gui:' capability

carla_engine -> NSM server : /nsm/client/remote_gui_executable carla_control NSM Server -> NSM GUI :+1: /nsm/gui/client/remote_gui carla_control $client_url

Now in NSM server GUI, client can click on the client remote icon. Then NSM server GUI launch process: carla_control $client_url

The remote should be closed with SIGTERM (by server GUI) when the client engine is stopped (from user or for another reason).

How does it sound ?

eeickmeyer commented 4 years ago

I like this idea, FWIW.

falkTX commented 4 years ago

carla-control needs to know the OSC URL and ports of the main instance in order for this to work. so the remote executable would need to allow CLI parameters (contrary to main NSM) in order to pass these.

brummer10 commented 4 years ago

For guitarix, just start the remote UI, as long it is in the same LAN, it will connect via AVAHI handshake.

falkTX commented 4 years ago

what if there are 2 instances of guitarix running, how does it know which one to connect to?

brummer10 commented 4 years ago

If there are two instances, the GUI process will pop up a window to let you select which engine you would control. And, you could use multiple GUI's to control one engine, but you can't control multiple engines with one GUI.

Houston4444 commented 4 years ago

@falkTX arguments are not a problem here. There are already a lot of messages in raysession<->ray-daemon accepting indefinite number of arguments in the case they all are strings.

@brummer10 TBH, I'll prefer that a remote connect directly to the good instance if there are many running. Simpler and less confuse for user.

maybe we could also let the client send all the arguments he wants, with auto-replace of patterns such as $OSC_URL, $OSC_PORT, $HOSTNAME or whatever.

brummer10 commented 4 years ago

Currently I cant say much to this, as we didn't have a OSC interface implemented. We use rpc via (web)sockets to communicate between GUI and engine. So, I don't know what I need to make the initial connection via a osc call. For sure, we need command-line args pass to the GUI instance.