houston4444 wrote: ↑Thu Mar 30, 2023 5:21 pmMight be nice to be able to 'announce' the patchbay as standalone (Patchance) to other NSM servers as well
I considered this solution before to develop the patchbay (patchbay as NSM client), but there are big disadvantages:
- The patchbay is not available when no session is loaded
- Impossible to make relations between JACK clients and NSM clients (it should be possible now with ':monitor:' capability).
Hm yeah that :monitor: capability, I'm sure it's useful, but one can't just add things to the NSM API on the client side imo. I find this a bit careless. Why not use the address /raysession/monitor for it now? And if there is 'community-wide agreement' on this feature, rename it to /neonsm/monitor or so?
Anyway back ontopic...
I'm not complete sure how the patchbay works in Raysession? It seems to announce to server, or the server checks a file and announces to the patchbay if it find one? Could you somewhat describe how it works technically?
What type of relations between JACK clients and NSM (a NSM client could be a JACK client and vice versa) clients are you taking about exactly?
I was not thinking about the patchbay as a NSM client, more as a (part of a) session manager GUI. In it's most simple form a 'connection and gui visibility manager' so to say. Or in a less simple form, a tool that just manages JACK connections and the launched session if there is one, and leave the launching/closing/aborting of the sessions(list) to a other tool for instance.
look where we are now: I can't use seq192 with jack-transport in original NSM.
What is ironic here, is that (I am pretty sure) jean-emmanuel would not have added NSM support to seq192 if RaySession didn't accept arguments. For its use, accept arguments is not a feature, it is just a base condition.
Sure, a good thing of RaySession could be that more clients would support NSM, all though the amount of clients didn't rise significantly it seems. (As reminder, I was never against RaySession or any new GUI, it bothered me when I find out it was using a different session format and that it treated Ladish v1 clients with the same status as NSM clients. In my view, this was hurting my attempt to encourage people to implement NSM and not to jump to the quick (and dirty?) option of Ladish Lv1* and so to get a more simple, predictable and stable environment).
In the case of Seq192, the only argument that is needed for NSM is --jack-transport. Is it such a deal breaker to have to provide that option in the GUI? I don't think so. Moreover, I think it's a regression for the NSM user, which can't set this setting from the GUI atm. This is just not a very convincing example for me.
But, and that frustration you read in my comments from years ago on your issue tracker, if you ever did a lot of work to get this NSM environment working (which I did from the start), you'll understand how difficult it is to get compatibility in the session management environment (especially on Linux). I try to avoid investing time and energy in projects/ people who don't seem to understand or see that. I see NSM as a very niche world, mostly plugins will take over probably, so new features might be nice, but if the consequence is that it breaks (backwards)compatibility then you must have very good reasons to implement them. 99% of the time this will not justify breaking anything imo. So if the seq192 author wants to break compatibility with the original non-session-manager gui, go ahead it's their project, it's a pity and not good for NSM imo and certainly not for me as non-session-manager GUI user, but I try not to bother anymore, I've adjusted my expectations I guess. Developers of session managers like RaySession have a somewhat other position imo, somehow they need to look at a broader picture to keep the ecosystem working. The arguments you've for the 'raypatch' is a somewhat different situation imo, one could see it as a RaySession specific application and looking at your project and programming skills I'm sure you'll find ways to accept arguments for that particular case, I don't see a real problem there atm. So that don't really convince me either atm.
Thinking about it now and now I do a little programming myself, I see your points about the session file format by the way. Sure a xml or json file or so, would be better extensible, you where right. And I could think of things to add, saving it's status, visibility status... On the other hand, you know what is great about the original session file, that it forces you to restrict yourself, which is in general quite hard as a programmer it seems. It's limitations are it's force in a way I realized. With a json file, I think it's much harder to keep the session management compatible then with a simple txt file as session.nsm. It's much harder to seduce the urge for new features... I've to see how my idea about this develops, but in principle with the original NSM you can do everything that bash can do: export as zip, upload/download to/from Internet. Sure, you can't add arguments etc, which are good arguments for imo, but again, this also means every NSM client will keep being backwards-compatible with the original version. And this restriction also helped me to easy implement a more modular approach with cli apps, launching from dmenu etc. No arguments, simple. Also more features to make things easier, are quite often making things harder at the end I think. Adding a feature that should make things easier, often gives the user more possibilities and more possibilities gives you more knobs, more shortcuts a longer manpage and so it won't make the application more easy, but more complex instead. This is also at least partly true for RaySession imo. There are many more knobs, options, checkboxes, differences, choices... That's also a criticism from older Unix experts "in our time the manpage was short and easy to read'. Now you've cli music players on Linux with a manpage >1000 lines, full of easy features. Sure, not easy to find a balance here.
[quote
without NSM_URL set early in the environment, cause then pid management, which I think/learned session management should rely on as less as possible, is less reliable (in theory at least).
I did not understand this sentence
[/quote]
Is has to do with pid management and the 'supervisor'. The supervisor has supervision about the processes it started itself. When using NSM_URL set early in the environment, such a client isn't started by the supervisor (nsmd), which is (in theory, in practice this seems to work fine so far) not what you want. At least that's my understanding of it now. About pids, now nsmd checks the status of pids to see if a client has died etc. I'm far from a network expert (comparable with some on Linux I'm in nothing a expert), but there might be other ways to detect these things (lost connection). I think I understand why NSM uses pids (and if not, we've them anyway), but for future sake, I feel it's wise to avoid extending it's pid management and to only let the supervisor (nsm server) handle them (where possible). So this would mean that the manager GUI app wouldn't do anything with pids. I assume the RaySession Gui sends a message to the server to instruct to SIGKILL the client (that feature you talked about where the knobs gets a different color)?
- Is using SIGUSR for saving projects considered to be good practise on Unix/Linux anyway or is it a 'hack'?