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