You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is no nsmd/OSC way to ask for a client list if the session is not loaded. Even within a loaded session only the single registered /nsm/gui/announce_gui program must parse client announce and status messages in realtime and save them internally.
Proposed is a new OSC message that would instruct the server to send a list of clients to the requesting osc-address (or more information about the session, see below). This is a change in the API and requires a MINOR version increment, because it doesn't change existing behaviour and only adds new message.
With this addition all requesting clients, not only the single registered GUI, could work with the client list. This is a requirement for non-music-clients that want to watch the session-state: For example JACK-connection savers, display manager position savers, statistical loggers for professional musicians (how much time spent, which software is used the most) and more.
Ideally this message would be available at any time, no matter if a session is currently loaded. Getting information about sessions without starting all clients can provide a GUI with information for overviews.
As a proof of concept I programmed my Argodejo GUI to open all session.nsm files itself for a preview, check the timestamp of session.nms and in a running session, since it is the announced GUI, mirror that data to internal memory.
This is incompatible with networked sessions, especially distributed, because the GUI does not have access to the above files.
In network-sessions the different nsmd-servers could exchange and relay these information internally.
The text was updated successfully, but these errors were encountered:
Additionally, the server could report PID of the client as well. It already has a list of them stored.
For a tool that could save window positions, this is a requirement.
We can find X11 windows by pid, so that we can match nsm clients to visible Windows. Using the window title matching to client name is problematic, requires fuzzy searching through the desktop windows so not very nice.
No idea about wayland.
PS: I know using PIDs is not portable, since this is a POSIX concept and other architectures like win32 do not use them.
But PID is part of the core NSM protocol, so we are still acting within the constraints of NSM. (clients report their PID to NSM during announce, and this is the PID that a client could request from the server)
Currently there is no nsmd/OSC way to ask for a client list if the session is not loaded. Even within a loaded session only the single registered /nsm/gui/announce_gui program must parse client announce and status messages in realtime and save them internally.
Proposed is a new OSC message that would instruct the server to send a list of clients to the requesting osc-address (or more information about the session, see below). This is a change in the API and requires a MINOR version increment, because it doesn't change existing behaviour and only adds new message.
With this addition all requesting clients, not only the single registered GUI, could work with the client list. This is a requirement for non-music-clients that want to watch the session-state: For example JACK-connection savers, display manager position savers, statistical loggers for professional musicians (how much time spent, which software is used the most) and more.
Ideally this message would be available at any time, no matter if a session is currently loaded. Getting information about sessions without starting all clients can provide a GUI with information for overviews.
As a proof of concept I programmed my Argodejo GUI to open all session.nsm files itself for a preview, check the timestamp of session.nms and in a running session, since it is the announced GUI, mirror that data to internal memory.
This is incompatible with networked sessions, especially distributed, because the GUI does not have access to the above files.
In network-sessions the different nsmd-servers could exchange and relay these information internally.
The text was updated successfully, but these errors were encountered: