Make Raysession compatible with the Non-Session-Manager

[grammoboy2]

In the description of RaySession, it says that applications that work with NSM will work with Raysession. This is true, but you can't use a NSM session made in Raysession in the default NSM GUI.

This is quite a unreasonable thing to do it seems and you do actually harm the NSM ecosystem with it. You don't even want to discuss these design changes, like you didn't discuss anything with the NSM community, nor with the developer of NSM. Now we end up with a new NSM session file format.

Why would any sane person, introduce such a unneeded obstacle? Just for a not essential feature? Didn't you learn from the past at all?

Please fix this and don't harm a ecosystem carefully build up by others any longer.

[trebmuh]

Could you please stop insulting people with non-sense comments and FUD please? The person here who do harm the community is you.

[mxmilkiib]

@grammoboy2 Why not ask and listen first instead? Denigrating someone is actively counterproductive.

Also;

a) "programs compatible with NSM are also compatible with RaySession"

why do you presume NSM session files will work with RaySession? the text doesn't talk about a file level "ABI" compatibility, it talks about program level API compatibility (to steal a description from falktx).

b) there is already an argument that the clue is in the name; it's a Ray session you're saving, not an NSM session :)

[grammoboy2]

I shouldn't react on this, because it seems I'm the only person who actually uses actual argumentation. Saying that something is a stupid choice, is not insulting a person. Just write that GUI without having to change a NSM file session format, which is a stupid and harmful thing to do. But this is clearly not a discussion about software and NSM infrastructure anymore, with 6 thumbs down on github (this ain't facebook guys) for a very serious issue, with a reasonable argument shared by many people who know their stuff.

[trebmuh]

I shouldn't react on this, because it seems I'm the only person who actually uses actual argumentation. Saying that something is a stupid choice, is not insulting a person.

and

Why would any sane person, introduce such a unneeded obstacle?

Sure, you do have an argumentation which is not underlaying that people are not sane (ie "insulting")...

[grammoboy2]

That quote is assuming that he is a sane person, so the question is why would you introduce a different NSM session file format. This is a serious matter for the whole community. You can defend the raysession design, because you like the author better then you do like me for whatever reason. But it would be nice to discuss the actual matter here. Which is serious and should be avoided. If Raysession would use the default NSM session format, it would be better for us all. It's not wise to make NSM sessions work in Raysession and not in the default UI. Without emotion, most people would agree.

[trebmuh]

If you want to discuss things, you should:

1. start talking in a friendly and open manner,
2. stop writing rhetoric blabla when you're caught being aggressive/provocative
3. don't make it like a teenager psychology telling people that the issue is bounded to whether they "like or not" the OP because you're running out of argument

So, once again: be nice to other people, don't assume you know everything, do not talk as if you're talking on behalf "the NSM community", and things will certainly slowly get much better. Thanks you by advance.

[grammoboy2]

We all make wrong choices, but this is such a important infrastructural essential wrong choice which affects a whole Session Manager infrastructure. Such wrong choices are hard to fix later. You can't hurt a whole infrastructure because you want a not-essential feature. I would be really happy if this would be fixed.

If raysession was just a other GUI for NSM, I wouldn't care so much. Everyone is free to use what he wants. But this GUI affects a carefully buildup infrastructure, which is not what a GUI should do.

[trebmuh]

Finally, you are starting to have less loaded and more technical comments. Glad you do! Thank you.

[grammoboy2]

Now just waiting until you realize how you've been offtopic trolling around. Incroyable.

[trebmuh]

Yep, sure thing, I'm probably the issue here...

[mxmilkiib]

Sniping is not going to help.

What is the difference between and advantages and disadvantages of both sets of on-disk file formats?

[grammoboy2]

Session Management is a vulnerable ecosystem. History has proven that it's hard to build such a ecosystem and now when we're close to the finish, there is this new NSM session file format.

You're asking questions, but changing the NSM session file format, shouldn't be a question at all probably. The answer is obvious.

If you want to ask questions, the first question is, why do I need to change the NSM session file format. You have to have very strong arguments for it, where a lot of people agree with it. A non-essential feature is certainly not a reason to change this.

You actually make it impossible to use a NSM session made in a other NSM GUI, impossible to load in the default GUI. Why would you ever want to implement such a disadvantage.

[Houston4444]

I assume RaySession is not an alternative GUI for nsmd, but another Session Manager using NSM API for communication with clients.

There are many many features needing this file format, choose the nsm file format would make a very big regression for RaySession.

To be honest, although text format is easier to modify for user, I don't find it sane and scalable. Add a property and get backward compatibility can become a nightmare. There is also a problem with data with special characters etc...

[grammoboy2]

Here we have it. So it's actually worse then I thought it was. A new Session Manager for Linuxaudio, great, that's exactly what we need on Linuxaudio!

But what regression are you talking about exactly? Would be nice if you could be precise.

[falkTX]

We can have as many session managers as we want, that is not a problem. The problem is if the session format is not the same.

This can be compared to plugin hosts and DAWs. Why do we need Qtractor if Ardour already works well? We could say Qtractor only exists because stupid people want a fancy Qt UI instead of the Ardour gtk2 one. Heck, their session formats are totally different and incompatible, this is a disaster for linux audio!

Why do we need Ingen, Carla, Element, jack-rack, mod-host and others like these plugin hosts? they do the same thing - loading plugins. Yet all have different session formats. Oh no, the tragedy!

Actually for plugins, what matters is the plugin format. As long as we all use LV2, the opensource community will benefit. Having more hosts helps everyone, as it can lead to finding out issues in plugins that would otherwise go unnoticed. Plus, everyone's tastes are different.

In short: choice is good. More session managers are not the problem, we can use multiple tools to do the same thing - software as a tool serves its purpose well in this case. But they should all talk the same format - NSM. That way, no matter what the user decides to go with, the "NSM plugins" (applications) will be supported.

[grammoboy2]

Strange, apparently you changed your mind, because you told me on IRC weeks ago that it's indeed not smart to introduce a new NSM session file format and that there is no real need for it.

Also I think the comparison is not right. It's obvious that a session in Qtractor won't work in Ardour. It would be cool if you could, but hey, nothing you can do about this limitation.

Why would you implement such a disadvantage into the modular linuxaudio environment? There is no need for this limitation, where between DAWs there is nothing you can do about.

You should have really good reasons to implement this disadvantage to the niche modular linuxaudio environment. If there are such good reasons to implement new features, then you need good reasons why you should change that NSM session file format and why you don't implement that feature on a proper way, without implementing a disadvantage/ limitation into a whole ecosystem.

[falkTX]

As the author said himself, NSM raw session format is too limited. RaySession wanted to do more, so it did. In this context it is perfectly understandable. I was not aware of this fact before.

I think it is asking a LOT if you think every single developer action needs to be explained. People do new projects all the time instead of helping existing ones because it is simply way more fun that way - and a great learning experience. If we were getting paid for this, we would consider our options better. But since we are not, we just do as we please.

Now sure, it would be best if RaySession file format could be the same as NSM. But honestly, I don't see how that would much now. Our music projects are most of the time only handled by us, individually. I don't see a user switching from NSM-UI to RaySession, seems pointless to learn 2 different tools. You can get annoyed that you are not able to load the session from a user that was made in RaySession in raw NSM NTK UI, but the same applies to a user doing a session in Ardour and someone else used to Reaper, Bitwig or any other DAW instead.

[grammoboy2]

Not sure if you can compare JACK applications in a modular environment 1:1 to plugins in a DAW environment, but it also sucks when a plugin works in host A and not in host B.

As the author said himself, NSM raw session format is too limited. RaySession wanted to do more, so it did. In this context it is perfectly understandable. I was not aware of this fact before.

So what is it precisely?

I think it is asking a LOT if you think every single developer action needs to be explained. People do new projects all the time instead of helping existing ones because it is simply way more fun that way - and a great learning experience. If we were getting paid for this, we would consider our options better. But since we are not, we just do as we please.

This is actually exactly what the NSM developer did. He took years to design this API, discussing it with others carefully. And it has become a success because of it. Ok, some people want more features, but that's perfectly possible with a other GUI for NSM, with the same NSM session file format.

You're actually saying that it is okay to make essential design mistakes like these. It's just a hobby. If this is your attitude, which is fine, you shouldn't work on something like a GUI for a Session Manager with a whole carefully throughout and vulnerable ecosystem for a whole community. You shouldn't write a GUI or application that does depend so much on a certain infrastructure like a SM environment.

Now sure, it would be best if RaySession file format could be the same as NSM.

Noted. So why this new NSM file session format? What are these very important reasons to implement new limitations (opposite of extra feature)?

But honestly, I don't see how that would much now. Our music projects are most of the time only handled by us, individually. I don't see a user switching from NSM-UI to RaySession, seems pointless to learn 2 different tools.

It's seems pointless instead to implement a limitation / disadvantage like this. It's perfectly possible that someone starts with raysession, decides that it doesn't work for him (crashes or so), and that he wants to finish his session further in the default NSM GUI.

You can get annoyed that you are not able to load the session from a user that was made in RaySession in raw NSM NTK UI, but the same applies to a user doing a session in Ardour and someone else used to Reaper, Bitwig or any other DAW instead.

Indeed, there is this other disadvantage. The great thing about NSM is that it is easy to share sessions between users. Now users of RaySession can't share their session with default NSM gui users. This limitation is not necessary.

[falkTX]

It feels so weird that you believe you are in a position to dictate what I should and should not do.

What if the NSM file session format is actually not a good one? You are going in circles based on this assumption.

NSM as session manager API is very good. As file format? Who knows...

All this stuff having NSM name gets very confusing. NSM API, NSM session file format, NSM for UI errrr

All we should really care about is the API, so applications can be under session management control. With the mess of LASH, SIGUSR1/LADISH, and JACK-Session that came before it, it is sooo nice to finally agree on a session API. Everything else is nonsense fluff.

We have been discussing this for far too long. It is really tiring now. Jonathan continues to be a prick and calling names even on regular emails to the people that most contributed to NSM, and you keep acting worse than a religious fanatic that just got told other people prefer buddism over christianism.

Letting NSM as API win, and giving up on trying to enforce and single and absolute session file seems to be a sane middle ground here. We want NSM as API, and we will have it. Now let applications build on top of that and everyone be happy with themselves.

[grammoboy2]

What if the NSM file session format is actually not a good one? You are going in circles based on this assumption

This is simply not true, then you should read my argumentation again.

All we should really care about is the API, so applications can be under session management control. With the mess of LASH, SIGUSR1/LADISH, and JACK-Session that came before it, it is sooo nice to finally agree on a session API.

This is one of the reasons why this issue is so important. Given this history it's not wise to introduce a new NSM session file format, if there is no need for it.

I've pointed out serious arguments against implementing a limitation / disadvantage into a ecosystem. They should be addressed I think, but you don't reply to these arguments now and go completely offtopic.

There is still no answer to the question why you would implement this limitation yet.

[falkTX]

I dont like quote replies, reminds me too much of email. A normal conversation does not flow like that.

[grammoboy2]

People don't realize apparently that it is perfectly possible to get a QT GUI with advanced features without having to change the NSM session file format.

Sad to see that people have 7 thumbs down for a serious concern, but no one who actually criticizes this design, which implements serious limitations without reason.

It's sad that there is no explicit answer given to the core question in this issue report.

Tackling the Session Manager problems on GNU/Linux was done by Jonathan Liles with his NSM API. Which has been a enormous achievement. It's not coincidence that he did it after all these years with several attempts. I've spoken with a lot of people last weeks in my attempts to improve the NSM environment, and it's sad to realize that he is probably still the only person who gets it, whether you like him or not. It's sad to see his work being screwed up by others, by people who have apparently no time or salary enough to think first before they start to code.

Now we just wait until the next hobbyist without enough resources to do serious thinking, comes up and decides that he wants to even change the actual NSM API for no reason, hailed by a community.

Don't worry anymore about what you call 'religious behavior' when you run out of arguments Filipe. You have to come up with real arguments now, because I've completely lost faith.

Good luck with it. I'm out.

[Houston4444]

@grammoboy2 RaySession needs its file format for saving launching state, templates, labels, file paths, trash, extensions ignored by snapshots, desktops memory.... nearly for all features specific to RaySession.

You perfectly have the right to think all these features are unneeded, and just not use this software. I validate 100% the words of falkTX ! no wait... 200 %. Thanks a lot to him!

But now stop this please, even if you don't commit direct insults, your tonality is aggressive and your obsession clinically disturbing. it's exhausting, I assure you.

[grammoboy2]

You failed to notice the comment by Falktx where he agrees that it would be better if raysession didn't change the NSM session file format.

But this is exemplary of this whole discussion and why I've lost total my faith in where this is going. It's obvious why this change is a limitation, but even the current JACK maintainer fails to see it and is not capable of proper argumentation nor discussion. Being a JACK developer is a responsible task, if that person gives thumbs up for trolling people, things becomes really childish and you start to loose faith in this whole thing you know. Can't imagine Paul Davis would ever do that. You would hope that someone with such a task could at least give argumentation on technical grounds.  A JACK maintainer should be still capable of discussing in a academic manner, even when emotions run high. This was always the case in the past. I'm totally missing that attitude and those academic skills now. So it's not only raysession, but also the fact that this wrong design is supported by the JACK maintainer, makes me completely loose faith in this whole project.

Let's hope that someone comes up with a QT NSM GUI  soon which doesn't needlessly changes the NSM session file format. I hope this for people who likes to see more features, which I don't need myself. Until then I recommend everyone to use the default NSM GUI. Which has proven to be more stable then raysession and which is simple stupid to use. It does what it should do and does it well.

[falkTX]

You failed to notice the comment by Falktx where he agrees that it would be better if raysession didn't change the NSM session file format.

That is some nice cherry-picking :) I also said that I understood the reasons for the format to change, and the author already mentioned them too.

RaySession needs its file format for saving launching state, templates, labels, file paths, trash, extensions ignored by snapshots, desktops memory.... nearly for all features specific to RaySession.

The raw/old format cannot do this, and the original NSM author does not want them. So what is a developer to do?

The old format is the limitation, because of arbitrary restrictions imposed on it by its author.

@grammoboy2 if everybody disagrees with you, maybe, just maybe, that is an indication that perhaps you are in the wrong?

I am quite calm here, just sad to see how far you fanboyism goes. The RaySession author already gave you a perfectly valid reason why the file format is not compatible, yet you choose to ignore it as it is not an actual thing or even relevant. How is that for academic discussion?

Even in academics, no one wants to deal with annoying people, and right now that is where you stand. Calm down and be reasonable please. The file format change is not the end of the linux audio session manager. I stated multiple times that everybody agreed on NSM API as the thing to use. Isnt that a thing to celebrate? If we need a small revolution in order to push things forward, so be it. We will be better off long-term because of it.

[grammoboy2]

The whole NSM API is restricted. That's exactly the power of it. You fail to see that I think. That's why I don't have confidence in where this is going. You want freedom. Everyone doing what he likes, even if the reasons are highly questionable. If you fail to see that this isn't working for session management on Linuxaudio then I think, 'Houston, we have a problem here'. That's why I was raising flags, even if I'm the only one (here). You like to run JACK standalone applications in Carla, export them to LV2 and run that in a LV2 hosts. Perfectly fine, but it's not a software approach I've faith in. It's not a good mentality for session management on linuxaudio at all. But hey, I can't convince people here. Fair enough, at least things are clear now for me.

[falkTX]

The whole NSM API is restricted. That's exactly the power of it. You fail to see that I think. That's why I don't have confidence in where this is going.

We are not changing the NSM API

You like to run JACK standalone applications in Carla, export them to LV2 and run that in a LV2 hosts

I dont like it per se, I just find it convenient. Re-using NSM API for saving application state is awesome, it makes the applications behave exactly like a plugin would. The only bad part is lack of parameters, but even that can be addressed at some point.

You are not a developer so I guess some things might be confusing. No one is changing the NSM API, or has intentions to do so. The API is quite not the same thing as the file format used for user sessions.

Speaking of Carla, it does not and cannot save in a way that is compatible with the "NSM" file format, it is technically not possible (Carla projects are a single XML file)

I think calling the files saved on disk by nsmd "NSM" was a mistake. There are different layers of stuff here that are all named NSM, which is very confusing even to me. So to clarify, we have:

1. A network protocol, which can be called an API, which defines how an application communicates with the session manager
2. A list of restrictions on applications when running under the protocol under point 1 (no "save as" etc)
3. Another protocol, specific to one implementation of point 1 (a server/tool), dedicated to making GUIs. This new protocol is irrelevant to the first one
4. A file format used by the tool described in point 3

Point 1 and 2 make the NSM protocol or API. The thing we are all glad to have and rooting for. Point 3 is the separate protocol used in nsmd to talk with a GUI (which is NOT the NSM API) Point 4 is how nsmd saves files on disk

Without any heated discussion from anyone's side. Are those 4 points well understood? If yes, we can continue..

[grammoboy2]

It's perfectly clear to me that the NSM API isn't changed. There are obvious disadvantages for the NSM ecosystem when you can't run a raysession session in the default NSM GUI. It's not smart to change this. You're implementing a major limitations in a ecosystem in a urge for new not essential features. Additional features are perfectly possible without changing the NSM session file format. This urge for new features and changes will not stop here. The API is next. Mark my words. Instead of focusing on the real problems, people screwing up a ecosystem, because there is always a new needless feature to be implemented.

[falkTX]

sigh... you are not listening at all...

We absolutely cannot change the API at all, because then everything stops working. I am trying to have a proper discussion now here and make you see our point. Did you understood the previous 4 points or not?

But if you really want to continue on and on about "I am right", "no, I am right", "no, I am right so!" meh Then I must say NSM default GUI is the disadvantage at this point. We want to improve it but the author refuses any addition for overall better user experience. His attitude is simply - works for me, so I don't care anymore.

Wanting a nice way to export a project is not feature creep. Wanting to wait / ensure JACK is running before loading a project is not feature creep. Saving the JACK connections properly (that is, not deleting connections from clients that are not active at the moment) is not feature creep. A GUI in a toolkit that integrates well in the desktop environment (file-picker, styling, colors etc) is not feature creep. Listing the supported NSM applications in the system is not feature creep. Deleting a NSM project within the GUI is not feature creep.

All of those above are nice to have things. But Jonathan is only interested on the last one.

[grammoboy2]

Then I must say NSM default GUI is the disadvantage at this point. We want to improve it but the author refuses any addition for overall better user experience. His attitude is simply - works for me, so I don't care anymore.

Then write that QT GUI or fork his GUI and implement new features you want. Then at least those features could be backported to the default GUI if it's a good one.

Wanting a nice way to export a project is not feature creep.

I absolutely don't see a reason for this, but male was open for a compression thingy, which I still find a total needless feature, but I guess Ardour has that feature to then.

Wanting to wait / ensure JACK is running before loading a project is not feature creep.

Never thought about his, never had a need for it. I don't load a session when JACK is not running. Do you need a new session file format for it?

Saving the JACK connections properly (that is, not deleting connections from clients that are not active at the moment) is not feature creep.

When you re-activate a client, all the connections are restored. I don't see a need for this feature myself. Do you need to change the NSM file session format for it?

A GUI in a toolkit that integrates well in the desktop environment (file-picker, styling, colors etc) is not feature creep.

Perfectly possible without changing the file format

Listing the supported NSM applications in the system is not feature creep.

Perfectly possible without changing the file format. Male would accept a patch, he has discussed this feature

Deleting a NSM project within the GUI is not feature creep.

Perfectly possible without changing the file format. Male agreed on a proposal I did for it.

All of those above are nice to have things. But Jonathan is only interested on the last one.

It's not about whether you like the default UI or not. Anyone can write his QT GUI.  It's about whether it is smart to change a session file format, by which you implement limitations and disadvantages into a ecosystem.

[falkTX]

You know, it is not about you... it is about the users. Just because you don't see the need or use for such a thing, does not mean users will not want it. Sure, you can treat the users as stupid. Jonathan does that a lot. But we should strive to be better than that. He is "open" to a lot of stuff, as long as you are willing to be treated like shit in the mean time of convincing him why caring for regular users is a good thing.

Nils had the experience already with trying to get students to use NSM. It went not well at all, to put it lightly. Making the experience nicer for new users is something nice and commendable to have as a goal, wouldn't you say so as well?

Finally, I cannot stress this enough, the "session file format" is not the NSM API. RaySession is compatible with the NSM API. Carla, Non-Mixer, ZynAddSubFX and any other application that implements the NSM API will work just fine with it. I am grateful for that, instead of angry at the author for a (highly debatable) perhaps bad decision.

I think you don't understand that nsmd and the NTK GUI that Jonathan did are not the NSM API. The protocol used by nsmd to talk with the NTK GUI is not NSM at all, it is just a method of communication. Anyone can do a replacement for nsmd and the GUI and keeping everything intact that is visible to the user, but internally totally different.

So let's get to the bottom of the issue here: Why do you so seriously believe that a different file type is such a big issue? (NOT talking about session format, the session method/API is still NSM)

How often do you expect people to share projects with each other? (Even for DAWs, that rarely happens)

If someone sends you a RaySession project, is it really that bothersome to install RaySession to open that file? (Someone sending us a Bitwig project for testing would mean we have to install Bitwig first. Is that something to be mad about?)

[grammoboy2]

It's disappointing that you don't reply directly to my questions, because then we could see exactly where we need those session file format changes for.

You say that's about the users, but I didn't say anything which is a contradiction to this. I explicitly stated that you can write your QT GUI or fork the default GUI, if you want more features. So that's absolutely not where this debate is about. But do it without changing the session file format.

It's obvious that it's a limitation for a ecosystem when you can't use a session in one GUI, made in another. Your argument is, it's not possible in DAWs, so that's why it isn't a problem. This reasoning makes no sense to me at all. Why would you implement a disadvantage or limitation from one system into a other when there is no urgent need for it? These are design choices where people have to deal with in the future. You say it's about the users, why would you put this limitation on their table?

You want to improve user experience, which is perfectly possible with a new QT GUI or forking the default GUI. But why would you make the user experience worse, by implementing a needless disadvantage in a ecosystem. This is the opposite of what you're trying to achieve.

[falkTX]

It's disappointing that you don't reply directly to my questions, cause then we can see exactly where we need those session file format changes for.

But I just explained that.. and the RaySession author too. Yet again:

RaySession needs its file format for saving launching state, templates, labels, file paths, trash, extensions ignored by snapshots, desktops memory.... nearly for all features specific to RaySession.

Why do you keep ignoring this?

You say that's about the users, but I didn't say anything which is a contradiction to this. I explicitly stated that you can write your QT GUI or fork the default GUI, if you want more features. So that's absolutely not where this debate is about. But do it without changing the session file format.

I thought it was a valid assumption that implementing the new things would in turn mean the format has to change, as the format is very (re)strict on what it can do. Sorry that was not clear. But yeah, there are some ideas of things to put in a new GUI that simply cannot be done with the format used by nsmd.

You want to improve user experience, which is perfectly possible with a new QT GUI or forking the default GUI. But why would you make the user experience worse, by implementing a needless disadvantage in a ecosystem. This is the opposite of what you're trying to achieve.

Simply because I dont see it as a disadvantage, but quite the contrary. Moving away from the format that was made specifically for nsmd and the NTK GUI can actually be good for us, in the long term. Why do we have to limit ourselves so much? The gains are pretty minimal doing so, contrary to letting go and making a better file format.

The current file format used in the NTK GUI makes sense in its own context, because the NTK GUI is minimalistic by design. A new GUI that wants a bit more than that (which, let's be honest, is not very hard since the NTK GUI is really barebones) will be very limited and have to jump through many hacks in order to make the new stuff work with an old format.

[grammoboy2]

RaySession needs its file format for saving launching state, templates, labels, file paths, trash, extensions ignored by snapshots, desktops memory.... nearly for all features specific to RaySession.

This sounds like a total new Desktop environment. Going in the direction of the failed attempt Ladish. Total contrary to the spirit of a modular approach and the NSM session manager. Which probably ends the total discussion, cause why would a user ever wants this again.

Indeed let's be honest, it's not very hard to offer a bit more then the default GUI, if you need it. Most people just want to be able to translate the GUI, to minimize the GUI, to change client names, to have a applications list with tab auto-completion, to remove a session, maybe export a session with tar.

Everyone would be happy with it. But you're going from a minimal design to a total new environment which is totally out of scope of what users really need. With a very nasty side-affect, which hurts a community.

Good luck getting this stable and reliable, number one feature for a session manager. Good luck for those who encounter crashes and unreliability. You're stuck with raysession, we can't help you.

You could have tackled the problem with a much better solution. Let's hope that someone else comes with a cleaner solution soon, for additional features people really need.

[falkTX]

why would a user ever wants this.

Most people just want to be able to translate the GUI, to minimize the GUI, to change client names, to have a applications list with tab auto-completion, to remove a session, maybe export a session with tar.

Everyone would be happy with it.

For someone who previously said that did not understand most users, you talked a lot from their perspective and what they ought to be and really want... I think you're assuming too much on what users and and not want. There are many kinds of people, not everyone wants the same.

I would like to have an online community platform where users can share, download and discuss sessions and project files. The online aspect can happen via browser, but talk to an application running locally in order to make it download and load specific projects. The MOD pedalboard feed with its "try now" button already does something quite similar. I see this as a way to push people to use NSM more and more, but such idea will never be possible with what we have now.

Would users want such a thing? The success of the LMMS Sharing Platform makes me think that yes, it is desirable.

There are many other ideas, I did not bother to mention before because even the smallest inconsequential things were already put aside as "too much".

Good luck getting this stable and reliable, number one feature for a session manager. Good luck for those who encounter crashes and unreliability.

Thanks. I think it is all doable, if we all start doing something instead of complaining all the time.

With just a few more applications supporting NSM (the API) and improved user experience in the UI (whatever that ends up being) we can make linux audio session management a nice happy place once again. We are very close!

[grammoboy2]

Let's be real, the situation at this moment mostly worsened. I've tested raysession just from a blanc sheet. I didn't knew it changed the NSM session file format then. It broke my sessions twice, so I gave up very soon. So now there is this new GUI which is less reliable then the default one. That is isn't a improvement.

You seem to care about sharing via a online platform, but the first thing you did was making sharing more difficult. The situation now is that 100% of the people can share their NSM sessions with each other and you ruin the score by making it 50% or so. This makes totally no sense.

When you use NSM, >85% of your time is in the applications. I do start NSM on a certain Workspace of my Desktop environment and leave it there untouched, apart from some little fiddling with saving.

The GUI is not the major problem for NSM, applications that don't support NSM are the major problem. No super super super feature in any NSM GUI can fix that or can compensate for it. But you rather spend the next five years on building a sandcastle.

And let's not talk about misbehaving JACK applications that doesn't work as expected yet.

Again, the default GUI might lack some quite simple features, which people seems to need. This could easily be fixed with some patches for the default GUI and if not, by building a simple other reliable QT GUI, without making sharing between users in the community more difficult.

It's sad to see you rather building sandcastles, instead of doing a good analyses of the problem first and then work from there to solve them. Now you've only worsened the situation.

[trebmuh]

Does that really make your life better to ramble all around pretending you're talking on behalf the community and accusing people of whatever frustration you encounter? Really?

[eeickmeyer]

I'm going to add this, and that's all I have to say. I am the leader of Ubuntu Studio and Fedora Jam, which are arguably the two most widely-used audio operating systems on the planet. As such, nothing goes into the default installation of either one without my approval.

@grammoboy2 , your crusade needs to stop. This is not the first instance of your insistence of NSM being the be-all end-all of audio session managment in Linux-based operating systems. Additionally, such an attitude flies in the face of the spirit of open source software including the GPL. Such a restriction of development of software is against the spirit of freedom from which the GPL and FSF are founded. @Houston4444 is free to develop this software as he sees fit. Additionally, since there is no API compatibility issue here (Note: not session compatibility), applications that implement the API have nothing to worry about. Your personal emails (and attacks, might I add) to me have not helped your cause, but have rather hindered it.

My packaging of RaySession just landed in Fedora Rawhide, and it will be added to the default installation of Fedora Jam 33 just like I have done with Ubuntu. Because of your attitude toward RaySession, I do not intend to add NSM to any default installation, even if the package is made available. I am working on unretiring the non-tools from Fedora, but am running into a lot of difficulty there since there have been so many changes that are not following proper *nix file structures. And, considering how hostile Jonathan has been in the past, I am leery of advising him to fix things that only he can fix.

I will also be advising people in Debian, such as Ross Gammon (who is on my Ubuntu Studio team) not to work with you, citing this thread as an example of your hostility, which has only hindered your cause.

You do not represent the Linux Audio community. Better representatives for that are in this thread, such as @falkTX and @trebmuh . I hope you now understand where your place is.

With that, any request of yours for NSM's inclusion as a default in either Ubuntu Studio or Fedora Jam, now or in the future, is hereby denied. Your hostility toward this project and others in the Linux Audio community, of which you do not represent, are cited as reasons for this denial. Please end your crusade now.

[Houston4444]

Oups. I forgot to mention I blocked grammoboy2 (for obvious reasons, I don't think you need arguments ;) ), so he can't answer. Perhaps he doesn't receives notifications, but I am pretty sure that he takes a look to this page seeing its obsession. Thanks for your work @eeickmeyer !