[01:06] !tea, [01:06] team [01:06] !team [01:06] Coffee [01:06] hehe [01:07] I was trying something but now that I have your attention... [01:08] New version of xfce4-settings heading toward the archives per bluesabre, builds with libcolord, so this is the version with colord itegration, therefore color correction is finally built-in to the desktop. [01:08] \o/ [01:09] Is it better than DisplayCAL? or does it do something differenet? [01:09] Do they have something for the drawing tablet too? [01:09] No, this is just for display. [01:10] Also, unlike DisplayCAL, it doesn't actually create icc profiles without a colorimeter. [01:11] bluesabre might have more information if he's around. [01:11] Eickmeyer: I wouldn't know what to ask, that would be best left to someone like eylul [01:11] Also, rather, it doesn't create icc color profiles period. We should keep DisplayCAL for colorimeter support. [01:12] OvenWerks: I'm pretty well-versed in this stuff since it's used in photography. [01:12] Good [01:12] Yes, it doesn't create icc profiles, but it does allow you to apply them to your displays/printers/scanners [01:12] Using colord/xiccd [01:13] bluesabre: that sounds like good steps forward. [01:14] I like that xfce config runs all the time and makes sure the system boots the same as it was set when it was shut down. [15:40] Eickmeyer: with regard to cheap USB input junk like I was talking about yesterday (the guitar in only job that has unused outputs inside) I am wondering if a stopgap solution might be to add another check box. [15:41] right now we have Bridge USB Devcies to Jack When Plugged In [15:42] I am wondering If I should add another that does the same thing but inputs only [15:43] Eickmeyer: my thought process is this: The purpose of adding bridging (or the thing that got us started) was USB mics where the user wanted to use internal outputs [15:47] OvenWerks: So, are we talking a sub-checkbox that says "Bridge inputs only"? [15:47] yeah like to the right of the one there [15:47] I'd also make it grayed-out unless its parent checkbox is checked. [15:48] good idea [15:50] I am thinking in the long run of deviding Audio setup into subtabs where one tab could be for device specific settings [15:51] it would be nice to tab jack master setting depending on backend or I need to figure out how to hide unused settings rather than disable them [15:53] But I would like to keep them saved in the config file so that when someone switched from dummy to alsa, the last used alsa setting would show. [15:55] Same even on a perdevice basis, so that device A with 2 i/o routes pulse out to 1/2 and Device B with 12/10 i/o route pulse to outputs 9/10 (spdif) [15:56] I would like to remember USB or FW devices that are no longer plugged in and their settings as well. [15:57] (we sort of do this for a USB device that is used as master) [16:05] That all sounds great. [16:05] Eickmeyer: this wool gathering has been good :) Device based would be best. A device could tell which back end it expected. So rather than selecting the dummy back end you would select the dummy device and it's settings would follow. [16:05] Yes! That's great! [16:06] This would aply to Net and Netone as well. [16:07] Yep. [16:09] Eickmeyer: I want to add a fourth column in each tab with just a ? button or add a tool tip to each label and button. The help setup is outdated and only applies to the System tweaks tab anyway [16:10] Good idea. [16:11] That would break the help into smaller chunks. Having the main help button only apply to the current tab would be great too. [16:13] my work on -controls is not really for 19.10... though that would be ok by me rpovided we stop at a logical place and it doesn't seem half done [16:15] Right. Let me know whenever you feel it's ready for release. [16:15] So I will finish the chanel count, add the input only and see if head phone switching can be quick (I think I can do the alsa level change easily) [16:17] with the head phones, I think I will put a Hook in that looks for .config/autojack/headphone.sh [16:18] so that if what I do doesn't work, the user can add their own script. [16:19] Some laptops change the jack (not jakcd) pin use on phone plugin rather than change levels. [16:19] * OvenWerks is off... [16:20] channel count is done in -controls it just needs the autojack half so it actually does something :) [16:49] Eickmeyer: another place people could help with controls (or any other US sw) is to point out places "help" could be added and suggest text for that help. [17:07] OK, good idea. [18:14] OvenWerks: FYI, FeatureFreeze is August 22nd. [18:16] It would be good to do as much as possible before then and work on bugfixes mostly from then until 20.04. [20:02] OvenWerks: New plymouth theme on the way (we got some bad reviews, this one will likely be better received), and new grub2 theme to match (just got rid of the gray background, now black). [20:07] And I done goofed, so 4 fail mails. :P [20:40] Looks like it's all working. Might upload to eoan soon, idk... [20:45] Eickmeyer: I will work on those things for controls. I should ave something new before august [20:45] OvenWerks: Sweet. [20:46] I have already removed all calls with shell=True so that can be a security update :) [20:46] OvenWerks: Ok, so if that's the case, should I SRU this to disco?? [20:47] I am suspecting a lot fo calls to dbussend should be native python dbus messages... which would include jack_control calls too probably. [20:47] I don't think they are a valid worry, the user can not invluence the command line. [20:48] All parameters are generated by -controls [20:48] Ok. Wouldn't mind sarnold's opinion on this (he's on the security team). [20:48] But, generally, it's probably not a big rush then. [21:06] generally, my problem has been expecting shell commandline dealing with things like ~ and running a command without worrying about the directory the command is actually in. Most of the time just adding /usr/bin/ to the command was all I needed [21:49] Eickmeyer: the jackd man page is out of date/inacurate and missing much information [21:50] OvenWerks: upstream issue? [21:50] just type jack_control il [21:50] probably [21:50] Most likely. Manpages are done by the upstream developer, not the packagers. [21:51] The authors for the jackd man page do not look familiar [21:51] Manpage written by Stefan Schwandter, Jack O'Quin and Alexandre Prokou‐ [21:51] dine. [21:51] except the last one [21:52] who I am pretty sure is no longer involved falktx being the only dev there pretty much [21:52] Yeah. Should we poke him in #lad? [21:52] no [21:52] k [21:53] if anywhere in #jack [21:53] True. [21:53] but really not unless we have a new man page to offer [21:53] Yeah. He might be very well aware it's out of date. [21:54] the plan is to phase out jackd1 [21:54] Yeah. We're using jackd2, so why are we concerned? [21:54] by adding anything jackd1 has into jackd2 [21:55] the man page is being used for jackd2 [21:55] there is no man page for jackdbus or jack_control [21:56] pactl is pretty much as bad [21:56] Ah. [21:56] Doucumentation is hard. [21:56] but the default maxports is not 256 for a long time now (2048) [21:58] which may be considered limiting as ardour with alsa back end can have 1024 channels... 3 ports per channel plus master (4 more) [21:59] At least 1024 channels has been tested, more may be possible :) [22:17] Eickmeyer: it seems https://www.olivevideoeditor.org/ is recommended as being much faster than kdenlive [22:17] I don't think we can include it though as it is beta at best (web page says alpha) [22:18] This is true. In order to be in the archive, it has to be final or soon-to-be final (as Carla was at the time). [22:20] jackd (1 and 2) have been beta forever... and all qstuff beta [22:22] Looking at the jackd manpage, I think it was just lifted from jackd1. I know Paul had nothing to do with jackd2 So far as I know the original jackd2 had one dev [22:28] looks like jackd2 uses some jackd1 bits :) other thhan the man page [22:29] Right, but that's a sound server and not an application, so it's treated differently. [22:30] Eickmeyer: anyway, it looks like the jack backend stuff in -controls will not work for anything else than alsa. [22:30] So, no dummy or firewire? [22:30] * Eickmeyer might be confused [22:30] The commands are different for each backend (different creators) [22:31] Ah, yes, that makes sense. [22:31] Actually them may (by accident) work [22:31] That might be why qjackctl has a completely different selection for if you select a different backend. [22:32] I just stripped all the jack_control commands into a file. And will use that to rework it. [22:34] I think that will change the order I do things. I might work on that next rather than USB input only.... Then again, that should be quick and easy [22:34] Anyway, I will try to get that fixed before august. [22:36] Sounds good.