Filipe, respectfully, I believe it is you who do not understand the problem. Consider that, as the inventor of NSM, I have spent an awful lot of time thinking about this stuff. Read over what I said about implicit and explicit disconnection and see if you can relate it to the subject at hand and understand where I'm coming from. This is not a high priority for me personally and as I said there's nothing I can do about it in NSM/JACKPatch. The only thing I could do without recourse to changing JACK would require that I also had control over *every* connection manager in play (patchage, Non-Mixer/Timeline, QJackCtl, etc), so I'm not going to spent a lot of time trying to explain the nature of the issue to you. You can figure it out for yourself if you just look deeper.
On Sun, Jan 3, 2021 at 5:37 PM Filipe Coelho <[email protected]> wrote: > 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]> 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 >>>>>> >>>>>> >>>>>>
