[02:05] <OvenWerks> Eickmeyer: it appears that channel count for alsa does not work.
[02:06] <OvenWerks> Eickmeyer: when I set channels to 4 I get 2, when I set channels to 6, I still get 2
[02:06] <Eickmeyer> Oof.
[02:07] <Eickmeyer> I wonder if it's based on the hardware it's targeting?
[02:28] <OvenWerks> dummy works fine though I can get 6 i/o
[02:29] <OvenWerks> I am going to try putting the exact number 12/10 i/o and see what it does
[02:30] <OvenWerks> 12/10 works, 10/10 doesn't
[02:31] <Eickmeyer> OvenWerks: So are we talking increments of 2?
[02:32] <OvenWerks> I am pretty sure that 2/2 is not useful enough to worry about and that full or less than full do not make any difference to the cpu used
[02:32] <OvenWerks> I don't know let me try 5
[02:33] <OvenWerks> I tried 5/7 on dummy and that works fine
[02:33] <Eickmeyer> Huh. ¯\_(ツ)_/¯
[02:34] <OvenWerks> so I will have to figure out how to hide that row for anything but dummy
[02:34] <OvenWerks> (and net, netone when they get added)
[02:34] <OvenWerks> As you may have noticed, I have fixed the backends problem already.
[02:35] <Eickmeyer> Seems like it would be similar to graying-out a checkbox, at least in theory.
[02:36] <OvenWerks> There are only two places it matters, startup and switch master to USB. The second only works with alsa anyway... so only one place.
[02:36] <OvenWerks> yes it should be. I may need to put that row in a container and hide the container
[02:37]  * Eickmeyer nods
[02:37] <OvenWerks> I don't want to do that... because the stuff inside a container may not line up.
[02:38] <OvenWerks> that would mean three containers... one for the label and one each for in and out
[02:38] <Eickmeyer> Yeah, less than idea. There has to be a way though.
[02:38] <OvenWerks> Anyway, first I will remove channel count from alsa and firewire so at least it works
[02:40] <Eickmeyer> 👍
[03:01] <OvenWerks> Hide() and show() do not work. There is no error but it does do anything
[03:39] <OvenWerks> I guess set_sensitive(False) will have to do.
[04:00] <OvenWerks> Eickmeyer: -controls has been built
[04:00] <Eickmeyer> OvenWerks: I'll take a look.
[04:05] <Eickmeyer> OvenWerks: Starting with the dummy backend setting channels to 32 resulted in 2 channels in/out.
[04:08] <OvenWerks> hmm, I got 32 here
[04:09] <OvenWerks> Um oh, logout and in... I should have bumped the Vnumber
[04:09] <Eickmeyer> Oh, k
[04:11] <Eickmeyer> There we go. That was the expected result.
[04:11] <OvenWerks> not ready for release
[04:12] <Eickmeyer> Yeah, I can see one issue. I had one i/o pair for Pulse and got two.
[04:12] <OvenWerks> I am going to add the inputs only for the USB bridge at least.
[04:14] <OvenWerks> I don't have that here... I did in the past (spelling error) but it should be fixed. Does changing the number of pule bridges up and config then back to one and config fix it?
[04:15] <Eickmeyer> I switched it to 0 and got 0. Changed it to 1 and got 2.
[04:15] <OvenWerks> did that here with no problem.
[04:16] <Eickmeyer> Changed it to 2 and got 4. :S
[04:16] <OvenWerks> restart jack and try again I think
[04:16] <OvenWerks> wow
[04:16] <Eickmeyer> I might try rebooting.
[04:17] <OvenWerks> That sounds like two autojacks running... shouldn't do that
[04:20] <Eickmeyer> Rebooting did the trick.
[04:22] <OvenWerks> when it is ready for release it will kill the old autojack.
[04:22] <Eickmeyer> Cool.
[15:04] <teward> Eickmeyer: I can't even tell what dpf-plugins is supposed to be bundling.  ERR: Insufficient Information
[15:04] <teward> i can ask sil to take a look but...
[15:04] <teward> chances are, same problem
[15:16] <OvenWerks> teward: which information is missing? I would think it generates a set of plugins in both lv2 and lxvst formate and probably as a jack client as well
[15:16] <teward> OvenWerks: just a description of what it does :P
[15:16] <teward> To be fair
[15:17] <teward> seth couldn't understand waht the package was supposed to do either :)
[15:17] <teward> and when that's the case I start headscratching
[15:17] <OvenWerks> In debian/control?
[15:17] <teward> oh btw I asked sil2100 to take a look at ubuntustudio-menu-add in NEW
[15:17] <teward> OvenWerks: just in general, needed more details about what it did before I poked it :p
[15:17] <teward> and sil indicated they'd take a look if they get any spare cycles
[15:28] <OvenWerks> Eickmeyer: with the distro plugins, do we really want to build the LV1 set? Is there any software that actually requires it? I think lmms can use the lxvst or is that wrong?
[15:38] <Eickmeyer> OvenWerks: I'm just building everything it includes.
[15:38] <Eickmeyer> teward: In order to run what dpf-plugins generates, it requires an audio plugin host, such as Carla, or a DAW such as Ardour.
[15:39] <Eickmeyer> Anybody that knows what an audio plugin does knows what it requires. Same as calf-plugins and lsp-plugins.
[15:39] <OvenWerks> or even jack
[15:39] <Eickmeyer> That too.
[15:51] <Eickmeyer> teward: Description in bug 1829562 updated.
[15:52] <Eickmeyer> sarnold: ^
[16:02] <teward> Eickmeyer: ack.  but we were wondering what the package was *doing* :P
[16:02] <teward> so :P
[16:03] <OvenWerks> doing?
[16:03] <Eickmeyer> doing?
[16:03] <teward> i'm currently working with Laney on debugging Chromium issues which're causing Selenium crash failures on kopano-webapp which is blocking NGINX
[16:03] <teward> as in what it was supposed to be packaging ;)
[16:03] <teward> is it creating the plugins or just including them
[16:03] <teward> FYI I'm dead tired today :p
[16:03] <teward> 10 coffees doesn't help
[16:04] <Eickmeyer> It compiles the plugins, and then puts them where they belong (/usr/lib/lv2, /usr/lib/vst, etc...)
[16:04] <Eickmeyer> teward needs a vacation.
[16:04] <teward> ack
[16:04] <OvenWerks> it packages audio plugins used to modifi or produce sound used digital audio workstaions and effect racks for live audio work
[16:43] <teward> Eickmeyer: OvenWerks: there be a good news for ubuntustudio-menu-add
[16:43] <teward> you can thank sil2100
[16:43] <Eickmeyer> teward: Saw that. 
[16:43] <Eickmeyer> I'll be adding it to our seed soon.
[16:44] <teward> Eickmeyer: sil2100 also said they'd ack the binaries once they show up so you should be good then once that's bulit and accepted and lands :)
[16:44] <Eickmeyer> Sweet. :)
[16:54] <Eickmeyer> teward: Thanks for all your help.
[17:01] <teward> yep.
[17:01] <teward> all i did was sponsor it but :p
[17:01] <Eickmeyer> teward: That's more than a lot of people can say.
[17:01] <teward> :P
[17:01] <teward> well I sponsored it and kicked things around but :p
[17:02] <Eickmeyer> Well, my biggest frustration has been getting motus or core-devs to help us at all, so you have no idea how much value you have. :)
[17:06] <teward> well MOTUs and Core Devs are all busy xD
[17:06] <teward> but there's some things I still won't poke :P
[17:06] <teward> like DKMS related things
[17:06] <teward> or Kernel related things
[17:06] <teward> or anything that's chaos xD
[17:06] <Eickmeyer> teward: I don't blame you. I guess the problem then is that we need more MOTUs and Core Devs.
[17:07] <Eickmeyer> OvenWerks: Opinions? https://github.com/Houston4444/RaySession
[17:13] <teward> I think the problem is most MOTUs/CoreDev are busy with their own project interests and niches
[17:14] <teward> or are busy because Canonical.
[17:15] <OvenWerks> Eickmeyer: I would almost ask are session managers even a thing any more?
[17:15] <OvenWerks> but that is me being too close to the Ardour team
[17:15] <Eickmeyer> OvenWerks: Well, they seem to be a thing, and there's a thread on the calf-plugins github talking about needing to support NSM.
[17:15] <OvenWerks> I have not heard anything about this on LAU or LAD
[17:16] <OvenWerks> Where people ask what session manager to use
[17:16] <OvenWerks> Yeah NSM is the only thing people suggest any more and nsm or non-anything is hard to package
[17:17] <OvenWerks> so if this does the same job and is easier to package...
[17:17] <Eickmeyer> Well, tbh, Ardour is such a complete solution that it really eliminates the need for a session manager. Yet some people have them in their workflows.
[17:17] <Eickmeyer> I might give it a shot.
[17:18] <Eickmeyer> After all, ladish is dead for all intents and purposes.
[17:18] <OvenWerks> Yeah people still do the hydrogen thing because Ardour does not have a paternbased editer
[17:19] <OvenWerks> I haven't heard anyone using Ardour-Qtrackor in a long time. most people seem to have gone with one or the other
[17:20] <Eickmeyer> Looks like this thing is completely qt5, so no ntk stuff like nsm.
[17:20] <OvenWerks> no reason to use ntk
[17:20] <Eickmeyer> Yeah. No idea why the non stuff is so locked into their own toolkit.
[17:21] <OvenWerks> history
[17:21] <OvenWerks> they started with fltk
[17:21] <OvenWerks> fltk is not really suited to audio GUIs so NTK is an extension
[17:22] <OvenWerks> I actually like fltk
[17:22] <Eickmeyer> Looks like someone already packaged it in a PPA, so I guess I could rob that and clean it. https://launchpad.net/~houston44/+archive/ubuntu/raysession/+packages
[17:24] <OvenWerks> however, people have found that both NTK and FLTK do not work well for plugins even though they tend to be static compile
[17:24] <OvenWerks> good, lash is pretty much dead. I think falktx is removing it from his tools
[17:28] <teward> Eickmeyer: surprised you never asked Simon to sponsor :P
[17:28] <teward> they've got access xD
[17:28] <Eickmeyer> teward: He's too busy much of the time, even though I've done most of the up-front work.
[17:29] <Eickmeyer> teward: Though, now that he's out of school for the summer, that shouldn't be much of a problem.
 yep, that sounds like @tsimonq2 :P
 @Eickmeyer probably relevant... https://blog.ubuntu.com/2019/06/24/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
[17:34] <Eickmeyer> Holy influence, batman! (RE: first sentence)
[17:37] <Eickmeyer> Well, looks like my email had some effect.
[17:43] <OvenWerks> wine is probably the big one. Most linux stuff comes with source packages that can be compiled either way but some of the older windows binaries that have just worked for years will never get updated. (like hulls.exe)
[17:55] <Eickmeyer> RE: raysession: OMG this package is dirty. Ew. Cleanup shall ensue.
 @Eickmeyer more likely not your email but WINE and Steam had more impact
 I did also ask Mark to weigh in behind the scenes too but
 that's me just being chaotic :P
 Hehe
[21:04] <Eickmeyer> http://ubuntustudio.org/2019/06/regarding-ubuntus-statement-on-32-bit-i386-packages/