| OvenWerks | Eickmeyer: yeah even them. | 00:36 |
|---|---|---|
| OvenWerks | Carla would be the exception | 00:36 |
| Eickmeyer | Ok. That actually might cut-down on some stuff. | 00:36 |
| Eickmeyer | Yeah, Carla isn't really a plugin, even though it *has* plugins that allow it to be used as a plugin. | 00:37 |
| OvenWerks | My feeling is that no one uses 10 jack clients and serialises them unless they already use a rack | 00:37 |
| Eickmeyer | Right, and that's an excellent point. | 00:37 |
| Eickmeyer | No clue why a developer would create a standalone client for each plugin. | 00:38 |
| OvenWerks | The toolkit does it automatically | 00:38 |
| OvenWerks | So it is no work to add it, just a compile flag | 00:38 |
| OvenWerks | I would say lv2 only except I think there are some applications that only use vst | 00:39 |
| OvenWerks | (LMMS?) | 00:39 |
| Eickmeyer | LMMS because they obviously hate LV2. | 00:40 |
| OvenWerks | because the devs are afraid of it... though I do hear it is coming. Also so comercial products | 00:41 |
| OvenWerks | s/so/some/ | 00:41 |
| Eickmeyer | That's cool. | 00:41 |
| Eickmeyer | Though, being afraid of something that has been around for... how many years now? | 00:41 |
| Eickmeyer | Looks like at least 8. | 00:43 |
| Eickmeyer | OvenWerks: "LV2 support is coming" since 2014: https://github.com/LMMS/lmms/projects/10#card-19782392 | 00:46 |
| Eickmeyer | They only got some traction on it a year ago. | 00:46 |
| Eickmeyer | And nothing since. | 00:47 |
| OvenWerks | Yeah, aside from jack clients not building LV1 would not hurt either | 00:47 |
| OvenWerks | in cases where there is already lv2) | 00:48 |
| Eickmeyer | But then the LMMS people will get upset if there's no VST version. | 00:48 |
| OvenWerks | so far as I am concerned, any plugin that has lv2, lxvst variants should not have lv1 | 00:49 |
| OvenWerks | Tell them to put in bug reports upstream | 00:49 |
| Eickmeyer | Ok, agreed. | 00:49 |
| OvenWerks | (to LMMS) | 00:49 |
| Eickmeyer | I'll start picking-apart the seed tonight and figure out what needs to go/stay wrt plugins. | 00:52 |
| OvenWerks | The main thing that is lv1 only are some of the specialized ambisonics ones I think | 00:54 |
| OvenWerks | There is the small set of dssi plugins, some are already lv2 (fluidsynth) or they are suffering from bitrot. | 00:55 |
| OvenWerks | I guess so long as they still build they are fine. | 00:55 |
| Eickmeyer | dssi.... ew. | 01:01 |
| OvenWerks | in fact the only real use for dssi seems to be hexter? | 01:02 |
| Eickmeyer | Hexter is one of those that is ideally used as a standalone at this point. | 01:02 |
| Eickmeyer | Still requires dssi stuff. | 01:02 |
| OvenWerks | but xsynth and ysynth are problematic enough that they are only included because some other package we need includes them. | 01:03 |
| OvenWerks | Eickmeyer: we need a desktop file for envy24control which decides to show up in video? to make it not show up at all (Dontshow=true) | 01:19 |
| Eickmeyer | Or move it to the right place in -menu. | 01:20 |
| OvenWerks | I think you have hit the graphics/video stuff pretty good. | 01:20 |
| Eickmeyer | In terms of the email I sent? | 01:21 |
| Eickmeyer | I admit the audio stuff needs further discussion/exploration. | 01:21 |
| OvenWerks | yeah, | 01:22 |
| OvenWerks | midisnoop does not show up in the menu. and should | 01:23 |
| OvenWerks | I guess a bug report up stream... or is it proper to add one as a patch to the package? | 01:24 |
| OvenWerks | we could add one to our menu package | 01:24 |
| Eickmeyer | Let me investigate a minute. | 01:24 |
| Eickmeyer | It *should* have one, per the source. | 01:25 |
| Eickmeyer | Yet I see nothing in /usr/share/applications | 01:26 |
| OvenWerks | that was I found too | 01:26 |
| Eickmeyer | There's even a ptach to fix the build. | 01:27 |
| Eickmeyer | It exists, it's just not getting built. | 01:28 |
| Eickmeyer | Perhaps it's getting built, just not installed. | 01:28 |
| Eickmeyer | Aha! They botched the rules file. The .desktop file exists, it's just not being put in the right directory. | 01:30 |
| Eickmeyer | I'm *technically* part of the Debian Multimedia Team, so I get to edit stuff. :) | 01:33 |
| Eickmeyer | This should do the trick: https://salsa.debian.org/multimedia-team/midisnoop/-/blob/master/debian/rules | 01:33 |
| Eickmeyer | Now hopefully somebody rebuilds that. | 01:35 |
| Eickmeyer | Any builds at this point should auto-sync. | 01:35 |
| Eickmeyer | OvenWerks: I'm moving envy24control to mixers, removing from video. | 01:40 |
| Eickmeyer | OvenWerks: drumkv1: Right now, we provide the standalone app. Should we switch it to the lv2 plugin or include both? | 01:48 |
| Eickmeyer | Meh, switching it to the lv2. | 01:57 |
| OvenWerks | Eickmeyer: envy24controls should not show anywhere because mudita24 should be used instead. Mudita24 is a fixed version. | 02:03 |
| OvenWerks | lv2 is fine | 02:03 |
| OvenWerks | for all the V1 plugins | 02:04 |
| Eickmeyer | Looks like envy24controls comes in with alsa-tools? | 02:06 |
| OvenWerks | yes | 02:06 |
| OvenWerks | otherwise we would not include it | 02:06 |
| Eickmeyer | Ok, yep, let's at least kill it from the menu. | 02:06 |
| Eickmeyer | I'm not a huge fan of killing .desktop files with another desktop file, I think nuking it from applications-merged is the way to go. Overriding a .desktop file with another is a hack at best. | 02:08 |
| Eickmeyer | I'll note we don't have anything that does that anymore. | 02:08 |
| Eickmeyer | Actually, I take that back. It's in -default-settings. | 02:09 |
| Eickmeyer | (odd place for it) | 02:09 |
| OvenWerks | historical reasons | 02:09 |
| OvenWerks | (hysterical) | 02:09 |
| Eickmeyer | Hehe | 02:09 |
| Eickmeyer | Easy enough to move. | 02:09 |
| Eickmeyer | Ok, that should nuke it from orbit. | 02:11 |
| OvenWerks | zynaddsubfx-oss.desktop is another that should go | 02:16 |
| Eickmeyer | We already have a .desktop file that nukes it, but again it's in -default-settings which you wouldn't have installed. | 02:16 |
| OvenWerks | Ah | 02:17 |
| * OvenWerks did remeber talking about that before | 02:17 | |
| Eickmeyer | I remember talking about it before, and we did that, but we haven't been consistent about where we placed menu-modifying items. | 02:17 |
| Eickmeyer | OvenWerks: Ok, in order to do that move I had to also backport a version of -default-settings I had branched. Also backported the fixes in -menu. | 02:58 |
| Eickmeyer | Updated seed, updated metas. | 02:58 |
| teward | Eickmeyer: FTBFS | 03:38 |
| Eickmeyer | teward: The metas? | 03:39 |
| teward | lsp-plugins FTBFS in Groovy sbuild | 03:39 |
| Eickmeyer | That's incredibly odd. | 03:39 |
| teward | my build farm locally was eating resources because I had 12 NGINX builds ahead of it | 03:39 |
| teward | let me grab logs | 03:39 |
| Eickmeyer | For reference, the versions in ubuntustudio-ppa/backports were locally built. | 03:39 |
| teward | http://paste.ubuntu.com/p/63zHPzWS6n/ | 03:39 |
| teward | > for reference | 03:40 |
| teward | you're talking backports | 03:40 |
| teward | did you actually test Groovy lol | 03:40 |
| teward | see the build logs | 03:40 |
| Eickmeyer | Sorry, launchpad built, not from recipe. | 03:40 |
| teward | it hard-failed | 03:40 |
| teward | well in this case it hardfailed | 03:40 |
| teward | so IDK what you have in yours that failed a plain sbuild | 03:41 |
| teward | 'cause i just created this groovy environment :P | 03:41 |
| teward | i rebuild it every 5 builds | 03:41 |
| teward | hence why it took my system a while | 03:41 |
| teward | i can re-run it but if it fails again | 03:41 |
| Eickmeyer | Yep, backport has direct upload versions. Not built against groovy, so my bad. | 03:42 |
| teward | i rest my case | 03:42 |
| teward | your updated version has to go against Groovy | 03:42 |
| teward | since we're focal-closed | 03:42 |
| teward | so it fails in Grooby | 03:42 |
| teward | Groovy* | 03:42 |
| Eickmeyer | Right. Didn't think it would be that far removed. | 03:42 |
| teward | with the log i pastebinned | 03:42 |
| teward | well it looks like g++ errors | 03:42 |
| teward | so perhaps toolchain differences? | 03:43 |
| teward | or some dep along the way went wonky? | 03:43 |
| teward | (that's your investigation :P) | 03:43 |
| teward | until it clean builds here, NACK on upload | 03:43 |
| Eickmeyer | ^ You didn't have to tell me that. :P | 03:43 |
| Eickmeyer | teward: Reported upstream, they're quite responsive: https://github.com/sadko4u/lsp-plugins/issues/104 | 03:58 |
| Eickmeyer | We'll see what happens next. I suspect a hotfix soon. | 03:58 |
| teward | ppa failure too heh | 03:59 |
| teward | so NOT my env | 03:59 |
| Eickmeyer | Right, I just tested in my own PPA as well. | 03:59 |
| Eickmeyer | Had to in order to at least get a log that was better than a pastebin. :P | 03:59 |
| Eickmeyer | teward: I didn't think it was your environment, but would've laughed if it was. | 04:00 |
| * StevenJayCohen sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/PeuaCxGXxoVbFOFTnLOxWMUW > | 15:06 | |
| StevenJayCohen | Again, I told them their answer to #1 and gave them the link to 15.04 being way beyond EOL | 15:08 |
| StevenJayCohen | If there is a guide for how they could update their own Multiverse entry, that might be all they need. | 15:12 |
| OvenWerks | Wow. 5 years behind? you can do that with windows? and mac? | 15:22 |
| OvenWerks | I know something that old will not run on a new mac | 15:23 |
| OvenWerks | (Ardour and at least one other DAW have that problem) | 15:23 |
| StevenJayCohen | Reaper will run on Win98 | 15:25 |
| OvenWerks | Ardour will run on win xp | 15:25 |
| OvenWerks | I don't know about 98 | 15:25 |
| StevenJayCohen | So, ignoring that bit, how do they update Multiverse so it stays in sync with the releases on their website? | 15:25 |
| OvenWerks | but that is the wrong thinking, it is not so hard making it run on old stuff it is keeping up with macos digs every new release | 15:26 |
| StevenJayCohen | true, is there a guide that I can send them about maintaining a Multiverse listing? | 15:27 |
| OvenWerks | I am not the right person to ask. probably the first thing is to have a launchpad account and keep a PPA up. That will have the system on launchpad build against the right lib and tools sets. | 15:28 |
| OvenWerks | the same tools chain can be set up on their own machine (I notice from the conversation last night) | 15:29 |
| OvenWerks | StevenJayCohen: the biggest problem we have with packages, is a change in lib/toolchain versions... often right at freeze time :P | 15:31 |
| StevenJayCohen | Got it, I found a good PPA explanation that I am going to send to them: https://itsfoss.com/ppa-guide/ | 15:32 |
| OvenWerks | we have lost some valuable applications in this way: GCDMaster, idjc, midimonitor, gnome2 (for that matter) | 15:32 |
| StevenJayCohen | A PPA seems to be what they really wanted. It just didn't occur to me. | 15:36 |
| OvenWerks | I don't see any reference to a git repo for it, so closed source but free bin. That may be difficult to do. I don't know if launchpad allows git repos that are private | 15:37 |
| StevenJayCohen | We'll see. Maybe they'll eventually do flatpak | 15:38 |
| OvenWerks | or static build | 15:38 |
| StevenJayCohen | Reaper does a static build | 15:38 |
| OvenWerks | A static build against X and alsa/jack I would guess | 15:39 |
| OvenWerks | Or like Ardour does things in /opt/package/own lib/bin tree | 15:40 |
| StevenJayCohen | in /opt | 15:40 |
| StevenJayCohen | I was checking how they do their GUI | 15:40 |
| StevenJayCohen | libSwell with gtk widgets | 15:41 |
| StevenJayCohen | same thing they use for macOS | 15:41 |
| StevenJayCohen | (the libSwell part) | 15:41 |
| OvenWerks | I think /opt was the original flatpack/snap | 15:43 |
| OvenWerks | I think the newer snap does not add anything useful, flatpack I don't know well enough | 15:44 |
| OvenWerks | snap removes the app from the system which is ok for some things... not anything with plugins though. | 15:44 |
| OvenWerks | and lots of things have plugins of one sort or another | 15:45 |
| OvenWerks | not just audio | 15:45 |
| StevenJayCohen | I was shocked to find out that flatpak had better audio support than snap. I haven't had a chance to test that yet | 15:46 |
| OvenWerks | snap is too far removed from the real system | 15:47 |
| StevenJayCohen | right | 15:47 |
| OvenWerks | one can not have an application in a snap that interacts with jack on the system | 15:48 |
| OvenWerks | cause the snap app can't even see jack | 15:48 |
| StevenJayCohen | seems like a good solution for a server app | 15:48 |
| StevenJayCohen | not an end user app | 15:48 |
| OvenWerks | snap has its place, but it is being pushed for uses outside it's place | 15:48 |
| OvenWerks | the main reason snap and flatpack have apeal, is the ease of use from a dev standpoint | 15:49 |
| OvenWerks | but when you add interface with the system, the dev has to know that part anyway and then these tools are no easier than just using /opt | 15:50 |
| Eickmeyer | Just read the backscroll. A EOL release 5+ years old? That's a security nightmare. If they don't upgrade, they could become part of a botnet for all we know. | 16:37 |
| Eickmeyer | StevenJayCohen: The other thing they seem to be worried about is packaging, when that isn't their job. | 16:41 |
| Eickmeyer | Their job would simply to provide the source code and any compilation instructions. We take it from there. | 16:41 |
| StevenJayCohen | Agreed, no idea why they were supporting it | 16:41 |
| StevenJayCohen | That's why I think they'd be happier with a PPA. It would be more in their control, which is what it sounds like they want | 16:42 |
| Eickmeyer | That's true. | 16:42 |
| StevenJayCohen | I've interviewed them before. Students at the university do various jobs. So, if its a PPA, then some students on their end could maintain it (possibly for credit) | 16:44 |
| Eickmeyer | Bear in mind though, even they're part of Launchpad, we can't support PPAs. So, when things go wrong because someone installed from a PPA, they're pretty much out of luck and need to contact the PPA owner. | 16:44 |
| StevenJayCohen | No expectation of us supporting enything, just making it easier than them sticking a deb file on the download page that needs gdebi to properly isntall | 16:45 |
| Eickmeyer | That's an excellent point. | 16:45 |
| OvenWerks | Eickmeyer: I could not find the source for that project. | 17:41 |
| Eickmeyer | OvenWerks: Neither could I, hence it's closed-source, so they'd have to use a PPA or open source it. | 18:10 |
| Eickmeyer | teward: The issue with lsp-plugins is fixed, but it's going to be a bit. I'd like to see them do a new release first. | 18:11 |
| OvenWerks | Eickmeyer: so audacity or mhwaveedit... | 18:25 |
| Eickmeyer | Audacity is the more well-known tool. I'd go with that. | 18:26 |
| OvenWerks | audacity comes with it's own set of effects some of which are quite good. mhwaveedit deals better with jack. | 18:27 |
| Eickmeyer | Right, but audacity is cross-platform and more well-known to people coming from Windows and Mac. | 18:28 |
| OvenWerks | the truth of the matter is that because this is a audio file editor and not realtime stuff anyway and so even using audacity with pulse is normally "just fine" | 18:29 |
| Eickmeyer | Exactly. It's not like you're dealing with more than two channels typically in that case. | 18:29 |
| OvenWerks | mhwaveedit has not seen much if any development (at least that is visible). So no I would not include it. | 18:32 |
| Eickmeyer | The only place where Audacity loses out is that it doesn't register itself as a Jack client, but for the most part it works. | 18:36 |
| * Eickmeyer is tempted to drop qjackctl from the seed | 18:38 | |
| Eickmeyer | OvenWerks: You might want to comment back on Ross's reply. | 18:39 |
| Eickmeyer | Getting rid of the ladspa plugins for calf definitely stopped the loading problems, but Calf itself likes to crash Ardour, iirc. | 18:40 |
| OvenWerks | Eickmeyer: is my reply good enough? :P | 19:03 |
| teward | Eickmeyer: so they hotfixed but you want to wait for their next release then | 21:39 |
| teward | Sorry i got busy :) | 21:39 |
| Eickmeyer | teward: Yeah, let's wait for next release, my guess is he doesn't want to wait long on this, he has a couple other fixes to get in. | 21:39 |
| teward | Makes sense | 21:40 |
| teward | Ping me when thats ready and we can run the builds again to make sure it works | 21:40 |
| Eickmeyer | Ok. | 21:40 |
| Eickmeyer | What I did in my PPA most recently (eeickmeyer/ppa2) is the build with the bugfix, and it succeeded. Just FYI. | 21:41 |
| Eickmeyer | Basically, the LV2 headers changed. | 21:41 |
| Eickmeyer | Not a g++ issue. | 21:41 |
| teward | Cool | 21:49 |
| teward | At least they were fast to fix it | 21:50 |
| Eickmeyer | From their perspective it would've sucked to release something that won't build. | 21:53 |
| teward | True xD | 21:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!