[01:47] Eickmeyer: working on phones un/plugged action. [01:47] wondering which options to play with [01:47] Did you ever find a common link between all hardware? [01:47] assume speakers may be hooked up to jackmaster [01:48] Eickmeyer: no but most these days are mute phone crank speaker/front [01:48] Sounds about right. [01:48] I will not try to deal with anything else [01:48] Happens at the alsa level, aiui. [01:50] how ever, an intrepid user can find space to A: add to /etc/acpi/studio.sh or B: add a script to .config/audojack/ with the right name. [01:50] *autojack [01:51] What if we had a default in /etc that could be overridden with something in .config? [01:51] * Eickmeyer is spitballing [01:52] if exist ~/.config/autojack/headphones {execute that script} else {do the default} [01:53] Exactly. Which is how most things configure anyhow. [01:53] the part in /etc/acpi/* has to be there to catch the plug signal. The script there now just sends a debus signal that autojack catches [01:54] Even one's default gtk theme is in /etc/gtk-3.0/settings.ini except when overridden by .config/gtk-3.0/settings.ini [01:54] (I probably have that signal wrong right now) [01:54] I'm not 100% sure there's a user-level equivalent for /etc/acpi. [01:55] nope, besides there are some things that would have to be done as root anyway so far as I know [01:58] True. [02:04] headphones may not be hooked up to jack master. So what to do whenthey are plugged in? Add bridge and move everything connected to system_1/2 to that bridge? [02:04] offer a choice? [02:05] what choices? [02:25] hmm.... [02:26] Usually this all gets handled at the alsa level for that particular device. Are we bridging to alsa or are we connecting directly to the device? [03:54] Eickmeyer: no it gets handled by pulse [03:54] Ah. [12:21] OvenWerks: Right, yeah I am not surprised. Flavors have always been a mixed bag of happiness and grief. [15:20] OvenWerks: bug 1877806 seems to be affected by all LV2 plugins. I just did a test myself and yes, attempting to save a preset for an LV2 does indeed crash Ardour. Not just calf. [15:20] bug 1877806 in ardour (Ubuntu) "ardour crashes when saving lv2 plugin preset" [Medium,Confirmed] https://launchpad.net/bugs/1877806 [15:21] Do you think anybody is interested in fixing this? I'm inclined to say no, since 6.0 is on the verge of release. [15:58] Eickmeyer: 5.12 will not recieve bug fixes nor will there be a 5.13 [15:59] Eickmeyer: is this a new for 20.04 problem? [16:05] so 6.0 would be considered the fix. [16:06] Eickmeyer: which plugin should I try? [16:07] the two so far I have tried do not seem to have a save preset button. [16:07] * OvenWerks doesn't use this facility... [16:10] LSP compression mono: add preset, ok. add a second preset, OK, switch from preset to preset, OK... [16:14] tried two more (dragonfly and eq4q) saving presets seems to work. [16:14] All tests have been with ubuntu repo ardour 5 [16:16] Eickmeyer: can you give specific plugins for me to test? [16:18] Calf eq 8 also works [16:26] OvenWerks: I tried LSP compression mono. [16:28] This is the same bug we thought was related to calf but is not. [16:28] So, what I did was open a new project, add a track, add LSP compression mono to it, go up to preset, click "Add" name it, made changes, clicked "Save" and Ardour crashed. [16:28] So what is different from my system to your's [16:30] I'm not sure. But I just tried it again and it crashed. [16:30] Same steps as above. [16:32] Merely clicking on "Save" in an LV2 plugin after creating a preset crashes it every time. [16:36] So what does save do? (save does crash things) [16:36] It's supposed to save any changes you make to the selected preset. This is in the plugin window, not the main window. [16:37] It just crashed when creating a preset on VST plugins. [16:37] but if I just add presets... they stay there on next session start [16:37] with no save [16:37] Yes, but try clicking save. [16:38] I understand that, but it apears that save has nothing to do with presets. [16:38] Adding presets already saves them. [16:39] If you hover over it, the tooltip says "save the current preset". [16:39] So, say you want to make changes to the preset. You can't. [16:44] even starting a new session and adding the same plugin shows those presets that were made on another session [16:44] But that's not the point. [16:44] I understand it is not the point. [16:44] I'm saying it's a confirmed bug. I am guessing that it's not a bug that the Ardour team can or wants to fix. [16:44] I am wanting to know what added functionality that button does. I can add the same preset a second time and it saves the changes. [16:44] (asks if it should overwrite [16:44] That would be a workaround. The Save button is supposed to do that without asking to overwrite. [16:44] Except I just did your workaround and it crashed. [16:44] So now my next test will be if this is also true in 18.04 [16:44] once the save button has been clicked, the add button will crash also on the same session [16:46] I will try ardour from ardour.org, ardour from ubuntu on 18.04 (which is different because you had to fiddle with it to make it work on 20.04... this may be part of the same lib problem) [16:47] this may be a package problem rather than an ardour bug [16:49] Right, and that's what we need to figure out. What build dep is missing? [16:49] It's not giving me any crash logs to find out what's going on. [17:02] I am pretty sure I have done a rebuild since then... maybe not full will try. [17:06] out cppunit seems to be quite old. [17:06] when doing config, I get: Checking for 'cppunit' >= 1.12.0 : not found [17:10] installer shows version 1.4.0 [17:10] Confirmed on that. [17:10] Launchpad is acting funny this morning. [17:10] Strange, should be 1.15. [17:10] https://launchpad.net/ubuntu/+source/cppunit [17:10] Is cppunit a build dep? I'm not seeing it as a build dep. [17:11] (for Ardour) [17:11] waf configure looks for it... but I am building 6.0 [17:12] so it may not be a build dep for 5.12 [17:12] Oh ok. That does make sense. The question is why you have cppunit 1.4 when 1.15 is in the archives. [17:12] 6.0 does build with out that lib [17:13] muon does not show a later version [17:14] just found it [17:18] Ah for unit testing so nothing to do with building the exec just building the unit tests [17:18] That is not my problem [17:19] Oh, good. [17:34] debug won't even run [17:34] Great. [17:34] And I suppose nobody else from the Ardour team will help us figure this out because ERR:NotOurBuild [18:13] OvenWerks: Same issue with my no-changes rebuild. I can't even narrow-down the library [18:18] OvenWerks: Here's the error it gives me when run from the terminal: IA__gdk_window_get_origin: assertion 'GDK_IS_WINDOW (window)' failed [18:21] OvenWerks: Maybe related? https://tracker.ardour.org/view.php?id=7543 [19:12] Eickmeyer: http://www.ovenwerks.net/paste/trace20200519.txt [19:13] when running debug I get that [19:13] looks like it is looking for something in libjack [19:13] Hmmm.... might have to rebuild against current jack [19:14] I literally just now got my upload rights, and with that I can upgrade Jack. [19:14] I'd have to do a local build, however. [19:16] Because I can only upgrade it in groovy, not focal, because that would require an SRU, but there's also new features. [19:18] OvenWerks: Even if I use direct alsa it still does that. Why is it calling libjack? [19:18] well from there I can continur and ardour does start up [19:21] Oh, that was during startup? [19:29] yes [19:30] the crash at save is: http://www.ovenwerks.net/paste/trace20200519-2.txt [19:32] Oh, the crash I'm having (and the bug is having) is inside a plugin window. [19:34] All signs are pointing to glib2.0 [19:37] https://github.com/lv2/lilv/issues/32 [19:37] this is what Robin thinks after looking at the trace [19:38] David seems to think he fixed it. [19:38] yes, but do we have the new version? [19:39] Version in Focal is 2.4.6, so no. [19:39] no [19:39] Vision in Groovy? Yes. [19:39] Therefore it's a matter of grabbing the one in Groovy and backporting it to focal. [19:40] in my case 20.04 [19:40] I'm also on 20.04 [19:40] I want to upgrade when we get calamares going. [19:42] Dangit, lilv isn't in the packageset. [19:49] hard dep though [19:49] Yep. [19:49] I'm going to see if we can get it added. [19:50] Also going to see if we can SRU this bad boy. [19:50] I guess we should boot 20.10 and cheack that the bug is gone... [19:50] I can do that later... but need to help my son with school [19:50] Rats, you're right. [19:50] I'll try it in a VM. [20:15] OvenWerks: Unable to even try it in a VM, so I did it on bare metal. Unable to reproduce there, so that tells me Robin is right. === Christoffer[m] is now known as christoffer[m] [21:01] teward: Made a request: https://lists.ubuntu.com/archives/devel-permissions/2020-May/001507.html [22:37] Maybe tsimonq2 can handle the request? ^ (I have some calamares stuff to ask as well) [23:06] Eickmeyer: good... well no not, not good but at least solved [23:06] what differences are there from our version to the next? Is ir just a bug fix or is there more? [23:07] I notice that those plugins use inline graphics too. Cool. I think they can safely replace calf. [23:15] OvenWerks: You mean lsp-plugins? [23:31] OvenWerks: As far as differences, it looks like it's definitely a bugfix release. If the SRU team disagrees, I guess I can cherry-pick the commit attached to the issue.