[05:10] <zequence> OvenWerks: I agree. The design of the gui is not done well on falks tool, but then again, it has a lot of useful code
[05:10] <zequence> It works as systray or indicator app
[05:10] <zequence> and i believe it can control any jack
[05:11] <zequence> or just jack2?
[05:11] <zequence> a bunch of tweaks in it
[05:11] <OvenWerks> I am thinking there are things that are set once in a while that are best accessed from settings and other things that get changed on the fly more often.
[05:11] <zequence> Yes
[05:11] <zequence> It should be as minimal as possible
[05:12] <zequence> Even settings should have two layers - basic, and advanced
[05:12] <OvenWerks> That makes sense.
[05:12] <OvenWerks> jack 1, 2 or dbus should all be easy to control... even with pulse thrown in.
[05:13] <OvenWerks> dbus is just easy and automated
[05:13] <zequence> While the design of the gui is interesting, that can be redone any number of times once we have all the features coded down as functions and classes
[05:14] <OvenWerks> functions or procedures I am ok with classes are harder :)
[05:14] <zequence> I dont' care, as long as it works, and is fairly well organized
[05:15] <OvenWerks> objects I understand what they are supposed to do, but the syntax gets me.
[05:15] <zequence> anyway, no reason to reinvent the wheel, so if we can use falktx code, we should
[05:15] <OvenWerks> OK
[05:16]  * OvenWerks is going to put kids to bed
[05:16] <zequence> I have some C code that checks if the user has rtprio and memlock from the kernel. Comparing that with settings will let the user know if a reboot is needed.
[05:17] <zequence> Don't think anyone has done something like that
[05:17] <zequence> Well, ardour possibly does exactly that
[05:17] <zequence> (except for checking settings)
[05:49] <OvenWerks> ardour does that by asking for that access, so does jack
[05:50] <OvenWerks> But knowing before getting a bunch of errors is good.
[06:03] <zequence> Right, jack does that of course