[00:36] <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:37] <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:38] <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:39] <OvenWerks> I would say lv2 only except I think there are some applications that only use vst
[00:39] <OvenWerks>  (LMMS?)
[00:40] <Eickmeyer> LMMS because they obviously hate LV2.
[00:41] <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:43] <Eickmeyer> Looks like at least 8.
[00:46] <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:47] <Eickmeyer> And nothing since.
[00:47] <OvenWerks> Yeah, aside from jack clients not building LV1 would not hurt either
[00:48] <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:49] <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:52] <Eickmeyer> I'll start picking-apart the seed tonight and figure out what needs to go/stay wrt plugins.
[00:54] <OvenWerks> The main thing that is lv1 only are some of the specialized ambisonics ones I think
[00:55] <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.
[01:01] <Eickmeyer> dssi.... ew.
[01:02] <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:03] <OvenWerks> but xsynth and ysynth are problematic enough that they are only included because some other package we need includes them.
[01:19] <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:20] <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:21] <Eickmeyer> In terms of the email I sent?
[01:21] <Eickmeyer> I admit the audio stuff needs further discussion/exploration.
[01:22] <OvenWerks> yeah,
[01:23] <OvenWerks> midisnoop does not show up in the menu. and should
[01:24] <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:25] <Eickmeyer> It *should* have one, per the source.
[01:26] <Eickmeyer> Yet I see nothing in /usr/share/applications
[01:26] <OvenWerks> that was I found too
[01:27] <Eickmeyer> There's even a ptach to fix the build.
[01:28] <Eickmeyer> It exists, it's just not getting built.
[01:28] <Eickmeyer> Perhaps it's getting built, just not installed.
[01:30] <Eickmeyer> Aha! They botched the rules file. The .desktop file exists, it's just not being put in the right directory.
[01:33] <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:35] <Eickmeyer> Now hopefully somebody rebuilds that.
[01:35] <Eickmeyer> Any builds at this point should auto-sync.
[01:40] <Eickmeyer> OvenWerks: I'm moving envy24control to mixers, removing from video.
[01:48] <Eickmeyer> OvenWerks: drumkv1: Right now, we provide the standalone app. Should we switch it to the lv2 plugin or include both?
[01:57] <Eickmeyer> Meh, switching it to the lv2.
[02:03] <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:04] <OvenWerks> for all the V1 plugins
[02:06] <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:08] <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:09] <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:11] <Eickmeyer> Ok, that should nuke it from orbit.
[02:16] <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:17] <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:58] <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.
[03:38] <teward> Eickmeyer: FTBFS
[03:39] <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:40] <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:41] <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:42] <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:43] <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:58] <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:59] <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
[04:00] <Eickmeyer> teward: I didn't think it was your environment, but would've laughed if it was.
[15:06]  * StevenJayCohen sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/PeuaCxGXxoVbFOFTnLOxWMUW >
[15:08] <StevenJayCohen> Again, I told them their answer to #1 and gave them the link to 15.04 being way beyond EOL
[15:12] <StevenJayCohen> If there is a guide for how they could update their own Multiverse entry, that might be all they need.
[15:22] <OvenWerks> Wow. 5 years behind? you can do that with windows? and mac?
[15:23] <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:25] <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:26] <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:27] <StevenJayCohen> true, is there a guide that I can send them about maintaining a Multiverse listing?
[15:28] <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:29] <OvenWerks> the same tools chain can be set up on their own machine (I notice from the conversation last night)
[15:31] <OvenWerks> StevenJayCohen: the biggest problem we have with packages, is a change in lib/toolchain versions... often right at freeze time :P
[15:32] <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:36] <StevenJayCohen> A PPA seems to be what they really wanted. It just didn't occur to me.
[15:37] <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:38] <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:39] <OvenWerks> A static build against X and alsa/jack I would guess
[15:40] <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:41] <StevenJayCohen> libSwell with gtk widgets
[15:41] <StevenJayCohen> same thing they use for macOS
[15:41] <StevenJayCohen> (the libSwell part)
[15:43] <OvenWerks> I think /opt was the original flatpack/snap
[15:44] <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:45] <OvenWerks> and lots of things have plugins of one sort or another
[15:45] <OvenWerks> not just audio
[15:46] <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:47] <OvenWerks> snap is too far removed from the real system
[15:47] <StevenJayCohen> right
[15:48] <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:49] <OvenWerks> the main reason snap and flatpack have apeal, is the ease of use from a dev standpoint
[15:50] <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
[16:37] <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:41] <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:42] <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:44] <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:45] <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.
[17:41] <OvenWerks> Eickmeyer: I could not find the source for that project.
[18:10] <Eickmeyer> OvenWerks: Neither could I, hence it's closed-source, so they'd have to use a PPA or open source it.
[18:11] <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:25] <OvenWerks> Eickmeyer: so audacity or mhwaveedit...
[18:26] <Eickmeyer> Audacity is the more well-known tool. I'd go with that.
[18:27] <OvenWerks> audacity comes with it's own set of effects some of which are quite good. mhwaveedit deals better with jack.
[18:28] <Eickmeyer> Right, but audacity is cross-platform and more well-known to people coming from Windows and Mac.
[18:29] <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:32] <OvenWerks> mhwaveedit has not seen much if any development (at least that is visible). So no I would not include it.
[18:36] <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:38]  * Eickmeyer is tempted to drop qjackctl from the seed
[18:39] <Eickmeyer> OvenWerks: You might want to comment back on Ross's reply.
[18:40] <Eickmeyer> Getting rid of the ladspa plugins for calf definitely stopped the loading problems, but Calf itself likes to crash Ardour, iirc.
[19:03] <OvenWerks> Eickmeyer: is my reply good enough? :P
[21:39] <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:40] <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:41] <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:49] <teward>  Cool
[21:50] <teward> At least they were fast to fix it
[21:53] <Eickmeyer> From their perspective it would've sucked to release something that won't build.
[21:56] <teward> True xD