debugging NSM clients (launching in terminal)

[grammoboy2]

I read about the feature "Launch the program in a terminal. Mostly for debug purpose."

It caught my attention, cause I was thinking about this as well (without having a lot of experience with debugging) and I am wondering: wouldn't be the easiest way to debug NSM clients, when the NSM client does a getenv for a debug environment variable?

For example:

AMS_DEBUG=1

This could be set in the same environment as the NSM server is starting in, so the client gets its own copies of these. AMS could do a getenv and if AMS_DEBUG is found and 1, turn on debugging. The server is possible to set the file descriptor of the client for logging I would think.

Then the developer sets the environment variable, starts the NSM server in the same terminal and adds the client via /nsm/server/add.

[Houston4444]

I don't see anything in what you say that is not perfectly doable by the dev without modifying the session manager (or maybe I don't understand something).

This is quite boring though, to need to restart server each time you restart your client, especially if your session needs a big program such as Ardour (with a long startup). Use client environment variable or argument is easier.

[grammoboy2]

If I'm the developer of AMS, AMS might have a argument option --debug, which NSM doesn't support. This could easily be solved imo, by letting AMS do a getenv for a debug related env variable, pure a client thing, no need to adjust the session manager.

Sure, that dev needs to restart the server or set the debug env var early in the environment if they want to debug it by default. Only once though, not every time you restart the client. Not a big thing imo.

edit: restart of the server is not needed if it can handle a request via OSC to set a env var.

What I don't see, is why you want to start a client in a terminal. Messages to stderr or stdout can be redirected to the terminal/logging file by default right? Isn't that what nsmd is doing?

[Houston4444]

What I don't see, is why you want to start a client in a terminal. Messages to stderr or stdout can be redirected to the terminal/logging file by default right? Isn't that what nsmd is doing?

Of course stderr and stdout are redirected to output of the daemon. In ray-daemon, with the help of Qt, ray-daemon says which client is speaking, this is practical, but I saw that in some situations the messages are very delayed, and it is particularly annoying when writing audio plugins. So, start the client in a terminal is a good way to ensure messages are coorectly sorted and not delayed, more, if for any reason a client is not working correctly, it's fine for user to just restart it in terminal to know what happens, especially if raysession was not started from terminal.