jackpatch "forgets" connections

[diovudau]

There is a known problem with jackpatch, that it seemingly "forgets" connections, thus creating a feeling of unreliability. Many users, myself included, have run into this.

There were discussions about this in IRC for many months now and I wanted to document that here.

The problem is that jackpatch saves exactly all jack-connections at the moment it receives the NSM save instruction. It has no log, no history and tries not to be "smart".
If, for whatever reason, a client is currently not present it will not be remembered and all connections are permanently lost. For example: this can happen because a client crashed, was closed temporarily to save system resources or (probably most often) the user was done with work and began to close programs manually and then changed to use NSM to save & close them all.

Proposed solution:
On the one hand it is very good that jackpatch is as simple as possible. "No user interaction" must remain the guiding principle. Behavior that is easy to understand and predictable

On the other hand this problematic behavior crosses the line because it creates real problems for the users. It is only "predictable" if you know what is actually happening. Demanding this from the user (or disguising it as "user education") is not the way forward.
The expectation is "if I add this to my session it will remember all my jack connections between NSM clients "

The current idea is to change jackpatch to never forget any connections it once saved FOR CLIENTS THAT ARE NOT CURRENTLY RUNNING.

There is a very unlikely statistical problem that this might recreate unwanted connections. However the risk that four clients of the same type receive the very same randomly generated ID is next to nothing, especially since I already improved the random ID generation in a previous release.

Please note that removing a client permanently from the session and then later add the same empty program again will not re-use the old connections. For Jack, NSM and jackpatch these are different programs because they have a different random ID.

Since this jackpatch change will not remember every temporary connection ever made (but only the ones when you press save) the amount of additional data is expected to be small enough.
A "reset" option is simply to delete jackpatch from the session and add a new instance, which starts with a fresh memory.

All other improvements to jack connection handling should be included in another (not yet existing) program that can be used instead of jackpatch. Wishes so far include the options for potential timeouts for previous connections, remembering graphical patchbay positions, only including actual NSM clients in the session etc.

Example

With the current jackpatch:
First I create the connections as shown above, then press NSM "Save". Jackpatch will now correctly save all existing connections. Now, if I close Patroneo, then save&close the session and reopen it Patroneo will start, so will Carla. But the connections will be permanently lost and I have to recreate them by hand.
Also: If I disconnect Carla/Melody from jack_mixer manually and then save it will not get restored, which is correct behavior. This example is only here for comparison to the new behavior below:

Proposed new behaviour: Again, create the state from the screenshot and press save. All connections are (still) correctly saved. Now close Patroneo and press save&close: jackpatch will see that it once had a "Patroneo" client connected to Carla and will remember the connections. If I open the session again later it will correctly restore the connections to the state of the screenshot.
Also: Disconnecting Carla/Melody from jack_mixer manually and saving it will still remain correctly disconnect, because at the moment of save both clients were present and thus only the current connections will be remembered. So: No change to the current behavior because it was already correct, albeit for different technical reasons.

[Houston4444]

Hi. If I understand correctly, the behavior you want is exactly the ray-jackpatch one from the start.
I see little (and rare) problems that could happens, you mention it here:

There is a very unlikely statistical problem that this might recreate unwanted connections. However the risk that four clients of the same type receive the very same randomly generated ID is next to nothing, especially since I already improved the random ID generation in a previous release.

Factually, in New Session Manager, the chance to remove and re-add a client with the same client_id is very very minor (that's not the case in RaySession). But it could happen in the case user uses simultaneously two NSM instances when one session is duplicated from the other one. In true life, probably no one do that, but I am quite surprised to see some users using RaySession as a "Studio", they always launch the same session even for different songs, and externally launch one program with the wanted project. That wasn't designed for that, but I can't blame them, it is simpler than doing this with a shell script (users are not supposed to have shell script knowledge).
That make me thinks to the way simultaneous sessions could work better with JACK (the only interestof simultaneous daemons I can see is to have one studio session and one song session), maybe the solution could be to decide that a "studio" session (or whatever it is called) adds a string key between client name and id (Patroneo.nJMPX could become Patroneo.stud.nJMPK). Sorry, this is near off-topic, this is obviously not something to see now, as I said ray-jackpatch works the way you expect for years without any complaints.

[diovudau]

A possible way out of the "duplicate session" scenario would be to regenerate all random client IDs. However, that generates new problems that are potentially worse. For starters it requires parsing and renaming of client files. That is at least a non-trivial change and I see high risk for regressions. That said, if that would work perfectly it would be a good solution. Or even better: Only rename actual conflicting clients. Then potential static system setups outside the session have a higher chance of working (like a global jack_matchmaker waiting for a certain connection) .

Between all these real solutions and problematic solutions I am at least certain they are all better than the current state. Because the current state is known to break the "normal" usecase and all others are just corner cases.

[Houston4444]

Between all these real solutions and problematic solutions I am at least certain they are all better than the current state. Because the current state is known to break the "normal" usecase and all others are just corner cases.

That is true.

When I was talking about key string (Patroneo.stud.nJMPK, ClientName.Key.client_id), I was talking only about given JACK client name, no need to rename the files and folders. Given path for files could still be ClientName.client_id. That is just an idea.

[diovudau]

This has finally been resolved.