[16:29] <OvenWerks> Eickmeyer: it seems that changing import dbus.glib to from dbus.mainloop.glib import DBusGMainLoop works fine in 18.04. Do we need to test it in anything older?
[16:30] <Eickmeyer> OvenWerks: No. 16.04 is EOL.
[16:34] <OvenWerks> I am assuming I need to do this to autojack as well...
[16:37] <Eickmeyer> If that's what the API requires, then yeah.
[16:37] <OvenWerks> Hmm, maybe not, it seems to be that way already
[16:40] <OvenWerks> I will leave it as is.
[16:46] <Eickmeyer> Sweet.
[16:48] <Eickmeyer> Woah. 4 Chroot problems in a row. That's unusual.
[16:48]  * Eickmeyer blames Launchpad
[16:49] <OvenWerks> it is more likely that I did a commit in the middle of the build because I didn't know it was running.
[16:50] <OvenWerks> But now it doesn't want to build :)
[16:50] <Eickmeyer> Doubtful, but I just manually requested a build.
[16:52] <Eickmeyer> Looks like it's going swimmingly now.
[16:53] <OvenWerks> if the build tries to copy the src into the chroot while it is being updated it would fail
[16:53] <Eickmeyer> Maybe that is what happened then. Just bad timing. ¯\_(ツ)_/¯
[16:54] <OvenWerks> Ya, I had forgotten to update the changelog...
[16:54] <OvenWerks> so two commits instead of one.
[17:12] <Eickmeyer> Meh, happens.
[17:25] <OvenWerks> Adding two spin boxes for number of pulse-jack bridges (input and output) this means the user can have 0 or more pulse inputs and 0 or more pulse outputs.
[17:26] <OvenWerks> Given that, should we retain the pulse bridge check box as well?
[17:26] <OvenWerks> Obviously 0 in both boxes is the same as off
[17:27] <OvenWerks> Eickmeyer: ^
[17:28] <Eickmeyer> Yes. There are reasons to disable Pulse if Jack is running, the biggest of which is to lower the latency (buffer).
[17:28] <OvenWerks> 0 bridges in both boxes already does that
[17:28] <Eickmeyer> Oh! Multiple bridges? I'm having trouble understanding why we'd need multiple.
[17:30] <OvenWerks> pulse with the dummy backend has no effect on either jack latency or cpu use, so it runs all the time. This also allows us not to mess with the pulse configuration.
[17:31] <OvenWerks> need for more than one bridge? simple, think about a podcast where one of the speakers/guests is on skype. Now we want to play back something from a browser but want to mix it in a jack app
[17:33] <OvenWerks> In such a case one input bridge and two output bridges would be needed
[17:35] <OvenWerks> It would also allow someone to choose an output device from inside pulse where jack has more than one
[17:44] <OvenWerks> Eickmeyer: if you run the latest -controls from CL should not longer give the dbus error.
[17:45] <OvenWerks> Published 35 min ago now :)
[17:45] <Eickmeyer> Cool. 
[17:46] <Eickmeyer> RE: Pulse bridge: Oh! Yeah, that makes sense!
[17:47] <OvenWerks> I could just use one number for bridges (input = output) but I think it is not worth the performance hit.
[17:50] <Eickmeyer> I would like the ability to, with the dummy driver, specify the number of in/outs. That becomes extremely handy when doing setups without the physical hardware available, i.e. having Ardour or Carla all set and ready to go/saved with all connections, then adding the physical hardware later.
[17:50] <Eickmeyer> Especially handy for portable setups.
[17:51]  * OvenWerks adds it to his list
[18:26] <OvenWerks> It may be that some boxes should not even be visible in some modes. For example, the USB master box should not be visible in FW mode. But I have not been able (so far) to hide boxes.
[18:27] <Eickmeyer> I agree with that. It's pretty clear that USB and Firewire don't mix. (no pun intended).
[18:27] <OvenWerks> As master no, but bridged yes.
[18:28] <OvenWerks> Can't bridge fw of course, unless it is using the alsa driver
[19:29] <Eickmeyer> OvenWerks: Confirmed, no more dbus errors.