Re: [LAD] [LAU] Release: New Session Manager Version 1.3

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. :(
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Jun 19 04:15:01 2020