I dont think the problem is clear to you at the moment.
This is not about disconnecting ports, but connecting them.
Even if jackpatch would remember connections from clients that have
quit, or stopped by NSM, it cannot possibly know if the client is
removed from the session or not.
So without jackpatch talking to NSM server, we have 2 possible situations:
1. jackpatch does not save connections for clients that are not running.
With this, we can lose connection data if an application was stopped
temporarily. Connections were made before, that when loading back the
session are not restored.
2. jackpatch saves and keeps connections even for clients that are not
running anymore.
With this, the list of connections keeps going forever, as jackpatch
cannot right now know if something is no longer part of the session and
thus not needed.
Conflicts will arise as soon as the same client name is reused later on.
There is a limit to the "unique id" given by the NSM server.
On 04/01/21 01:10, J. Liles wrote:
(and of course I don't think any solution to this problem can be
perfect, because it's impossible to always correctly guess the user's
intentions).
On Sun, Jan 3, 2021 at 5:08 PM J. Liles <[email protected]
<mailto:[email protected]>> wrote:
Why would it care? Closing a client is equivalent to unplugging a
MIDI interface. You might plug it back in and you might restart
the client and if JACKPatch remembered the connection for you,
that would be exactly what you want. But when you open Patchage
and sever the connection, you really want it to stay severed/be
forgotten.
So I think any time a client is terminated or a device is
disconnected, the message from JACK should be different than the
message sent when a connection is explicitly disconnected.
To be clear: the distinction is between implicit disconnection
(client killed) and explicit disconnection (connection manager used).
On Sun, Jan 3, 2021 at 5:00 PM Filipe Coelho <[email protected]
<mailto:[email protected]>> wrote:
How would jack know about a client that is stopped because the
user closed it, or stopped because it got removed from NSM?
Some collaboration/talk between NSM and the patch tool is
needed in order to make this possible, as far as I can tell.
On 04/01/21 00:57, J. Liles wrote:
Personally, I've already put enough thought into it to decide
that it must be addressed in JACK.
JACK needs to give JACKPatch a way to distinguish between a
client disappearing and a connection being explicitly severed
by (proxied) user action.
AFIAK there's nothing in the JACK API for this.
Add that, and I'll change JACKPatch so that it only forgets
connections that are explicitly severed, rather than ones due
to the client or port disappearing.
Obviously there are probably some more subtle issues
involved, but I'm quite sure it's not JACKPatch's problem.
On Sun, Jan 3, 2021 at 4:54 PM Filipe Coelho
<[email protected] <mailto:[email protected]>> wrote:
On 04/01/21 00:49, J. Liles wrote:
On Sun, Jan 3, 2021 at 4:38 PM Filipe Coelho
<[email protected] <mailto:[email protected]>> wrote:
On 04/01/21 00:20, J. Liles wrote:
For the bystanders: one thing that's funny about
all this is that I use Non every day, including
NSM, and I have a very low tolerance for
buggy/crashy software, and in all this time, with
all the fork drama etc. I've worked on Non, adding
things I need, fixing bugs I encounter. Well, in
all of that, I can't recall having needed to make a
single change to NSM. It just works. So this idea
that there's is or was some dire usability issue
with NSM is to me laughable.)
The link I posted from Nils disagrees with you.
https://linuxmusicians.com/viewtopic.php?f=24&t=21772&p=121745#p121745
It is expected that it works for you.
My tools also work for me, but then people find
issues by doing things I am not doing. Bugs are
still there, even if I dont ever experience them.
Yes, I understand that people encounter weird bugs on
different systems and with different clients and all
that. But those are not justifications for the actions
you and your comrades have taken. What justification do
you have for not politely submitting a PR? I like fixing
bugs just as much as the next guy.
The "justification" is that it is much easier to report a
bug than it is to fix it.
Plus, FLTK/NTK is not widely used, so most people do not
know it (yet). Perhaps a few things would be simple
things for you to do.
In any case, a ticket is not a demand. Just brings
visibility to the issue. Who knows, maybe someone else
sees it and decides to fix it.
Not everyone is a developer, we should not be asking
everyone to submit patches instead of issues. Some are
just incapable of that in the present time.
Sure, there are many things I wish I had. Fillipe
says that JACKPatch has some "usability problem." I
disagree. It is what it is.
To be clear here. The issue is that jackpatch
ignores applications that are no longer running.
If you have a session where you temporarily want to
stop closing something just to focus on one part of
it, then save, connections for all the other
applications are lost.
It is very annoying when it happens, often
misinterpreted as a bug of the SM.
I have a few ideas on how to go about
solving/working-around it, and others have
alternative ideas. There was no true consensus yet.
Maybe it is just not something for jackpatch to deal
with, but a new tool. You seem to think the same way
from what I understand on the messages below.
Yes, but that's not a problem with JACKPatch. That's why
I say, "it is what it is." The problem is with the
protocol, which is JACK's domain, and anything I could
do in JACKPatch would be a crappy workaround. I'd be
happy to discuss the matter. But you really shouldn't go
around accusing people of having flawed software when
the flaw is in the underlying subsystem.
NSM is quite good, this was/is not a criticism.
There exists still a user-experience problem, this is not
an accusation.
I will be happy to discuss a possible solution too, just
waiting for all to calm down a bit more first.
But it would be nice to have a better connection
manager than Patchage to pair with it, and maybe
some extra info from the JACK API to identify
certain tricky scenarios that JACKPatch currently
has no way to know about. Maybe if I could drive
home the NSM "everything is a client" philosophy a
little harder, people would stop blaming NSM for
being incomplete, when the fact is that it was
never intended to be a complete solution for
anything other than supporting sessions of clients.
Clients therefore, are the seat of your
extensibility. Write a client that does something
cool and you can have all the fame you like and
with no obligation to share it with me or NSM.
On Sun, Jan 3, 2021 at 4:09 PM Filipe Coelho
<[email protected] <mailto:[email protected]>> wrote:
On 03/01/21 23:57, rosea.grammostola wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 4, 2021 12:47 AM, Filipe
Coelho <[email protected]>
<mailto:[email protected]> wrote:
1. the new-session-manager fork was done by
Nils, not me. I appreciated the effort and
contributed some little things afterwards.
The idea for a fork was yours Filipe. You're
fully responsible for it, together with Nils.
There is no point in denying or downplaying
your role.
Huh? Where did you get this from?
I approved the idea of a fork, yes. Not sure if
I was the first one to suggest it, I am pretty
sure a bunch of people thought about it too.
I did say that I would maintain the "old" GUI
if needed, you can point the finger at me for that.
But wait, just because I have an idea for
something, how does it make me responsible for it?
It would not have happened if others did not
have interest on it.
Stop making it all on me.
Thanks
