18 Jun
2020
18 Jun
'20
4:59 p.m.
On 06/18/20 13:10, rosea.grammostola wrote:
You know I did a lot for NSM, and I'm probably the
most likely the
most active user in the community. Involved from the start of the project.
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.
I did a lot to improve the situation lately, with some
success. I've
had contact with both of you last week (IRC and mail). Nils sent me
mail this week about NSM/Jonathan. Nothing about the fork. Besides the
fact that I understand that at some point a fork was inevitable, next
time you want to fork, just say it and make sure to do it in full
daylight.
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.
On a technical level, I'm glad you are aiming to
be fully compatible
with the original Non-session-manager (NSM). I'm just afraid that
you're underestimating the task at hand and the accomplishments being
made here though. Not giving the original author the credits he
deserves, might be a sign of it as well.
From personal experience, I've still have to find someone else besides
the original author of NSM, who understands why NSM works as a session
manager. It works I think, because it's simple and has clear rules.
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.
I see a urge for new features, which are potentially
harmful for the
success of NSM. When I didn't use Linuxaudio for years and restarted
it, it was quite a horrible experience. JACK standalone applications
do have all kinds of features, but where crashing on me constantly
(the nice thing about NSM, is that you've it back in one click).
Totally unusable to make music with. I'm personally not waiting for
new non-essential NSM features, which are making my setup less
predictable, more resources consuming and less stable.
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, I've no confidence in it. I said
enough about it. Better
spent your time in NSM support for clients.
RaySession has nothing to do with this announcement, let's not talk
about it here.
You recommend Argodejo as GUI on the github page.
I've a very hard
time finding it better then the default NSM GUI. The simple view is
not that simple anymore if you've a lot of sessions. The advanced
view, is more complex then the original GUI, because it gives you so
much more information. Duplicate was renamed as 'save as', which might
cause dataloss for people who expect it to behave as 'save as' in
other applications. Might be personal preferences, but all these small
things doesn't make me very enthusiastic about NSM without the
original author.
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.
A other related experience. Feature request for
Radium. NSM support in
Radium, which is great. Author did implement accidentally server
client osc messages. As a consequence he decides to give Radium
session manager functionality as well. I think this design approach
will harm a reliable and predictable NSM session environment for the
user at the end.
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. :(