[15:35] autumna, OvenWerks: what is the name of the file to remove after the whisker menu is broken? [15:36] I put it in the bug report, one sec [15:36] (which reminds me I need to recheck and report back to the bug) [15:38] thanks autumna :) [15:38] https://bugs.launchpad.net/ubuntu/+source/menulibre/+bug/1362452 [15:38] Launchpad bug 1362452 in menulibre (Ubuntu) "Categories disappear after editing" [Undecided,Confirmed] [15:38] ~/.config/menus/xfce-applications.menu.bck [15:38] ~/.config/menus/applications-merged/user-ubuntustudio-audioproduction.menu [15:38] ~/.config/menus/gnome-applications-merged/user-ubuntustudio-audioproduction.menu [15:38] reverts the menu back to correct structure. [15:40] sakrecoer: see above [15:40] (realized I forgot to tag you) [15:41] ah ok, i thought it was this one: bug #1430571 [15:41] bug 1430571 in Ubuntu Studio "ubuntu studio menu items disappear after adding new launcher" [Undecided,Confirmed] https://launchpad.net/bugs/1430571 [15:44] sakrecoer: possibly same bug presenting itself in different ways in different versions of the menu? I am not certain. I filed that comment in latter a while ago. :) [15:46] :) [16:03] i think i will remove all the subteams from ubuntustudio-documentation except ubuntustudio-core and apply that as a group with wiki.ubuntu.com editing [16:04] permissions even during lockdown [16:04] :) yeah, there are 2missing '"' there :) [16:04] * sakrecoer copied the xubuntu rt ticket :p [16:30] .config/menus should be empty [16:32] sakrecoer: you may also like to check .local/share/applications/ for desktop files you did not put there... [16:35] sakrecoer, autumna: the menu config files are (supposed to be) read from system to system stubs to user, with the last one read overrides anything read before. [16:39] menulibre assumes the system file resides in /etc/xdg/menus/ This is the default... but the appliacations menu spec in there is broken (Bugged and told "won't fix"). It should not matter, because they should be reading what the menu does which is /etc/xdg/xdg-ubuntustudio/menus/ as the top directory. This is set by the session. [16:42] menulibre then makes mistake 2 (in my opinion) by replacing the whole system menu with it's own. They do this because... as stated above, the default menu spec is broken (two line fix BTW) and won't be fixed. [16:46] Because it replaces the system file completely, any subsequent changes to the system menu will not show up. As an example adding wine normally adds a menu stub and there are other packages that add menu stubbs as well. Alacarte, is also broken... but at least does things right in making changes. I would choose alacarte over menulibre... but would actually prefer not to ship either one. [16:50] For reference, there are three system menu config files that are correct: xubuntu (not xfce), ubuntustudio and KDE (kde has always been correct... probably because they were very involved in making the spec in the first place) The rest are broken... including the example in the xdg spec which would be ok if the menu contructor followed the rest of the spec... but does not make sense from a programming POV. [16:53] OvenWerks: You've been workin on controlling ardour using OSC, correct? Is it for personal use, or are you developing it? [16:54] The freedesktop menu construction spec says in effect that there is a default file which can be overridden by the session file, the stubs directory files /etc/xdg/menus/applications-merged/ overrides whatever has been read so far... and then the user's changes override everything that has allready been read. [16:54] zequence: developing. [16:54] it should be a part of Ardour 5 [16:54] I was just looking at ways to control ardour remotely, and came to the conclusion that a touch screen with OSC control may be the optimal solution [16:55] zequence: look at open stage control in particular. [16:55] open stage control runs as a web server and any tablet (or whatever) with chome works with it. [16:56] OvenWerks: Oh, nice. [16:56] Open stage control handles OSC correctly and fully. [16:56] That is it handles /path, /path f, path ff or whatever. [16:57] I was looking at making my own interface, if needed. Using javascript for sending the OSC messages [16:57] A lot of the android/iOS controllers only do /path param [16:57] Oh, ok [16:57] zequence: cool. [16:58] zequence: the last few days I have been taking the osc branch and merging it against the VCA2 branch which will also show up in A5 [16:58] What's VCA2? [16:59] zequence: the most up to date docs for OSC (in A5) are here: http://scott.cbbs.org/using-control-surfaces/controlling-ardour-with-osc/ [16:59] VCA2 adds master controllers that can control other strips. [17:00] like groups but can be nested. [17:00] They were called VCAs in analog mixers and are sometimes called DCAs in digital mixers [17:01] I was looking into the ardour manual, and there did seem to be quite a lot of support for OSC already [17:01] OvenWerks: Ok, so channels can be hidden inside the group controller graphically as well? [17:01] Like a folder? [17:01] That would be a nice addition. [17:02] not really. But channels could already be hidden anyway. [17:02] Yes, but then they can't be edited [17:02] True. [17:04] Paul is doing with consultation with a few people. The main reviewer does live show recording on a SSL console, so Ardour's VCA ends up following that and Harrison large format consoles. [17:05] VCAs don't control as much as groups can control, mostly level and mute (and solo when it gets fixed) [17:06] the VCA has a button (spill) that only shows the strips that VCA controls. [17:10] Well, not sure how handy that will tbh, since you can just use buses right now for that [17:11] Not sure what the logic is [17:14] I was looking at hardware controllers, a [17:14] ..and 1) too expensive 2) not enough features [17:19] we now have edit permission in through ~ubuntustudio-documentation [17:19] i added autumna krytarik OvenWerks and cfhowlett to it :) [17:20] permission in *wiki [17:21] That was quick! [17:22] yeah :) nice! [17:28] zequence: different workflows for different people. VCAs can do things like VCA1 controls channels 13579 and VCA2 controls 234678. Busses can't do that. [17:29] * OvenWerks is not sure of the practical use for that. [17:29] It is possible to set up mute groups though, which could be very useful in live situations. [17:43] OvenWerks: Sure buses can do that. You can route a channel to as many buses you want. [17:44] Multiple groups for single channels would do the same as VCA, but that doesn't work practically, of course [17:44] ..for many of the controls [17:45] Let me retract the first sentence there [17:46] The VCA would also control the output for all the different buses [17:48] Yeah, maybe that kind of thing gets interesting in situations where you have really complex channel setups, like big movie productions or something [19:33] thanks sakrecoer === \b is now known as Guest49310