(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]> 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]> 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]> wrote: >> >>> On 04/01/21 00:49, J. Liles wrote: >>> >>> On Sun, Jan 3, 2021 at 4:38 PM Filipe Coelho <[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]> wrote: >>>> >>>>> On 03/01/21 23:57, rosea.grammostola wrote: >>>>> >>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>>>> On Monday, January 4, 2021 12:47 AM, Filipe Coelho <[email protected]> >>>>> <[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 >>>>> >>>>> >>>>>
