What session managers do people prefer?

What other apps and distros do you use to round out your studio?

Moderators: MattKingUSA, khz

grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

houston4444 wrote: Thu Mar 30, 2023 5:21 pm

Might 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'?
houston4444
Established Member
Posts: 78
Joined: Mon Apr 02, 2018 6:53 pm
Has thanked: 3 times
Been thanked: 25 times

Re: What session managers do people prefer?

Post by houston4444 »

one can't just add things to the NSM API on the client side imo. I find this a bit careless

No, no problem at all, I just said to others that I added the ':monitor:' capability and how it works.
Now, if someone wants to do something similar but not exactly, it is perfectly possible, the only need is to use another name.
Clients can have many possible OSC messages (other than concerning their nsm client), so '/nsm/client/' is the good path.

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?

Here it is how it works when all is working (with 2 GUI processes in the example) :

Image

You can see that the daemon and the GUI processes have no JACK client. JACK client is in a specific process (ray-jackpatch_to_osc) which communicates with the GUI(s).

When GUI is started (or when patchbay is shown in GUI), it asks to the daemon an OSC address for the patchbay sender.
Daemon checks in /tmp/ files if a running instance of the patchbay sender exists (it executes one instance if not found), then it replies to GUI the port of the patchbay sender.

About PIDs.
Honestly, I don't know if ray-daemon uses pids to check state of clients. ray-daemon uses QProcess class, and I suppose it uses pids.
ray-daemon uses pids for client started from external (launching

Code: Select all

NSM_URL=... program

).

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)?

exact.

Is using SIGUSR for saving projects considered to be good practise on Unix/Linux anyway or is it a 'hack'?

Why should it be bad ?
For sure, the nsm way is better, because server has an answer from the client to know when the client is saved, or if save failed.

grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

houston4444 wrote: Fri Mar 31, 2023 7:49 am

one can't just add things to the NSM API on the client side imo. I find this a bit careless

No, no problem at all, I just said to others that I added the ':monitor:' capability and how it works.
Now, if someone wants to do something similar but not exactly, it is perfectly possible, the only need is to use another name.
Clients can have many possible OSC messages (other than concerning their nsm client), so '/nsm/client/' is the good path.

I can imagine some kind of release schedule where a experimental feature is released first with a /raysession/... address, and if there is 'community-wide' consensus (good luck ;) ), it will be added to a /neonsm/ api. /neonsm, cause ideally I would keep the original API untouched, but this would need some extra thought.

Is using SIGUSR for saving projects considered to be good practise on Unix/Linux anyway or is it a 'hack'?

Why should it be bad ?
For sure, the nsm way is better, because server has an answer from the client to know when the client is saved, or if save failed.

Sure and in general this is not what you want for something important like saving a project I think.

Here it is how it works when all is working (with 2 GUI processes in the example) :

Thanks. As it seems to use OSC all over, I certainly have ideas how one could implement this. This is more or less what I'm prototyping already in my own more modular way of managing sessions.

But to be honest and while I enjoy this discussion and share design choices, I've to press my brakes a bit here, before I share too much. You're probably aware that you're talking with a 'cancelled' person in this whole NSM world. At places where I'm not blocked already, I must be really careful what to write every time I write something. I know beforehand that it will be ignored or disregarded as nonsense. I lost some kind of 'white privilege' I guess, which others still have. Sure it talks much easier knowing that you've your almost ideal custom setup already under your fingertips, and in general it's best to do your thing anyway which I do, but it also comes with a certain amount of unhealthy pressure to find yourself against a majority constantly. Moreover, the issues or better the consequences I fought against, I wanted to avoid, are still actual. If I or anyone else, releases software in this area, you just can't be sure that it will be renamed to 'new-session-manager' or related the next week and put under the umbrella of god knows what. You've little rights as individual, while some seems to have all the rights. A smart independent thinker who solved a problem, but who became a burden for some, can be send to virtual Siberia, while his project is being annexated for the good of the community. Request to defend the rights and interests of the individual are all discarded. This can happen to anyone. Nah this communistic vibe is not my cup of tea. Therefor, I really have to explicitly take care of my own interest (including health) and rights as well, before I contribute too much by sharing ideas or even code. For now this is all pretty clear for me for various reasons, don't share too much, you've only things to loose. I've shared the bugs I found and some ideas as 'tit-for-tat' for the extended documentation in the nsmd fork and reported client related bugs because I care and I benefit myself from a good functioning ecosystem of course, but that's about it for now I guess, at least in this area. And maybe this is still the best for all parties for now.

Maybe it will become fun again to share ideas or release code later. If you give me your e-mail address via pm, I might be willing to share and discuss my ideas with you when the time is there. But now I want to enjoy the system I've now and see if such a more modular way really works. Anyhow, good luck with RaySession and be sure to take a look at Bespoke for how modularity could work as well.

houston4444
Established Member
Posts: 78
Joined: Mon Apr 02, 2018 6:53 pm
Has thanked: 3 times
Been thanked: 25 times

Re: What session managers do people prefer?

Post by houston4444 »

I can imagine some kind of release schedule where a experimental feature is released first with a /raysession/... address, and if there is 'community-wide' consensus (good luck ;) ), it will be added to a /neonsm/ api. /neonsm, cause ideally I would keep the original API untouched, but this would need some extra thought.

Changing message paths between versions would be a nightmare, simply accept that /nsm/ is the protocol (relation server<->client) is simpler. I see no problem with the possibility of many session managers with the same /nsm/ paths and different capabilities. Capabilities has been done for that (I guess).

I must say I don't follow you in what I feel is paranoia. On my side, I blocked you in March 2020 to stop that thread: https://github.com/Houston4444/RaySession/issues/41. You were just too insistent on a subject that did not seem important to me (and not more today). Now if you want to participate to bug reports or development without prejudice from others, just use another alias, if you are correct and not too insistent, everything should go well.

grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

Mwah, you think a bit too easy about this I think. Have you ever tried to imagine how the original nsmd author must feel? What if non-session-manager was raysession instead? Just think about it, not asking for a real answer.

You call it paranoia, but without judgement, fact is that I'm currently blocked on the forks github page after reporting issues. Also, given the fact how the fork has been handled, especially calling the fork the 'community version' of the forked project without consent, just slightly or no name changes, there are simply no guarantees that this won't happen again atm. Raysession is probably a example that projects can live next to each other, but realize you're part of the ingroup.

Just to think about, in hindsight, would it be so different if the fork was called agordejo-daemon instead? You've probably have some Agordejo users now, which use the new-session-manager server. Isn't it basically already a server for Agordejo atm maintained by the Agordejo developer? If you use Agordejo, you use the forked nsmd, if you're a Raysession user you use the raydaemon. It apparently works for Raysession, so it should work for other projects I guess. The common ground between these projects is the clients API, I think all involved, me included, agree with this now.

Anyway, it's absolutely not my aim to redo this discussion or to force something. I'm just sharing how I perceive the situation. People don't have to be friends, these social issues won't be resolved totally, no illusions, but it would be good to normalize the relations somewhat at some time, which doesn't have to be short time at all.

Somehow I feel that (new) developers should be sure, such a fork won't happen again, and where possible the current situation should be adjusted according to reasonable forking ethics. But that's totally up to the maintainer(s) to agree or disagree with, to act upon it or not atm.

Again, no intention to redo the debate or to play any role in this, but it would be nice if I open up the Internet in, let's say a year and I would see a situation where it's more fun to share ideas and code again, with a bit more guarantees for protection of the individual (developer).

grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

houston4444 wrote: Fri Mar 31, 2023 2:18 pm

I can imagine some kind of release schedule where a experimental feature is released first with a /raysession/... address, and if there is 'community-wide' consensus (good luck ;) ), it will be added to a /neonsm/ api. /neonsm, cause ideally I would keep the original API untouched, but this would need some extra thought.

Changing message paths between versions would be a nightmare, simply accept that /nsm/ is the protocol (relation server<->client) is simpler. I see no problem with the possibility of many session managers with the same /nsm/ paths and different capabilities. Capabilities has been done for that (I guess).

Ah it announces itself with that capability, no then it wouldn't make sense to change the path in that case.

For your patchbay, I could see it at least partly work in my workflow if I can pass the url of the NSM server to the patchbay I think. Then I would launch the patchbay from my session manager GUI with a script or command. Passing the url from the NSM server. Then the patchbay announces itself in some way to the NSM server of the given url. Then I would expect to be able to show/hide the NSM clients with the patchbay and do the connection stuff like I would do in njconnect or Patchage, while the patchbay is communicating the needed client information (gui visibility, client status) with the server and vice versa (which might be more complicated to implement).

edit: I'm not sure how JACK is integrated in your patchbay, that might complicate things maybe? I'm thinking of a situation where the patchbay is only handling my connections and the show/hide feature of NSM in this case. I start jackd myself and jackpatch is storing the connections. And I'm not using pipewire, that might also cause some nasty patchbay compatibility issues between jack and pipewire (now or later)?

Does raysession uses the same client id model as nsmd? Does Raysession use the same nsmd api/addresses for the server side, /nsm/server/open etc?

Anyway, there are certainly ideas how this could work, but has it any priority/hurry to work out these ideas? I think I've ideas, but I've to walk with them in the back of my head for a while first...
And probably need to use the patchbay a little more first as well...

houston4444
Established Member
Posts: 78
Joined: Mon Apr 02, 2018 6:53 pm
Has thanked: 3 times
Been thanked: 25 times

Re: What session managers do people prefer?

Post by houston4444 »

For your patchbay, I could see it at least partly work in my workflow if I can pass the url of the NSM server to the patchbay I think.

If you make a python3-qt5 GUI, it is perfectly possible and not so hard to implement the HoustonPatchbay submodule (which is a pure GUI thing), and adapt things.

edit: I'm not sure how JACK is integrated in your patchbay, that might complicate things maybe?

Not so complicated. in RaySession, JACK client is on another process (ray-jackpatch_to_osc (name could change latter, not very clear)), totally agnostic to NSM things.
It sends the present JACK ports and connections to the GUI. The GUI, because it knows which clients are presents (and there supposed JACK name), make the links between JACK clients and NSM clients, note that this link is finally just a supposition: A JACK client external to the session could perfectly be named as a present NSM client should name it.

And I'm not using pipewire, that might also cause some nasty patchbay compatibility issues between jack and pipewire (now or later)?

No problem with pipewire, it seems to fake perfectly JACK. The main disadvantage is that it makes a more complex patchbay, some users want the possibility to hide some boxes (https://github.com/Houston4444/HoustonPatchbay/issues/3).

Does raysession uses the same client id model as nsmd?

Yes and no, it can be ClientName, ClientName_N or ClientName.ClientId (as nsmd) (the last one is best and tend to be used in most cases). The ClientId generation is totally different though.

Does Raysession use the same nsmd api/addresses for the server side, /nsm/server/open etc?

Because the server is capable of ':server_control:', you can use theses /nsm/server/ messages, but the communication daemon<->GUI or daemon<->ray_control is done with /ray/server/ or /ray/session/ messages.

grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

Image

When I double click on the client in the canvas, it's sends a osc msg to the ray-daemon I suppose (show/hide)? So do I miss in the picture, a green line back to the ray-daemon from the client?

When I stop the client, it just stops and it's not shown in the patchbay anymore, cause that's what patchbays do I suppose. There is no nsm related communication between the daemon and the patchbay at that event?

So the only nsm related communication between the patchbay and the ray-daemon is client gui visibility status (shown/hidden)?

[ray-daemon]patch sends clean
[ray-daemon]patch sends dirty

hm

houston4444
Established Member
Posts: 78
Joined: Mon Apr 02, 2018 6:53 pm
Has thanked: 3 times
Been thanked: 25 times

Re: What session managers do people prefer?

Post by houston4444 »

Maybe I was not very clear.
In the picture, OSC (green) are supposed to exist in both directions (from ray-daemon to NSM Client 2, and from NSM Client 2 to ray-daemon for example).

Where you double click on the client in the canvas, you are in the GUI (HoustonPatchbay belongs to GUI process, it is a pure GUI patchbay). The GUI sends to daemon to show/hide the client (and then the daemon asks the client to show/hide).

When you stop the client, all its jack ports disappear, so the ray-jackpatch_to_osc receives an event from JACK with the deletion of the ports. ray-jackpatch_to_osc sends an information to the GUI for each event.

So the only nsm related communication between the patchbay and the ray-daemon is client gui visibility status (shown/hidden)?

If what you call 'the patchbay' is the GUI part of the patchbay, no, it also share to daemon canvas positions, because we need to save them in the session folder.
If 'the patchbay' is the core part (ray-jackpatch_to_osc process), no, there is no OSC relation at all between this and the daemon.

grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

houston4444 wrote: Sat Apr 01, 2023 8:22 pm

If what you call 'the patchbay' is the GUI part of the patchbay, no, it also share to daemon canvas positions, because we need to save them in the session folder.

Is it possible to not save the canvas position (in theory) and let the patchbay not save a file? Of course you'll loose the possibility to restore canvas position, but that's ok probably. Otherwise also the session folder should be passed to the patchbay, in a workflow I describe, where the patchbay is launched as external (connection/visibility manage) application. But most simple would be if it won't save anything in such a setup. Then it would only share gui visibility status with the server right?

Somehow in your setup the patchbay seems to be tight to a loaded session (communicates it's state of dirtyness and saves a file). For a modular approach, this might unnecessarily complicate things.

I've no plans to make such thing myself, but it's a nice example to think about, to make such thing possible. Let's say Patchichi is launched, without a url passed to it as argument, then it just assumes it's used as pure patchbay. If a url is passed to it, it tries to 'announce' itself as patchbay to the server and it will receive the needed info from the server when the visibility status of a client changes. Such a thing might work and might be useful probably indeed. Having some functionality of RaySession in a more modular setup.

houston4444
Established Member
Posts: 78
Joined: Mon Apr 02, 2018 6:53 pm
Has thanked: 3 times
Been thanked: 25 times

Re: What session managers do people prefer?

Post by houston4444 »

Is it possible to not save the canvas position (in theory) and let the patchbay not save a file?

Perfectly, It's really bad but totally possible.

Somehow in your setup the patchbay seems to be tight to a loaded session (communicates it's state of dirtyness and saves a file).

Aren't you confusing the ray-jackpatch and the patchbay (core or GUI) ? the ray-jackpatch is a NSM client, it saves and restore JACK connections, but has absolutely no responsibility in the displayed patchbay, it does the same job than jackpatch in NSM.

Let's say Patchichi is launched, without a url passed to it as argument, then it just assumes it's used as pure patchbay. If a url is passed to it, it tries to 'announce' itself as patchbay to the server and it will receive the needed info from the server when the visibility status of a client changes.

Not Patchichi, Patchance, but else, it could work.

grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

Perfectly, It's really bad but totally possible.

Why it is so bad? Less ideal I believe you, but Patchage (by drobilla) has a shortcut to reorganize the patchbay. Such thing could work probably.

If you've to to save a file, then the patchbay is related to or tight to a loaded session right? It has to save the file in the session folder, but when there is a other session loaded, that path to save to, changes.

Earlier quote:

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)

If develop the patchbay as a NSM client, it is tight to a session, sure you've problem 1. If used the way I try to think out, then 1 is solved at least (especially if you don't save anything with the patchbay).

I don't think I understand the patchbays design well enough (sorry) to understand problem 2.
Ah there is osc communication by some of them, some have NSM support, some don't? Maybe you can provide a example?

Aren't you confusing the ray-jackpatch and the patchbay (core or GUI) ? the ray-jackpatch is a NSM client, it saves and restore JACK connections, but has absolutely no responsibility in the displayed patchbay, it does the same job than jackpatch in NSM.

Ah, so these are messages from ray-jackpatch of course:
[ray-daemon]patch sends clean
[ray-daemon]patch sends dirty

patchbay, jackpatch... that's the confusion.

grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

grammo wrote: Sat Apr 01, 2023 10:16 pm

Otherwise also the session folder should be passed to the patchbay

Nah it could get the session dir from the server when it announces itself as patchbay, like it works with the NSM GUI. The only thing then left is sending the save signal to something that's not a NSM client (the patchbay). Not sure if this is doable in a clean way and if such thing is desirable at all. If the patchbay could easily be arranged with a keybinding, saving might not be needed at all probably.

/ray/pbay/announce
/ray/pbay/denounce

edit:

grammo wrote:

Let's say Patchichi is launched...

Argh, Patchance I'm talking about... the standalone patchbay.

nils
Established Member
Posts: 536
Joined: Wed Oct 22, 2008 9:05 pm
Has thanked: 35 times
Been thanked: 94 times
Contact:

Re: What session managers do people prefer?

Post by nils »

grammo wrote: Mon Apr 03, 2023 8:44 am

Nah it could get the session dir from the server when it announces itself as patchbay, like it works with the NSM GUI.

You mean with this message?

Code: Select all

When a GUI announces itself to nsmd it will receive the absolute path to the session directory
through the message /nsm/gui/session/root
grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

Then it also would need the root dir, that's right, but that's only at announce.

I think it's this: "/nsm/gui/session/name"

When a session changes.

Note, I'm just thinking if such thing would possible (it probably is), what the best way to do this is and after that if its worth and desirable (does it fit in the NSM design, or would it make things messy) to implement it. Like mentioned, if the patchbay won't save anything it will be more easy and clean probably. Then it acts just as sort of extra GUI, with limited capacities compared to a NSM GUI (but also this can make configurable maybe, some might want to do more with it).

If the patchbay has a clever way to reorganize it's view using a shortcut, that would be probably ok for me already (YMMV), but I've no or just little experience with Patchance. According to houston444 it would be really bad if it can't save, but doesn't say why that is yet (standalone Patchance can't save anything either now I think). It might be even worse thought to let the server send a save signal to a app that isn't a client. Should it reply, what should the server do, wait, react on error, something else? It would make the NSM design more complex for sure and so less predictable.

Anyway, for me it's just a interesting scenario to think out, to find out what info such patchbay would need from the server, but I might still reject at least parts of the idea (most likely the saving part), for myself at least. Perfection (save option) is the enemy of good (clear design) here probably.

  • Patchance is quite a unhandy name btw. Type in patcha and then autocomplete in shell with TAB, good chance you're looking at patchage instead.

edit:
I see two other ways to give user the possibility to save.
1) Ok, the server only takes responsibility for NSM clients to save, but if you want to save manually, go ahead.
2) Let the launcher (Agordejo for instance) take care of the saving part, so then Agordejo will for example first save the patchbay (and handle it's errors) and then send save to the server to save the session/NSM clients.

A patchbay with OSC support gives all kind of options, which are interesting, but at the end I'm pretty happy with a combination of njconnect (has fixed positions) and Patchage. Both don't save anything and I never felt they should. I could change Patchage for Patchance, then the possibility to be able to show/hide NSM clients might be helpful, but still, I don't see the possibility to save the canvas as a missing or needed feature, especially not if it has a clever way to organize it's canvas.

That concludes my brainstorm I guess.

Locked