Discover, remember and apply connections

[thomasfinstad]

Would it be possible to have a different ruleset that would match connections being made and store them so they can be applied again automatically?

I was thinking it could have lower prio than anything explicit from the current ruleset, but a wildcard regex would then mean you will no longer have to write down every thing you need to match, making the setup and testing phase of a new system much quicker.

Might be easier to only have a toggle for "remember connection" if the rules way seem redundant.

If this can be implemented it would probably be good to either store the connections in a human readable format or have a cli option to list and remove parts of the db/list.

[SpotlightKid]

You can just do:

 jack-matchmaker -c > my-connections

and use the resulting file as input with the -p option.

Would that solve your requirements? If not, what do you think is missing?

[thomasfinstad]

With some cli work using diff and patch and remove remembered connections manually when needed I could possibly make this work, so the only thing missing when going this route that I can see is that there is no way to automatically "forget" connections when a connection is unplugged, but the client/inout/output remains (meaning the connection was removed not the port).

If this is out of scope I think I will be able to make it myself, but the lib you are using seems somewhat complex for me so I would probably create it using https://jackclient-python.readthedocs.io/en/latest/ That might mean it would not fit too well into your code if you would want to reuse it.

[SpotlightKid]

I'm not sure yet, whether I understand they way you want t work. Can you describe your workflow how you wan it to be with some concrete examples?

As to jacklib vs jackclient-python, jack-matchmaker was created before the latter provided all the functionality it needed. If I was to write it again today, I would probably use jackclient-python. jacklib sticks closer to the C library API.

[thomasfinstad]

I can try to lay out a senario or two.

Remembering the connection (much like what happens today):

1. User make a connection from client1-out to client2-in
2. User closes application1 (owner of client1)
3. User opens application1, connection is remade.

Forgetting a connection

1. User make a connection from client1-out to client2-in
2. User manually removes connection from client1-out to client2-in
3. The connection is no longer automatically made when application1 is closed and opened again

Remembering the old and forgetting the new

1. User make a connection from client1-out to client2-in
2. User make a connection from client3-out to client4-in
3. User closes application1 (owner of client1)
4. User manually removes connection from client3-out to client4-in
5. User closes application2 (owner of client3)
6. User opens application1, connection is remade (client1-out:client2-in).
7. User opens application2, no connection is made since it was manually disconnected before closing the app

For this to work smoothly as it is today you would have to take the output of jack-matchmaker -c only when every single app you wish to remember is open and connected, or you have to check for the diff between the new and old config and only add in the new stuff, and manually remove connections you no longer want from the resulting text file.

It would be nice if all historic connections are remembered and added to the file, but also be able to forget connections when they are manually disconnected from each other in a patchbay/connections graph app.

[SpotlightKid]

It would be nice if all historic connections are remembered and added to the file, but also be able to forget connections when they are manually disconnected from each other in a patchbay/connections graph app.

Unfortunately, I don't think there is a way to know for a JACK client, which listens to connections being removed (and made), whether they were removed "manually" (what does that even mean exactly?) or because a client was closed.

Thus, AFAICS, the user needs to trigger saving the connection state at that point in time when all desired connections are present.

I suppose it would be possible for jack-matchmaker to record a history of all connections as they occur, which could be a basis for creating your pattern file.

[thomasfinstad]

Unfortunately, I don't think there is a way to know for a JACK client, which listens to connections being removed (and made), whether they were removed "manually" (what does that even mean exactly?) or because a client was closed.

I don't think there is any direct way either, I was thinking to just wait 500ms or so after the connection is removed and if there was no even that the client was removed that probably means the connection was manually removed/disconnected. What I mean by manually is just that I notice that there is no difference I could see in the events of a connection being removed because you disconnected it yourself, or automatically because the application was closed, so I wanted to specify manually.

[SpotlightKid]

so I wanted to specify manually.

Yes, for the user the intention might be clear, but for jack-matchmaker there isn't any difference. I don't think resorting to heuristics is a good way to approach this. I think there needs to be a way for the user to state his intention, i.e. declare a connection to be retained for the future, even if it is removed now (or the opposite).

I'm unsure whether jack-matchmaker is the right tool for this, because I think you'd need some kind of interactive interface for this, other than the commandline.

[thomasfinstad]

I think it might work, but I don't enjoy the thought of "I guess 0.5 seconds is enough time to wait" as the messurement either, just don't know of a better way. In any case, if does not fit then I will see if I am able to make my own thingy as I do not want to force the user to make the connections in my app I will try the heuristic way and see if it works well for me.

[SpotlightKid]

Thinking about this again, I decided that this is out of scope for jack-matchmaker. Like I said above, this would require it to retain a history of all connections made and removed and some sort of user interaction to decide which ones to keep. jack-matchmaker is not designed for this. A new tool designed with this goal in mind from the start (probably with a GUI) would be better.

So I am closing this as wontfix.