[00:36] Eickmeyer: I am assuming the binary is called agordejo [00:36] OvenWerks: Yes, it's agordejo. [00:36] I even just double-checked. [00:37] It should just work then [16:22] Hmmm, having trouble figuring out what I really want in a monitor mixer... [16:22] looking at zita-mu1, jack-mixer and jack-mix-box [16:25] mu1 is really "too much", jack-mixer doesn't totally make sense and adds a monitor channel if we want it or not :) [16:27] jack-mix-box is CLI only and very basic... n channels sets in to one channel set out. (set may be set of one or two) [16:35] Eickmeyer[kde]: not sure you saw all the above comments as I seem to have reconnected or something [16:36] OvenWerks: I'm reading now. [16:37] hmm, "connections" in qjackctl does not list ports in numerical order but alphabetical. [16:37] OvenWerks: That's one place where Ardour or MixBus would be better/simpler. That or two instances of jack-mixer. [16:37] Carla list them in numerical order [16:37] Controls lists them in alphabetical too, does it not? [16:38] yes [16:38] I think the issue Milkii was having was that the loopback devices were listed first, which makes sense given the alphabetical order. However, he's right: loopback devices shouldn't be first. [16:38] portlist = jackclient.port(portspec) [16:38] Of course, we didn't account for that early on. [16:39] The reason loopbacks are first is because they end up being hw:0.* [16:39] Ah, I see. [16:39] So, they're first alphabetically and numerically. [16:40] I think what I will do is to put hw:LOOPBACK in with append and everything else with prepend [16:40] Yeah, that's really the only solution. [16:41] (actually its not prepend but insert(0) :) [16:42] BTW, had another bug report about 2.0.8 in Fedora early this morning. Apparently 2.0.9 got stuck in testing and I had to manually push it to stable, so that should fix their issue. [16:44] OvenWerks: Did you see the PR this morning that does some fixing to Autojack? [16:44] issue 11 seems to have been temporary but the poster has not commented any more... not really our problem anyway. [16:45] Yep, close as invalid in that case. [16:45] yuck [16:46] invalid/won't fix. Just sucks that there's nothing we can do in that case. [16:46] Is their version of jack_control broken? [16:47] I don't know. Looked like 20.04, and I haven't seen any others like it. [16:47] I mean the PR [16:47] Oh, that one. [16:48] I'd ask. It does seem odd that they needed each command on a different line. [16:48] And the reasoning that it fixes pulse-bridge problems? [16:49] That should be totally unrelated [16:49] Yeah, apparently. 🤷‍♂️ [16:49] I think it definitely warrants further discussion as to the logic behind the fix. [16:53] It is connected with issue 14 [16:53] The logic in issue 14 is flawed as well [16:54] Same poster. [16:54] he posts jackdbus output: Acquire audio card Audio0 and then because that fails aserts that start was not received [16:55] Looks like Arch is using a slightly newer version of python-jack-client. [16:55] He thinks that jack.client tred to start it. [16:55] I will check. [17:02] he may be right. I have used the c++ calling convention where if call(string, bool x = false) is speced I can just go call("string", true) but I may have to do call("string", paramter_name=True) in python. [17:04] All that to say, I thought I was calling jack.client with no_start_server=True [17:05] but am probably not [17:05] I think this is really a good time to switch jack_control calls to direct dbus calls [17:08] Might be. Seems as though he pointed out an underlying problem, if that's the case. [17:09] I think it is more related to system speeds than anything... by todays standards my "new" i5 is probably slow :) [17:25] Well, I was just gifted a Kubuntu Focus M1, so I'm flying warp speed now. :) [23:21] Eickmeyer[m]: I think I will add monitor: True to the dummy backend.