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