rncbc
NSM, qtractor dialog box is blocking nsmd
Some clients seems to cause nsmd to wait for replies, while that shouldn't be needed I think. This occurs often when Jack is not running. Your cool synth applications, just assume a user doesn't want to use Jack, reply to nsmd and launch normally, which seems reasonable and the right thing to do imo.
Qtractor on the other hand displays a dialog box and expects the user to click ok, before processing (which make nsmd wait for a reply to the open message).
Could you think about a solution for this for Qtractor? I've noticed the problem and suggested some possible solutions as a user, but you know better how your application should behave.
(Edit: the message doesn't get clicked away probably, because of the next 'sample rate dialog box'. So just this message isn't displayed twice) It seems I get this message twice (why twice?):
"The audio/MIDI engine could not be started.
Make sure the JACK audio server (jackd) and the ALSA Sequencer kernel module (snd-seq-midi) are up and running and then restart the session."
And I also got this message:
"The original session sample rate (48000 Hz) is not the same as the current audio engine (44100 Hz).
Saving and reloading from a new session file is highly recommended."
The first 'Jack not running issue' is handled by non-sequencer by just dying (SIGABRT, exitStatus: -1) and report a error logging message in red: [non-sequencer] Could not initialize MIDI system! (is Jack running and with MIDI ports enabled?)
As mentioned before, padthv1_jack would just go on without jack.
About the sample rate warning, that's probably a good candidate for such a dialog box, where the user needs to confirm 'ok'. But ideally it shouldn't block nsmd, especially because it replies 'ok' to nsmd afterwards.
Should it reply to the open message of nsmd with 'ok' or with a error when a sample rate mismatch is detected? Currently it replies ok after the user has clicked the dialog box.
From the API: "A response is REQUIRED as soon as the open operation has been completed. Ongoing progress may be indicated by sending messages to /nsm/client/progress. "
As reported here: https://github.com/jackaudio/new-session-manager/issues/92
qtractor goes on without jackd(bus) until you hit some operation that needs it to proceed correctly, always prompting that same error-message-box whenever jackd(bus) is not up and running--this has been its behavior ever since inception.
OTOH, re. the vee-one standlones, although they don't die their core functionality is severely NOOP when jackd(bus) is not up and running at the time of launch; unlike qtractor, they won't recover anyhow: you'll have to close the GUI (or kill the process) if you ever want them back in business.
I'll investigate if the response to nsmd may ever be sent as soon the NSM session is being opened...
qtractor goes on without jackd(bus) until you hit some operation that needs it to proceed correctly, always prompting that same error-message-box whenever jackd(bus) is not up and running--this has been its behavior ever since inception.
If that's the behavior you want from Qtractor, then only the startup phase is a problem, when using NSM I think, because the clicking dialog box is blocking nsmd. So reply with ok to open and then display the dialog box? Or display a notification without having to click it? If Qtractor is not really usable without jackd(bus), I as a user would say, fail loud and die with a clear logging message (without a clicking dialog box). I as a user would need to exit the applications anyway, before I start jackd(bus). If it's already killed, that's saves me a action. :)
OTOH, re. the vee-one standlones, although they don't die their core functionality is severely NOOP when jackd(bus) is not up and running at the time of launch; unlike qtractor, they won't recover anyhow: you'll have to close the GUI (or kill the process) if you ever want them back in business.
Then I would say, die with a clear logging message to stderr, without the need for the user to click a button.
I'm not sure when the detection is Jack not running happens. Is it before or after 'announce to nsm' and getting the open message from nsmd? If it's after it, then it might be best to reply with a error, possibly sending a status message (see below) and then die (which nsmd will detect)? Then the app could exit nicely with 0 status? Non-sequencer dies by SIGABORT (-1), not sure what the most appropriate way is. .
There is also a :message: feature in NSM,
Clients may send miscellaneous status updates to the server for possible display to the user. This may simply be chatter that is normally written to the console. priority should be a number from 0 to 3, 3 being the most important.
Clients which have this capability should include :message: in their announce capability string.
The other part of the story is that nsmd waits up to 60 seconds for replies, if it has waited for 60 seconds, it continues it's procedure the same way as when all clients responded quickly. So not clicking the 'ok button' in Qtractor, doesn't affect the outcome of the nsmd procedure (open session) (Loaded, Done). https://github.com/jackaudio/new-session-manager/blob/master/src/nsmd.cpp#L656
So how I see it at the moment, it's a client issue. It let's nsmd wait for something which will happen anyway, respond ok to open. That session is then opened successfully, cause Qtractor just gives a warning, it's state is ready after clicking the warning/dialog box.
If Qtractor would responds ok to the nsmd open message and give a dialog box afterwards, the user/ nsmd has loaded a session successful, but get's a warning.
But Qtractor might then not be ready for other clients yet. So that might be a problem, if application X depends on Qtractor to be fully loaded and ready to go, then that dialog box which still has to be clicked sits in the way.
But if the 60 seconds waittime of nsmd is exceeded, nsmd will give the same 'session is loaded' message and then Qtractor wouldn't be ready either.
Note that non-mixer also show a dialog button when Jack is not running, which has to be clicked and it replies to open with ok after the user has clicked some dialog buttons (same as Qtractor). Is it usable without Jack? I don't think so, so why doesn't it die like non-sequencer and non-timeline*?
- [non-timeline] Could not connect to JACK! [nsmd] ../src/nsmd.cpp:350 handle_client_process_death(): Client Non-Timeline.nJARI terminated itself.
Quote from api:
"Accepting this :message: is optional. The intent is to signal to clients which may have some interdependence (say, peer to peer OSC connections) that the session is fully loaded and all their peers are available. Most clients will not need to act on this message. This message has no meaning when a session is being built or run--only when it is initially loaded. Clients who intend to act on this message MUST not do so by delaying initialization waiting for it. "
Building seems fine, but sudo cmake --install build fails:
-- Install configuration: "Release" CMake Error at build/src/cmake_install.cmake:52 (file): file INSTALL cannot find "/home/user/git/qtractor/build/src/qtractor": No such file or directory. Call Stack (most recent call first): build/cmake_install.cmake:47 (include)
Building seems fine, but sudo cmake --install build fails:
this seems a unrelated to the issue at hand; please remove the "build" sub-directory before retrying the build ...
please remove the "build" sub-directory before retrying the build
Still same error.
rm -r build cmake -B build sudo cmake --install build
The same files which are in build are also in src.
qtractor]$ ls build/ CMakeCache.txt CMakeFiles cmake_install.cmake Makefile src user@archhost qtractor]$ ls build/src/ CMakeFiles cmake_install.cmake config.h Makefile
When I run make manually, it works.
I get this message twice indeed, there's something wrong:
The audio/MIDI engine could not be started.
"Make sure the JACK audio server (jackd) and the ALSA Sequencer kernel module (snd-seq-midi) are up and running and then restart the session."
Ok, it replies 'Ok' to nsmd now and shows the error dialog box after it. I think that's indeed preferable in this case. Qtractor should be functional without Jack according to it's developer, so it don't die, but it gives a warning.
You solved the 'qtractor blocks nsmd problem' (yeah!), but there is still the dialog box which the user has to click (along with the other 5 apps who show the same kind of dialog box), that Jack is not running. I think it would be best to only show that dialog box when the user hits a function that needs Jack, and skip the one right after session load. Let me fiddle with it.
Did you decide on your synths yet? I think it would be best to let them die, when they need jack and there is no jack.
Cool, thanks for thinking with me. These decisions are more complex then it looks at first sight.
Saw this commit: https://github.com/rncbc/padthv1/commit/871485980356f02bfe010e28b34c22abb2992a2d
It looks like Carla is able to restart it's engine, when Jack is initially not running. So Carla starts normally (but suffers from the same blocking nsm server issue) and is then able to restart it's 'engine' after the user has started Jack. This seems to only work if a loaded project doesn't need Jack though. If the user has a plugin loaded that needs Jack, it seems to get lost, when a user starts Jack and then starts the engine. The user gets a empty project (likely potential serious issue). This can be fixed by stop/resume Carla from the NSM gui. So, also in this case, the application blocks the NSM server, asks the user to click some buttons, but at the end it's needs to be restarted (if the loaded project is not empty).
FYI: this case might help you thinking out a solution.
Note, a NSM client who died, is visible in the NSM gui. In my workflow I look why it died and would expect to find the cause in the log of the NSM server or via a 'Gui message', which the server sends to the NSM Gui. I can imagine that this is typical for NSM. When a typical (Gnome/ Kde) Desktop user doesn't use NSM, I can imagine dying might not be the best option and a dialog box is a common solution in such a scenario probably.