NSM, option to set --jack-transport from gui
grammoboy2 opened this issue · comments
Sync to jack transport can be enabled by -j, --jack-transport from the command line. NSM api doesn't support command line options to make session reliable, when under session management options should be able to set via the GUI. Most options seq192 provide are not needed when under NSM I think, but --jack-transport is. At least, I would like to be able to use jack-transport when using seq192 with NSM.
https://www.mail-archive.com/non@lists.tuxfamily.org/msg00446.html
@grammoboy2, Alternatively, you can add an executable 'seq192' to your $PATH, containing this:
#!/bin/bash
exec /usr/local/bin/seq192 --jack-transport
ok thanks, but I don't think these kind of 'hacks' makes session management reliable. In fact this might be even a good example of why such solutions should be avoided and why I'm in general being critical on your approach with RaySession.
If you name the wrapper script, the same name as the binary (seq192), whatever is first in PATH seems to be launched.
I don't get it working with nsmd anyway. It seems to work when you launch it outside the NSM manager when NSM_URL is set (which is not ideal for pid management I believe), but not when launching from the non-session-manager GUI.
A modular approach like with NSM has many parts, there are so many parts which can fail in the chain and this can make it a fragile and frustrating workflow. A lot should be done to make it reliable, to make it work. Anyway, read that message on the non mailinglist posted above.
As much as I respect NSM's author I strongly disagree. Not supporting command line arguments in NSM is a complete nonsense in my opinion, being able to load different sessions without restarting the clients is an unrealistic reason for doing so. I'm perfectly fine with the idea that there is a static state and a dynamic state.
I'm not saying I'm never going to add a way to set these from the GUI but I don't consider this to be an urgent issue, if an issue at all.
The way I see it, RaySession's flexibility is one its strengths, I would have stuck with ladish if it weren't there (don't get me wrong, I still think ladish is awesome).
You don't have to agree with the full 100% with a API, to comply to it anyway. Sure this is not documented officially, but there is the message on the mailinglist.
If you don't implement it in the GUI, then it means users of other GUIs then RaySession might not be able to use this feature. That's in general not what you want in such ecosystem. Backwards-compatibility isn't bad either in general.
Sure you can make of it whatever you want, but then again, that message on the list is pretty clear and that's not the translation you make of it now.
But these kind of discussions one has to go over and over again, makes clear for me that at the end session management on Linux will not really work. And why RaySession wasn't received with flowers and bells by everyone, cause this is a side-effect of it which people saw coming. Loosing compatibility and start all over again.
You can praise Ladish, that's fine, but it never reached the same support, compatibility and predictability as NSM. In a way I find you're taking the fruits of the NSM approach and the people who took care for it, but kill it's reached compatibility with the same ease.
Session management does work, it did with Ladish and it still does with RaySession, I've been working with the former on stage for years reliably and for months now with the latter. It's not plug and play though, and whether or not this is a problem is admittedly a subject I'm not very interested in.
The way I see it, I'm only taking the fruits of my very humble efforts (I'm just a spare-time developer) and make them available to whoever finds them useful and/or is willing to gets his/her hands dirty to make them fit into a particular workflow.
Seq192 has a config file but not for things like keybindings and such a setting as jack-transport?
I know suckless.org tools, don't have it by design. Then the user is able to edit the config.def.h file with all the configurations like keybindings, mv that to config.h and then compile it. I've good experience with such a approach, for fast and easy to compile (not dynamic) tools:
https://dwm.suckless.org/customisation/
https://git.suckless.org/dwm/file/config.def.h.html
Other tools work with environment variables:
SEQ192_JACK_TRANSPORT=1
or similar.
The disadvantage is that the user is less flexible of course, especially for GUI apps (for a cli app such env var is easy enough to set).
non-mixer provides also non-mixer-noui, which is a symlink to non-mixer, non-mixer then acts on the noui arg
https://github.com/linuxaudio/non/blob/master/mixer/src/main.C#L221
non-sequencer has jack-transport enabled by default.
Most options are just a compromise comparing to a setting in the gui imo, best user experience with be via gui.
Anyway, have good fun with it on stage.
Setting a environment variable is more flexible then I initially thought in this case I think.
I thought that setting a environment variable for a GUI application, would mean the user would have to log out and back in. But I think it only has to set the environment variable in the terminal, start the NSM server in the same terminal (could be done with a script), if then the NSM client is added to a session using /nsm/server/add (launched from a NSM gui or launcher), then the client is launched by the NSM server and in that case the NSM client is a child of the NSM server and inherits the same environment variables. That's how I understand it.
One can also set the environment variable early in the environment .xinitrc or similar, then the NSM client would always pick up that variable. But to change it, the user has to edit the .xinitrc file and logout/login I think.
A other way to do this, is setting NSM_URL as environment variable in a terminal (if it's not already set early in the environment) as well as the NSM client specific environment variable. Then the NSM client could be launched from that terminal.
I don't think setting the NSM_URL variable is the best thing to do though. Then the launched NSM client process is not a child from the NSM server process and that makes the pid management, which NSM is using less reliable (in theory). Ideally the NSM_URL is only set by the NSM server (disallowing clients to join other then via /nsm/server/add).
https://mywiki.wooledge.org/ProcessManagement?highlight=%28fork%29
That's just absurd. I'm not going to provide env var options when CLI args already do the job just fine. Regarding NSM I've made my point clear already and I'm not interested in debating this forever so please stop feeding this thread with what appears to be random personal notes and thoughts.
I don't think it's absurd. It just shows alternatives, in which you're not interested in apparently. Then I've to do it myself I guess, cause there are good reasons to avoid arguments in NSM imo.
A last thing that can't be missing I think to understand why NSM doesn't support arguments. Clients can have the capability to :switch:. This means that clients can switch to a other project without the need to restart. I don't think Seq192 supports this, but if it would be added later, then the possibility to allow arguments makes switching unreliable. When seq192 in a current NSM session uses jack-transport, it can't switch to a session with seq192 having jack-transport turned off. This is also true when using environment variables.
:switch: won't ever be added to seq192. This feature is the only argument I find somewhat relevant against cli args in NSM however while it's a nice idea in theory it's actually completely useless in reality. Multiple instances of an application with different cli args can safely be considered as distinct softwares. As I said, I'm not interested in debating this, further additions to this tracker on this matter will be considered as spam, you are free to take this debate somewhere else.