Open sessions with clients stopped
grammoboy2 opened this issue · 2 comments
One of the differences between raysession and nsmd is that raysession allows sessions to open including NSM clients which will not launch (have status stopped).
In nsmd this would cause JACK connections, not being saved. I guess this is not the case for Raysession. So the tool that saves the JACK connections, knows the status of the NSM clients (via osc) in RaySession?
I can think of two reasons why this might be useful.
- a alternative for show/hide the GUI.
- less system resources being used + faster launch of session
Any other reasons I missed here?
I could think of several alternatives for the problem here:
Alternative for 1:
- implement :optional-gui: capability in the NSM client
- use a good Desktop Window Manager
(move app to different WM desktop, let app launch on specified WM desktop) - temporarily stop a NSM client during a session
(with the disadvantage that a user might need to restart it before saving a whole session,
at least when using the original JACKPatch).
Alternatives for 2:
- write / use light tools (unix / non philosophy),
- buy a more powerful computer,
- share resources by using multiple computers via netjack / zita-njbridge and NSM network sessions.
- temporarily stop a NSM client during a session
(with the disadvantage that a user might need to restart it before saving a whole session).
I saw Guitarix has a 'bypass' option, not sure if this also lowers the use of system resources.
Makes me wonder how this works for plugins, is hiding or bypassing a plugin, lowering the system resources?
Would it be possible to make a JACK client lower it's system resources via some kind of 'bypass' functionality?
A disadvantage when you allow to start with stopped clients in your session, is that it adds more complexity to the session management system I think. It's conceptually more simple and stupider to just take one scenario into account, all clients should launch. Session management is already complex enough one could argue.
It also is a conceptual change comparing to the original nsmd / API. When nsmd sends the message 'session is loaded' to the NSM clients, it is assumed that a successfully loaded session, is a session where all clients (ideally) have been launched, announced, opened and so have status 'ready', I think. This conceptual difference might effect the NSM client API in the future (theoretically) and is something to keep in mind.
Any idea how much this feature is used by raysession users?
Any idea how much this feature is used by raysession users?
No idea, many for sure, including me, maybe almost. TBH, I don't consider this as an additional feature compared to nsmd, it is just absolutely required (for the second reason: less system resources being used + faster launch of session).
A disadvantage when you allow to start with stopped clients in your session, is that it adds more complexity to the session management system I think. It's conceptually more simple and stupider to just take one scenario into account, all clients should launch. Session management is already complex enough one could argue.
No, it is not so complex. For me as user, when I realized that NSM did not remember if the client were started or not, my reaction was to consider this session manager as immature.
No, it is not so complex.
Raysession warns when I stop a client which has capability dirty and is dirty, but for clients that don't have and can't have capability dirty (zynaddsubfx, complex to implement), it doesn't warn. So if you stop Zynaddsubfx and then save and close the session, you could loose some data unintentionally.
Every time a warning dialog when you stop a client can be disturbing (can be set off) and goes against the idea of the API a bit I think:
"Clients will receive the Unix SIGTERM signal and MUST close cleanly IMMEDIATELY, without displaying any kind of dialog to the user and regardless of whether or not unsaved changes would be lost."
https://non.tuxfamily.org/nsm/API.html#n:1.2.2.1.
How do you distinguish between a application that is stopped intentionally or not? I guess you could determine the exit status, but I doubt this is the case at the moment.
If a application is not available in PATH anymore, you won't notice it when you launch the session, until you launch the application with stopped status. This is not so much of a problem probably.