Jack MIDI connections don't show with client/port aliases

[agraef]

Hi Rui, this is with the very latest qjackctl from HEAD, and seems to be the same no matter whether using Jack1 or Jack2.

With JACK client/port aliases set to "First" or "Second" on the Display tab of the Setup dialog, like this:

The aliases are shown alright, but the connections aren't. (This only affects the connection window, which I prefer; the graph window is alright.)

If I add a new connection, it sometimes briefly flashes into existence and then disappears again. Changing back the JACK client/port aliases option to "Default" all the invisible connections are shown alright:

It would be really nice if you could fix this, because I like the tidier view provided, in particular, by the "Second" option.

(BTW, can you elaborate how the "First" and "Second" views are constructed? I couldn't find any corresponding information on your website.)

[agraef]

seems to be the same no matter whether using Jack1 or Jack2.

Scratch that, the problem only arises with Jack2. Jack1 doesn't seem to support the aliases, so the connections view doesn't change at all, no matter what option I choose.

[agraef]

I should maybe have mentioned this, I'm running this on Linux (Arch Linux, or rather Manjaro, to be precise). ;-)

[rncbc]

hi @agraef , please don't use this "JACK client/port aliases", or at least keep it on the "Default" setting at all times; as Paul once said, many years ago, it's rubbish and one of his most regretful ideas (besides JACk itself) ;)

now that you remind me: I'll prolly considering to kill it; there's too many jumble in qjackctl that I'm afraid to get rid of... it happened before: some time, even years later, will come someone that bet his/her life on it and demand to get the thing back (or else :))

[agraef]

Ok, thanks. Not the reply I was hoping for, though, as I actually like the feature. But anyway, maybe we should keep this open until you "fix" the issue by slashing the aliases altogether? ;-)

[agraef]

Badly worded reply last night, let me try that again:

I have to admit that I only recently discovered this feature since I wanted to get rid of Jack2's generic (and rather useless, if you have many MIDI devices) Jack MIDI port names. But I solved this now with https://github.com/jackaudio/jack2/pull/945, so this certainly isn't a life-or-death matter to me. :)

Paul isn't always right, and he might be wrong on this one. Jack is likely to live on in one shape or another, it's something that people need and use (if only as a component in pipewire). And I still think that qjackctl is the best Jack frontend out there, despite all the attempts to replace it with glossy and flashy graphical interfaces. Yeah, I know that you've been falling victim to that as well. ;-)

Anyway, as it stands, Jack2 still supports those aliases, so why not keep this feature around and fix it, if it's not too much work? I can understand if you don't want to invest any time into it, so I'm willing to have a look myself. If you have the faintest idea what goes wrong there and can give me a hint before I start digging into the source, that would be much appreciated.

[agraef]

Specifically, I'm looking at qjackctlJackConnect.cpp, where I see qjackctlJackConnect::connectPorts(), qjackctlJackConnect::disconnectPorts(), and, qjackctlJackConnect::updateConnections(). These all use port names from qjackctl's internal data structures and pass them on to Jack API routines to set, unset, or query port connections. Could it be that there's a mismatch between the port names being used on the qjackctl side (if aliases are enabled) and the Jack port names?

[rncbc]

as said the JACK client/port aliases are utterly broken and non-functional on the qjackctl/Connections widget: it might show but then you don't see the actual connections nor you can connect them. sorry

[agraef]

Ok, I understand. Thanks for taking the time to reply. (I have some vague ideas on how to fix this. If I find the time, I'll look into it.)

[rncbc]

maybe fixed in ca4fec9 please test && tell thanks

ps. update: now prolly final in qjackctl >= 0.9.11.11git.119cdf

[agraef]

Thanks, will do!

[agraef]

"First" works now:

But "Second" lists all ports under a single device now (probably the last one?):

No cigar yet, but that's very close already! :) Only the device prefix needs to be fixed (of which there may be many in the aliases, not just one).

[rncbc]

well, "Second" never gave me anything meaningful either, so ?

a still think that this jack aliases (not to confuse with qjackctl aliases and/or jack metadata/pretty-names) are rubbish, useless and for crying ou loud, they should go away

dixit

[agraef]

well, "Second" never gave me anything meaningful either, so ?

Well, it did for me, as shown in the 2nd screenie I posted:

Of course, this depends on which Jack version you're running. Jack1 doesn't predefine any aliases afaict, but Jack2 does.

In any case, we're almost there, so it would be silly to give up now IMHO. Let me have another look at rev. 9b55062a680669f177127cd4e33a26957fa37eb7 over the weekend and see whether I can massage it to produce the right results for Jack2's second alias slot.

not to confuse with qjackctl aliases and/or jack metadata/pretty-names

Do you mean the "Enable client/port aliases" and "Enable JACK client/port pretty-names (metadata)" display options? I played around with both of these, with both Jack1 and Jack2, but they never seemed to make a difference. What am I missing there?

[rncbc]

Do you mean the "Enable client/port aliases" and "Enable JACK client/port pretty-names (metadata)" display options? I played around with both of these, with both Jack1 and Jack2, but they never seemed to make a difference. What am I missing there?

yep, TL;DR they let you rename client and port names to your liking ;)

[agraef]

Ah yes, I remember that now. That's nice, but I'm a lazy bum, so I just don't have the time to edit all that stuff manually. The advantage of the Jack2 auto-generated aliases are that they are, well, generated automatically, which saves me a lot of time that I can then invest into writing bug reports. ;-)

Concerning rev. 9b55062a680669f177127cd4e33a26957fa37eb7, I notice that at line 144 in qjackctlJackConnect.cpp, void qjackctlJackPort::updatePortName(), only the port name is set from the alias, but I'm not sure where the corresponding client name is supposed to be updated. There's no alias checking in qjackctlJackClient::updateClientName(). There is such code in qjackctlJackClientList::updateClientPorts(), but shouldn't qjackctlJackClient::updateClientName() also look at the aliases, like qjackctlJackPort::updatePortName() does?

[agraef]

Well, that won't work, because qjackctlJackClient::updateClientName() doesn't have the full port name, so it can't query Jack for the aliases. But maybe we can set the client part of the alias along with the port name in qjackctlJackPort::updatePortName(). Let me give this a try.

[agraef]

Nope, that doesn't work either, because qjackctlJackPort doesn't have the setClientText method. Catch 22.

I wonder whether that's the right approach. It seems to me that the connections view worked just fine with aliases even before rev. 9b55062a680669f177127cd4e33a26957fa37eb7. It was just the update of the port connections in qjackctlJackConnect::updateConnections() (in qjackctlJackConnect.cpp) that went awry. I'm pretty sure that this is because it iterates over the list of all connections retrieved with jack_port_get_all_connections(), which of course has the real port names which won't match any of the aliases in pIClientList->findJackClientPort(). At least that's my theory. :)

If I'm right, then it should just be a matter of fixing up findJackClientPort() so that it also considers the aliases of the port name it receives as its parameter. Incidentally, that's also what I alluded to as my "vague ideas" above. ;-)

I have to teach courses tomorrow, but I can hopefully have a deeper look at this over the weekend.

I have one more question, though: If I want to debug this stuff, I'll need to post some messages to the qjackctl messages window. Can I just do a printf to do that, or do I need to call a special log function for that?

[rncbc]

yes, you may have printf's or qDebug's in there and they will be sent to stdout/stderr as usual and captured to the messages window (depending of Setup > Options > Capture standard output option)

however, I've looked deeper and found something fishy on the "Second" aliases, esp. regarding midi ports from jackd2... it seems that some entries are not correctly prefixed by the client name resp. most esp. the "Midi-Through" client, which aggregates the whole lot of other jack-midi clients out there, but missing its "Midi-Through:" prefix, leading to a quite broken listing, exactly the trouble you're seeing in the "Second" set of aliases.

so it seems the bug is now in jackd2, qjackctl v0.9.11.11 is working just fine :)

[agraef]

Hmm, yes, I'll have to check that. Stay tuned.

Incidentally, my idea of just massaging the call to pIClientList->findJackClientPort() in qjackctlJackConnect::updateConnections() so that it also considers the aliases of the input ports on the fly (https://github.com/agraef/qjackctl/commit/3c9010e3e8a949dd5710fe2424f6414513a2b2b2), also seems to work, and without having to fix anything in Jack2 itself. Here's Jack2 with the Second option: This doesn't require all the renaming of ports that's going on in your changeset, so that might still be the tidier solution. Or maybe not. I'm not entirely sure that it fixes all the issues. Obviously you know your own codebase better than I do. :wink:

[rncbc]

This doesn't require all the renaming of ports that's going on in your changeset, so that might still be the tidier solution. Or maybe not. I'm not entirely sure that it fixes all the issues.

ok . that might show the existing connections alright, but... what about making new (dis)connections?

otoh. are you sure that your client/port listings above are not messed up? esp. the Midi-Through related ones, that of ports that strangely appear under some other client?

[agraef]

ok . that might show the existing connections alright, but... what about making new (dis)connections?

Yes, connections also work. As I said, the connections were already made alright, they just weren't displayed, and the sole reason for that is that qjackctlJackConnect::updateConnections() didn't use the alias names, which I fixed in https://github.com/agraef/qjackctl/commit/3c9010e3e8a949dd5710fe2424f6414513a2b2b2.

otoh. are you sure that your client/port listings above are not messed up? esp. the Midi-Through related ones, that of ports that strangely appear under some other client?

I am. Here is how it looks like if I go back to rev. 49661937b4c4083dbb3f7cb8169bdc190756c3dd on master (i.e., before your most recent changes), with https://github.com/agraef/qjackctl/commit/3c9010e3e8a949dd5710fe2424f6414513a2b2b2 on top:

And here is how exactly the same view (-Xseq with alias = Second) looks like with your current HEAD (rev. https://github.com/rncbc/qjackctl/commit/119cdf74f6f519ef51a0014271dc217b928d43aa):

It's clearly your most recent changes which broke the view. Also, I reviewed the code setting the aliases in Jack2's alsa_seqmidi.c, and there's really nothing wrong with it. Apart from some very minor cosmetic changes some 4 years ago, this code is literally the code that Stephane wrote some 15 years ago. If you don't believe me, have a look at the blames starting at line 477. I've been working on exactly this code for a PR the past week. So don't tell me that Jack2 is to blame here. :)

I'll tell you what we do. I'll send you a PR which reverts all the most recent changes that went into master after rev. 49661937b4c4083dbb3f7cb8169bdc190756c3dd, and adds my https://github.com/agraef/qjackctl/commit/3c9010e3e8a949dd5710fe2424f6414513a2b2b2. Then everything will be fine and dandy again once you merge this. Ok?

[agraef]

Done, see #197. Let's get this merged quickly and pretend that the recent breakage never happened. ;-)

[agraef]

Hmm, maybe wait a little longer. I have an idea on how to further improve the alias checking in my change.

[agraef]

All done and dusted, #197 is ready to be merged now.

[rncbc]

I' say it again, are you sure?

please hit "Expand All" while in -Xseq and "Second" set of aliases. I bet you'll see the SNAFU!

[agraef]

"Expand All" while in -Xseq and "Second" set of aliases works for me:

The devices are all there, connections are shown alright. I can also make connections in this view and delete them again:

This is with the qjackctl from the PR. I tried with both Jack2 version 1.9.22 from the Arch repositories and with the latest Jack2 from git. I don't notice anything unexpected there, do you?

[agraef]

Just to make sure, I tried with the latest from your master branch, works the same. If it doesn't work for you, it could be:

• hardware setup (unlikely; I tried unplugging all the extra MIDI gear that I have, and it still works; plug everything in again, still works)
• Jack configuration (again, unlikely, I use the default options except for the Yamaha AG03 USB mixer that I use as the Jack PCM device, realtime enabled, and the -Xseq and alias = Second options)
• Jack version and package (now there might be any number of differences there, depending on the Linux flavor and OS version that you have; I'm using the latest Manjaro here, with jack2 installed either from the official repositories, or from git via the Arch User Repositories)
• qjackctl build options (again, I'm doing nothing unusual here, qjackctl is configured with cmake -B build -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DCONFIG_QT6=ON)

It's hard to tell what's going wrong on your system without a bit more information. Maybe I'll be able to help if you at least post a screenshot of the "SNAFU" that you see. :)

[rncbc]

this is on "Default" aliases:

and this is on "Second" aliases aka SNAFU:

notice that, besides the messed up ports under some clients it also gets the "playback" and "capture" port roles swapped and this also shows in your last shot... WTF?

both of the above are from the merged PR#197 (qjackctl v0.9.11.13git.f60845)

[agraef]

Oh boy, this indeed looks completely garbled. :( Even your default view looks garbled. Do you have "Enable client/port aliases" turned on? (I don't.) Maybe there still are manual edits of the port names which mess up the view?

I can't imagine that my changes in qjackctlJackConnect::updateConnections() have anything to do with that.

both of the above are from the merged PR#197 (qjackctl v0.9.11.13git.f60845)

That's exactly the version that I am running, which works perfectly for me.

What Jack version do you use there? (Mine identifies as jackdmp version 1.9.22 tmpdir /dev/shm protocol 9.) If it's the same version, could you try Jack 1 instead? What Linux system is it?

Maybe it's a miscompiled Jack? Or a mishmash of different versions that you've been testing? Sorry, I'm grasping at straws there, but I've never seen such a mess in the connections view on any of my systems before...

[agraef]

Another idea, maybe clearing out qjackctl's config settings helps?

[agraef]

FWIW, here's what my About dialog shows:

[rncbc]

you might have a point on disabling the native (qjackctl) client/port aliases (or on clearing the qjackctl.conf)... but even though I've tried both and the result is the same mess, for the "Second" aliases set...

AND it doesn't solve or matter for the "capture" vs. "playback" ports that get listed in the WRONG columns, that even on YOUR side! didn't you noticed that?

jackdbus v1.9.22 here... let's try with classic jackdmp 1.9.22... nope. same SNAFU, sorry.

ps. the former point (re. native aliases enabled) maybe responsible for the "Terratec DMX6Fire" port name instead of the "Default" for "midi_playback_2", but that's all to it, and reckon as pretty ok--it got in last because the Connections client lists are sorted on the display text (the alias, not the original client name)

pps. not willing to revert anything on your PR whatsoever, it's all done and mission accomplished. thanks a lot.

[agraef]

Hmm yes, you're right. With the PCM device, capture is always on the left, playback on the right, the same is true with the default Jack MIDI view. It's the wrong way round with both aliases in seqmidi. That's a bug in Jack2, well spotted! Hopefully I can still fix this with the PR I have open at https://github.com/jackaudio/jack2 right now.

[agraef]

Ok, I fixed this now in the PR I have pending for Jack2, so it will hopefully be in the next Jack2 release. NB: The out and in port designations were also swapped some 7 years ago in Jack1 with commit https://github.com/jackaudio/jack1/commit/0b0953db926fc22f5cd93180461e7a98153628c5 which was authored by you. ;-)

[agraef]

pps. not willing to revert anything on your PR whatsoever, it's all done and mission accomplished. thanks a lot.

That's good news, thanks a bunch, I'm a happy camper now. :+1:

[rncbc]

NB: The out and in port designations were also swapped some 7 years ago in Jackd1 with commit https://github.com/jackaudio/jack1/commit/0b0953db926fc22f5cd93180461e7a98153628c5 which was authored by you.

oh yes I remember, but that's about jack1's alsamidi driver, by far and long ago an 110% better replacement to jackd2 broken -Xseq ... trust me!

that's history, jackd1 -Xseq is by far the best jack-midi driver... if using jackd2 then my only recommendation is: don't ever use the -Xseq setting, use a2jmidid instead

dixit again

ps. also, "Second" aliases are SNAFU. don't use it. you've been advised :)

[agraef]

Well, I think that we'll eventually switch to pipewire, because it makes things so much easier. In fact we've been taking it through its paces, but even the latest version has some glitches, especially with Ardour. So I went back to Jack proper for a while, and since Arch has Jack2 as the default Jack version now, that's what I use. I've actually been using a2jmidid with it, but I thought I'd give jack2's seq driver another try and make it work as well as I could. Hence all these bug reports and PRs. I think that it works rather well with #197 and jack2 #945 now, even with the aliases. So I'm closing this ticket.

It's been fun looking at the inner workings of qjackctl (at least some of it). I like qjackctl and have been using it for a really long time. It's functional and easy to use, and the compact connections view keeps my studio setup tidy and well-organized. Which is why I still use it with pipewire, too. Yes, I know about qpwgraph, but those graphical patchbays always look like a big unholy mess with the bunch of audio and MIDI devices that I have these days. :stuck_out_tongue_winking_eye:

Anyway, it was nice to have a little chat again, I hope that we can meet at another LAC soon!

[agraef]

Sorry, it's me again.

not to confuse with qjackctl aliases and/or jack metadata/pretty-names

I'm curious (and obviously I'm clueless about this): What's this jack metadata/pretty-names stuff that you mentioned? I see some documentation about that on https://jackaudio.org/, but I just don't get it. ;-) How am I supposed to use this? Just turning on the "Enable JACK client/port pretty-names (metadata)" toggle in the Display Setup doesn't seem to change anything in the connection and patchbay windows over here, neither in Jack1 nor Jack2.

[rncbc]

in a nutshell, it picks on the jack-metadata infrastructure and lets you rename clients and ports at your choice and whim;) these aliases will be shared among any other jack clients that support and read jack-metadata (ie. pretty-names) so it won't be a qjackctl exclusive.

ps. these kind of aliases are also featured in the Graph, while the other kind, the ones we've been dwelling in this issue, are not (and never will, sorry to tell).

[agraef]

Ok, I think I get it now. Thanks for the explanation. :)

Still, in the connections window I can only see pretty-names that I have edited myself, even if I turn on the metadata toggle. The thing is, Jack2 actually sets default pretty-names for all the Jack MIDI devices, but those are not shown in the connections window, that's why I thought the option wasn't working.

E.g., on my system with Jack2 I have (just listing the first few ports for brevity):

$ for i in 1 2 3 4 5; do jack_property -p system:midi_capture_$i http://jackaudio.org/metadata/pretty-name -l; done
Midi Through
APC mini mk2
APC mini mk2
AG06/AG03
MPK mini Plus

That's after a fresh start of Jack2, no manual edits of the port names. Those pretty-names are generated automatically by the -Xseq driver. And they are shown alright in the graph window:

But not in the connections window:

So there might still be a bug lurking there in qjackctl. Maybe I'll look into that some time...

Alas, none of the existing metadata/aliasing mechanisms seem to apply to the patchbay window. There I always have to use the real portnames in the regexes, is that right?

[rncbc]

So there might still be a bug lurking there in qjackctl. Maybe I'll look into that some time...

yes probably... besides your recent PR, qjackctl/Connections hasn't seen any code changes for ages...

Alas, none of the existing metadata/aliasing mechanisms seem to apply to the patchbay window. There I always have to use the real portnames in the regexes, is that right?

yes. definitely.

[agraef]

yes probably... besides your recent PR, qjackctl/Connections hasn't seen any code changes for ages...

I understand. Making the graph window the new default for doing connections, you sent a clear message to all qjackctl users after all. I'm sure that I'll eventually learn to love it, too. To help with that, I actually switched the "Connections" button back to "Graph" again. :)

I'm still glad that we got the alias connections issue sorted out, since that was a genuine bug. I don't see any other grave problems when using jack2 with qjackctl any more, and the default metadata issue with the connections view can also be seen as a design choice.

[agraef]

Maybe it's time for a summer release in August? Just sayin'

[agraef]

I think I found the problem with the metadata in the connections window, see #198. Here's how it looks like with Jack2 from my PR over at https://github.com/jackaudio/jack2/: Which now matches the graph window:

[rncbc]

fyi. merged #198

not quite related to the fix at hand, but ntl...

it's been known and discussed some time ago, with the jack2 devs/maintainers at the time, that ANY meta-data that is set at the server side or in premises like the -Xseq driver does on jackd2, will simply preclude any persistent renaming from qjackctl client side: you may think that you can rename the thing but then it will fail to be remembered or survive the next jackd2 service start.

and you may ask, why? because the dang server overrides the pretty-names no matter what on its startup, all the time!

this is just a fair warning to all the sailors out there ;) also, let there be known that this very annoyance is not exclusive to the Connections view: it also affects the Graph.

you've been warned :)

ps. of course it can be fixed, but in its current incarnation qjackctl is not simply prepared to deal with this. so sorry. cheer up!

[agraef]

Hmm yes, I can see this. Well at least with the connections view, I can disable the metadata option to make the edits take effect again (note the Midi Thru port, that's the one I edited): I think that's because of the check for the bRename flag in qjackctlJackPort::updatePortName(), qjackctlJackConnect.cpp:135. That way edits always take priority.

qjackctlJackGraph::findClientPort() in qjackctlJackGraph.cpp lacks such a check, though, and thus will happily overwrite node and port titles with anything it finds in the metadata. But that's very easy to fix, by just moving the loops which iterate over the alias lists behind the code that check for the metadata, i.e.:

diff --git a/src/qjackctlJackGraph.cpp b/src/qjackctlJackGraph.cpp
index 82130c0..abc783d 100644
--- a/src/qjackctlJackGraph.cpp
+++ b/src/qjackctlJackGraph.cpp
@@ -348,8 +348,6 @@ bool qjackctlJackGraph::findClientPort ( jack_client_t *client,
        if (add_new && *node) {
                int nchanged = 0;
                QString node_title = (*node)->nodeTitle();
-               foreach (qjackctlAliasList *node_aliases, item_aliases(*node))
-                       node_title = node_aliases->clientAlias(client_name);
        #ifdef CONFIG_JACK_METADATA
                const char *client_uuid_name
                        = ::jack_get_uuid_for_client_name(client,
@@ -364,14 +362,14 @@ bool qjackctlJackGraph::findClientPort ( jack_client_t *client,
                        ::jack_free((void *) client_uuid_name);
                }
        #endif  // CONFIG_JACK_METADATA
+               foreach (qjackctlAliasList *node_aliases, item_aliases(*node))
+                       node_title = node_aliases->clientAlias(client_name);
                if ((*node)->nodeTitle() != node_title) {
                        (*node)->setNodeTitle(node_title);
                        ++nchanged;
                }
                if (*port) {
                        QString port_title = (*port)->portTitle();
-                       foreach (qjackctlAliasList *port_aliases, item_aliases(*port))
-                               port_title = port_aliases->portAlias(client_name, port_name);
                #ifdef CONFIG_JACK_METADATA
                        const QString& pretty_name
                                = qjackctlJackGraph_pretty_name(port_uuid, port_name);
@@ -384,6 +382,8 @@ bool qjackctlJackGraph::findClientPort ( jack_client_t *client,
                                ++nchanged;
                        }
                #endif  // CONFIG_JACK_METADATA
+                       foreach (qjackctlAliasList *port_aliases, item_aliases(*port))
+                               port_title = port_aliases->portAlias(client_name, port_name);
                        if ((*port)->portTitle() != port_title) {
                                (*port)->setPortTitle(port_title);
                                ++nchanged;

That way edits take priority there, too:

I can send you another PR for this. I also still want to fix qjackctlJackClient::updateClientName() which has the same kind of glitch that I just fixed in qjackctlJackPort::updatePortName() with #198.

[agraef]

199 should take care of this. I wonder, though, whether the graph window also needs to check the global bAliasesEnabled and bJackClientPortMetadata flags in order to determine whether to actually consider alias and metadata information at all when constructing the view. I see corresponding checks in the connection window, but it seems that qjackctlJackGraph::findClientPort() will happily use both no matter what.

This stuff makes my head hurt. :) Give #199 some time, so that I can get this sorted out as well.

[agraef]

I wonder, though, whether the graph window also needs to check the global bAliasesEnabled and bJackClientPortMetadata flags

Well, I gave it the good old college try, but couldn't make it work. :) But #199, as it stands, is certainly an improvement, since persistent edits also work in the graph window with Jack2 now, if you turn off the metadata option in the display setup. (EDIT: For the graph view, disabling that option isn't actually needed, with #199 edits will survive a restart of the server and of qjackctl itself. Unless the alias option is also enabled, in which case the connections window will now override the alias from the metadata, I still need to figure out a way to fix this.)

I'm done with this, I need to work on other things...

[agraef]

BTW, #198+#199 still need to be tested with Pipewire. I'll do that tomorrow.

[agraef]

the dang server overrides the pretty-names no matter what on its startup, all the time!

Yes, looking at the git blames, I can see that those changes got added some 4 years ago. Specifically, https://github.com/jackaudio/jack2/pull/505 was the PR which introduced the initial metadata settings for the Jack MIDI ports. This was an attempt to work around the problems with the generic default Jack MIDI port names which the Jack2 devs don't want to change anymore because of backward-compatibility concerns, lest the Jack2 users of the world will come at them with their pitchforks. ;-)

This works as intended, but of course this makes things much harder for client applications like qjackctl which operate under the assumption that the server will never set this metadata on its own, as it is with Jack1.

Anyway, I think that #199 mitigates most of these ill effects. I still need to figure out a way to ensure that the connections view doesn't stomp on its own edits when the server is restarted, though. Stay tuned...