On 06/18/20 13:10, rosea.grammostola wrote: Yes, I know. Though for quite some years after the initial launch you were away from the scene, only recently coming back to check on status of linux audio and related things. So please do not make it seem like you were helping all these years, NSM has been dormant for a while now until we (including you) recently starting pushing the discussion again. Before you came back though, we already had set on NSM as the de-facto SM to use (which you do not seem to believe it seems). Last year I gave a talk at Sonoj discussion JACK, and its future. I specifically mention that NSM is the winner of all SMs, that JACK-Session is being made deprecated, and congratulations to Jonhathan for that. That has been my opinion for a long time, but I could never do much about it. Once I became the JACK maintainer, it was easier to push into this direction. Nils was also always very active in pushing the conversation regarding NSM, making code examples on how to use it, and keeping the NON wiki updated. He made his new tools (Patroneo, Fluahjo and Vico) entirely based around NSM. We talked about the fork quite a few times in the #lad IRC channel, where most linux-audio developers hang out. Again, the timing of the announcement is irrelevant. Might be night time for you, but it was still day in the American continent, as usual per timezones ;) We had many times tried to make things work with Jonathan, you of all people should know. If we spoke about a fork, we would fear yet another shit-storm would come, and we are tired of that at this point. PS: There is no need for personal attacks here, please cut that out and be nice. We do understand why NSM works, so much that we are actively pushing for it! If we did not believe that NSM can be the de-facto SM, we would not go to all this trouble for it, insisting on it after so many years despite the toxic environment around it. I also think the clear rules is what makes NSM work, not sure why would say I do not. Me, Nils, David and many others, we all do. Other SMs have clear design issues, where NSM was brave enough to be quite strict on what applications are allowed to do, and that is what it makes it possible to succeed. Not exactly true about new features. We do not want to add new stuff into NSM, it is perfectly fine as it is. We do want though to make the user experience better. As requests for (in my opinion sensible) features to the GUI were ignored, and me and Nils not being comfortable developing with FLTK, the only solution was to try to create a brand-new GUI that we can maintain. This will change nothing about NSM though, the protocol will remain exactly the same, with very tiny exceptions where unavoidable. One such change is the highly-requested possibility of getting the NSM Session dir out of $HOME and into $XDG_CONFIG_HOME, there was no way to support this without adding a tiny new *GUI only* change. And the *GUI only* is critical, the NSM protocol still remains unchanged, this is only used for "NSM Control Panels". Stability issues of standalone applications are a bummer for sure, but not related to NSM. Also, in case this was not obvious... We made the fork leaving the original NSM GUI untouched, it is the same original code. So there is no need to use any new "less predictable, more resource consuming and less stable" control GUIs. RaySession has nothing to do with this announcement, let's not talk about it here. Thanks for the constructive criticism. The tool is very new, and I even haven't run it myself. Please give us some time to get it nice and polished - it is not even released yet. Yes, I agree fully. Not sure how he confused things so much, but it is not the task of the applications to be messing with NSM server-side business.. Basically, he did not implement NSM properly. :(

Am 18.06.20 um 16:09 schrieb rosea.grammostola: Yeah, WTF, really. As Filipe already pointed out, the time of day of the release is totally irrelevant and you keep on complaining about it without elaborating why it is significant. Sorry, but that doesn't instill much sympathy for the rest of your statements. And accusing the devs of "acting like snakes on a pro level" doesn't help there either. Chris

On Thu, Jun 18, 2020 at 1:37 PM rosea.grammostola < rosea.grammostola(a)gmail.com&gt; wrote: 1) "midnight" is a point in time in a given time zone that could correspond to any hour of the day somewhere around the planet 2) many programmers, especially those working on unpaid projects, work late at night your rush to assume ill-will here isn't a good look

Am 18.06.20 um 21:37 schrieb rosea.grammostola: there was some discussion on original-male about the future of NSM, which was deleted lately by the original author. You, was part of this discussion. So, I don't understand why you been so surprised now that it really happen, just, because you, as a power user of NSM wasn't involved in the process. If you are still interested in the future of Linux Audio Session Management you should really be happy that the Session Management is now in the hands of linuxaudio.org As a point of my side, I'm happy about that, and now, I'll consider to implement support for NSM in my software, as I didn't have to deal with original-male any more.

Ok, the cooled down version. My apology for the whitenoise. On 6/18/20 10:09 PM, Hermann Meyer wrote: It's positive that people are still working on it indeed. It's also a good thing that people who prefer a QT gui, have a option to use Argodejo (new GUI for NSM). It's positive that nsmd and a gui (argodejo) will be easier accessible for regular Linux users and that it's chosen to be the session manager to focus on and to recommend for Linuxaudio. It's positive that they stick with the original NSM design, not reinventing the wheel. I'm not positive about the renaming to new-session-manager though. Non-session-manager is around for many years now, renaming it, adds confusion, also in relation to the existent documentation around on the Internet. I would really reconsider whether this change of name is needed and a wise thing to do. This part is also the 'hijackish' part for me, I know, it's free software, but still, it's a bit too much claiming NSM now with a whole plan behind it. It was Jonathan himself who suggested to put nsmd in it's own repository, so it would be easy to package Argodejo with nsmd for the variety of Linux distributions (the dependency on NTK and using waf made it difficult to get it in distros like Debian). It would be better to settle around with the original developer on how to organize this. But with a bit more patience, this drastic approach was not needed I think. If a fork turned out to be the only workable option, it might have been better to just fork nsmd and rename that, and don't touch the non-session-manager (GUI) at all. The version available on the new github repo is not a fair replacement for the original GUI at the moment anyway. It has problems with the graphics. It's also not the intention to develop it further, so why fork and rename it. The most important change is the change of the maintainers/developers of course. All though I'm sure it has positive sides in some aspects of it, don't forget we have NSM because of the work of Jonathan. He has come up with a session manager that works better then previous attempts, all though technically less complex it seems. Quite a accomplishment. It might sound good to have it labeled under 'linuxaudio' now, and aim for a more community driven development, but being nice and easy to each other isn't always good for the software. In fact, one of the reasons why NSM works, is because the original developer didn't make all kinds of compromises, for the sake of being a nice and friendly community. So, a new way of maintaining the software, isn't success guaranteed. If I compare Carla with the NON tools for instance, it's a totally different approach to software development. Where NSM is minimal and restricted, Carla has lots of features, even quite some experimental ones. I'm not judging about which approach is better, I'm happily using both of them, but I'm convinced that NSM is a success because it's minimal, restricted and without compromises. So for session management a minimal approach is surely a better one imho. Also building a GUI for NSM, is different coffee then actually judging about if and which features should be implemented in NSM and how that should be done.  So, I've to see how this different maintainer-ship will turn out, but the original developer has proven that he 'gets it' when it comes to session management, for the others it's something we'll have to wait for and see. But not having the original designer of NSM as maintainer for whatever reason, I see it as a loss, not as improvement. Anyway, at the end of the day, the real important thing which improves user experience significantly at the moment is adding NSM support to applications. Hacking around applications without NSM support, without adding NSM support itself as I also see happening, is time spending on the wrong things and adds only to a more confusing, less stable and a worse user experience imho. I'm glad this Argodejo/NSM project doesn't seem to take this path and I hope it keeps that way. It has been said that there are not enough applications adding NSM support. I think a list of +- 30 applications isn't that bad at all actually, with quite some important ones included. For myself I've just a short list of applications that would have been nice to support NSM: Radium (in next release), Seq64/66 (work in progress), Hydrogen (work in progress), Carla-single (in roadmap), Muse (possibly maybe), Rakarrack, Sooperlooper, (Luppp needs a bugfix). In meantime, the original Non-Session-Manager with the NTK toolkit is still available, easy to build and as I prefer it above Argodejo myself, I'll still be heading to the NON project and more will do so most likely. So you can state that it will replace the Non-Session-Manager, but at the end the users decide I guess and for the user it is actually just a matter of which GUI you prefer for the Non-Session-Manager, with the advantage of Argodejo being easy to package for Linux distributions and having a more responsive and active developer.  I think this could have been offered to the user in a less radical way, without releasing 'New-Session-Manager' (which has a lot of characteristics, but being new is not one of them). My 0.02$