[00:04] <OvenWerks> autojack has been using a device database almost from the start... this is new since 2.0.21 for studio-controls
[00:56] <OvenWerks> Eickmeyer[m]: if autobuild is at auto a new vesion should show in the next 24 hours... or do you need to do some action first?
[00:57] <Eickmeyer[m]> OvenWerks: I've been updating it manually, I think autobuild is stuck on the old stuff. lp:ubuntustudio-dev/studio-controls-staging is where I've been putting it. I'm working right now, I might be able to do an upload this evening. :)
[01:06] <OvenWerks> no problem. I have changed the gui layout again and I think it looks a lot better.
[01:08] <OvenWerks> Eickmeyer[m]: it odes work with a USB MIDI only device now.
[03:47] <Eickmeyer[m]> OvenWerks: Building now: https://launchpad.net/~ubuntustudio-dev/+archive/ubuntu/studio-controls-staging
[04:23] <Eickmeyer[m]> OvenWerks: I just installed it and ran it through a small gauntlet. I love the new layout, it's brilliant. The shortcuts for session management also work, ran it with agordejo and it was good (if only we can get agordejo to build on hirsute...). Overall, A+, and I know there's more to come.
[04:47] <OvenWerks> Eickmeyer[m]: just looking at it again. Pulse output ports all say stereo pairs (1-2, 3-4, etc) but the reality is channel a to (a + count - 1)
[04:49] <OvenWerks> So how should put that in the drop down? Oh and autojack would happily handle 2 - n as well.
[04:49] <OvenWerks> it doesn't have to be odd - even.
[04:50]  * OvenWerks has always thought of more than stereo as a gimick... and mono correct for a live environmet in most cases
[15:18] <Eickmeyer[m]> OvenWerks: Agreed, mono is correct for a live environment. Maybe change it to a fill-in-the-blank variable?
[17:01] <OvenWerks> Eickmeyer[m]: I realized the textbox beside the count and port widgets already says the right thing so I have chnaged the port widget to just show the list of ports instead of pairs of ports. Anything on the list is the "first" port of a set.
[17:05] <OvenWerks> Eickmeyer[m]: of course now Main output ports needs to have "count" as well.... but then what to do with headphones? Maybe someone where two sets of headphones so they can mon itor their "Quad mix"?
[17:06] <Eickmeyer[m]> O_o
[17:06] <OvenWerks> actually I think I will leave it as is unless someone bugs me about it
[17:06] <Eickmeyer[m]> Yeah, I'd leave it.
[17:06] <Eickmeyer[m]> If people are using two sets of headphones it's because they're testing headphones. :P
[17:08]  * OvenWerks remembers a picture on the back of a vinyl sleeve with someone with two headphones one crosswise with a caption "<name> listening to the quad mix"
[17:09] <Eickmeyer[m]> HAHAHA
[17:10] <OvenWerks> (back in the 70s)
[17:12] <OvenWerks> Eickmeyer[m]: there are two feature requests left (well three but internationalization is not happening right now)
[17:14] <Eickmeyer[m]> Right. I'm not sure if I like #23.
[17:14] <OvenWerks> why?
[17:15] <Eickmeyer[m]> Actually, I reevaluated it after I typed that. Doesn't seem like a bad idea, just an advanced feature.
[17:15] <Eickmeyer[m]> And #30 should be lowest priority. Logging xruns seems almost like a waste of time.
[17:15] <OvenWerks> I suppose it may confuse newbys
[17:16] <Eickmeyer[m]> Yeah, and that's where I'm at with it. We're trying to make this stuff as easy as possible to use, but adding latency when most people want latency gone... I mean, I get it, but seems like something a little more niche.
[17:16] <OvenWerks>  30 could be satified by a text box with ~/.log/jack/jackdbus.log
[17:16] <Eickmeyer[m]> Yeah, I suppose. (RE: 30)
[17:17] <OvenWerks> basically tail -f |<pipe this to our window>
[17:18] <OvenWerks> I am pretty sure that is what qjackctl does
[17:19] <OvenWerks> it logs it's own stuff as well but I don't know if I would do that.
[17:19] <OvenWerks> There is a big difference in the way qjackctl works from controls
[17:20] <OvenWerks> qjackctl is designed to stay open as long as jack is running and so keeps a count of xruns from last start or last xrun-reset
[17:21] <OvenWerks> controls only keeps count from controls startup. Start controls twice and xrun count starts at zero both times
[17:22] <OvenWerks> to do anything else, autojack would have to do the counting and pass the info to controls if it is running
[17:27]  * OvenWerks notices jackdbus.log starts at: Wed Jun 15 23:17:21 2016
[17:28] <OvenWerks> mayb instead setup some kind of log rolling...
[17:32] <OvenWerks> hm speaking of jackdbus.log, I am getting: Wed Dec  9 09:31:45 2020: Jack: JackSocketServerChannel::Execute : fPollTable i = 3 fd = 17
[17:32] <OvenWerks> X4 every 10 seconds
[17:52] <Eickmeyer[m]> Something. The thing is, controls is only meant to start Jack and be done. We're experiencing a bit of feature creep here.
[19:04] <Eickmeyer[m]> OvenWerks: Weird thing just happened: Jack started spontaneously.
[19:05] <Eickmeyer[m]> Acted as if Autojack started it.
[19:45] <OvenWerks> Assuming logging is set to extra... the contents of ~/.log/autojack.log might be interesting
[20:55] <OvenWerks> Eickmeyer[m]: also it could be pulse auto starting
[20:55] <Eickmeyer[m]> OvenWerks: Well, I wasn't using Jack at the time, and all the sudden my pulse switched-over to a jack sink.
[20:55] <OvenWerks> k'
[20:56] <OvenWerks> that is better info then