| wonko | Is there a way to send a dbus message that'll trigger msg_cb_new? There appears to be a bug in it, but it's hard to check because I need to wait for it to happen | 13:21 |
|---|---|---|
| wonko | Oh, I think I got it | 13:37 |
| wonko | JACK was getting set to False and not starting | 13:37 |
| wonko | so tweaked that and now it's good | 13:38 |
| wonko | It's all pushed up | 13:38 |
| wonko | and as far as I can currently tell (unless an error pops up while it's running) it should be good to go. | 13:38 |
| wonko | https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-controls/+git/ubuntustudio-controls/+merge/374143 | 13:40 |
| wonko | We can start tracking stuff here | 13:41 |
| OvenWerks | wonko: I didn't get a chance to pull it yesterday, will do so now. | 15:12 |
| wonko | No worries | 15:27 |
| wonko | Merge request in | 15:27 |
| wonko | Think I got everything sorted | 15:27 |
| OvenWerks | autojack line 304 looks wrong. | 15:29 |
| wonko | Ok, I'll take a look when I get home in a few | 15:32 |
| OvenWerks | I will look further too. | 15:32 |
| OvenWerks | I am not sure if it is a mistake from before. | 15:32 |
| OvenWerks | Ok I know what and why that line does what it does... | 15:42 |
| OvenWerks | It compares the PID using the capture device to the PID using playback device and if they are the same... then jack owns it. | 15:43 |
| OvenWerks | This may not be strictly true and it may be better in the long run to actually check if that PID belongs to jackdbus. | 15:45 |
| OvenWerks | In this context it probably doesn't matter or is a good test anyway. If some other program is using it other than jack... we should probably leave it alone rather than killing the pid (someone's project?) and starting zita-ajbridge :) | 15:48 |
| wonko | Yeah, that's not a line I touched so I'm claiming not my problem> :) | 16:14 |
| OvenWerks | I have found some other things... likely my own logic and have made some changes. I am now looking through connect_pa and wondering where my head was that day... | 16:30 |
| OvenWerks | but there were some places where we were not replacing the old config with the new soon enough :P so I have fixed that. | 16:32 |
| OvenWerks | The layout of device is in notes.txt in the main directory, but is not clear enough for someone else to understand well and I am thinking it should be right in the autojack file. | 16:34 |
| wonko | Let's not get too ahead of ourselves | 16:58 |
| wonko | is a re-write something to be seriously considered? | 16:59 |
| wonko | if so we should definitely plan that out | 16:59 |
| OvenWerks | I would like a c++ like struct for each device so I could do device.name device.is_usb device.sub_no device.sub(1).name device.sub(1).has_play etc. | 17:11 |
| OvenWerks | I supose I could have global name = 0 global is_usb =1 etc :P | 17:11 |
| OvenWerks | but an object would be much nicer and much more readable. | 17:12 |
| OvenWerks | even enums would be better... lets rewrite in c++ :) | 17:13 |
| OvenWerks | we could use waf to build it... Eickmeyer would like that :) | 17:13 |
| wonko | I'm down for C++ or Go or whatever. I really dislike Python. :) | 17:19 |
| OvenWerks | packaging anything that needs compiling is at a whole other level. it means learning autobuild or something so it can be multi arch. | 17:21 |
| OvenWerks | It would mean we can use fltk instead of gtk.... which does mean not having to worry about gtk 4 when it shows up. | 17:22 |
| OvenWerks | That is how we lost GCDMaster. | 17:22 |
| wonko | I do DevOps for a living. autobuild is my thing. :) | 17:22 |
| wonko | Of course I'd have to learn whatever janky shit Launchpad uses, but that shouldn't be so bad. | 17:23 |
| OvenWerks | The other part of c++ vs python is that are likely to be people around who can maintain python in the Studio dev group, c++ is less certain | 17:24 |
| wonko | I do totally get that point. I just don't like it. It seems like an artifical limitation | 17:25 |
| wonko | "Write it in whatever language you like, as long as it's Python" | 17:25 |
| wonko | sounds Ford-ish. :) | 17:25 |
| OvenWerks | wonko: in some ways I would like to make controls more generic to work outside of ubuntu as well, but I have looked at what Cadence had to do to make it generic... more if statements than I want to think about. | 17:26 |
| wonko | The joys of cross-distro | 17:27 |
| OvenWerks | wonko: any time one deals with system stuff it gets that way. | 17:27 |
| wonko | Yeah, but it's worse in the Linux world than anywhere else. | 17:28 |
| OvenWerks | is there anything else? | 17:28 |
| wonko | That people use on their desktops other than Windows, OSX or Linux? Yes. | 17:28 |
| wonko | Large market share? Nope. | 17:28 |
| OvenWerks | windows is just that example you get with the computer so it looks like it works, its meant to be removed before the computer is actually used. | 17:29 |
| wonko | hahahahahaha. That++ | 17:30 |
| OvenWerks | OSX? out of my price range, maybe corperations can afford that stuff, not me. | 17:31 |
| wonko | But the point I was making is, to be truly cross-compatible (ignoring windows for the time being) you have to port to 3 or 4 versions of unix and like 47 versions of linux. | 17:31 |
| OvenWerks | yup. | 17:32 |
| wonko | It's frustrating to me because what is the point? Why muddy the waters just because you think things belong somewhere else? | 17:33 |
| wonko | Anyway, enough of that. :) | 17:33 |
| OvenWerks | well there is systemd and initv, upstart has gone. | 17:34 |
| wonko | Which is unfortunate | 17:34 |
| wonko | I liked it a lot better than systemd | 17:34 |
| OvenWerks | systemd is pretty standard these days | 17:34 |
| wonko | that doesn't make it not horrible | 17:34 |
| OvenWerks | anyone who uses an init v system is not going to use controls anyway, cause they have their own script in sh (not bash) | 17:35 |
| wonko | heh | 17:35 |
| OvenWerks | (its called slackware) | 17:35 |
| OvenWerks | Anyway, for now I am going to make things work. connect_pa() looks wrong to me. I think it has been working because my system is sane with my thinking. | 17:38 |
| wonko | co-worker tried to get me to run slackware a couple years ago. Two days of that was enough for me. | 17:40 |
| OvenWerks | The configparser branch is a mess... I may compress it. | 17:40 |
| OvenWerks | (once it is working) | 17:40 |
| * OvenWerks ran slackware for over 10 years from 1995 till mid 2000s | 17:41 | |
| wonko | yeah, I recommend rebasing it down to a single commit | 17:44 |
| wonko | Old me would have loved slackware. New me has better things to do with his time. | 17:45 |
| wonko | I was on Solaris back then. :) | 17:45 |
| OvenWerks | I still like a lot about fvwm | 17:45 |
| wonko | I'm an OpenLook kinda guy | 17:46 |
| wonko | Although I did use fvwm for a long while after switching away from Solaris | 17:47 |
| wonko | Anyway, no more talking until you've reviewed and approved the merge request. :) | 17:48 |
| OvenWerks | My main thing is A) the window with focus should be obvious... like a whole different contrasting colour. B) the window handles should be easy to find and grab | 17:48 |
| wonko | I'm all for A. I never know which window is active in xfce. :) | 17:49 |
| OvenWerks | That is the first thing I change. | 17:49 |
| OvenWerks | gnome is worse... they take away the title bar. | 17:50 |
| wonko | I stuck with gnome for a while when installing 18.04 | 17:50 |
| wonko | but then I remembered xfce was better. :) | 17:50 |
| wonko | While you do that I'm going to beat my face into kubernetes | 17:51 |
| OvenWerks | wonko, Eickmeyer: with regard to policy for controls, right now whichever device the user chooses for pulse to connect it's outputs to is used as the input to connect to pulse as well. I am thinking that probably this shouold not be true. | 18:26 |
| Eickmeyer | OvenWerks: Agreed. It's an OK default, but to have an option to connect the outputs to a different device as inputs isn't a bad idea. | 18:27 |
| OvenWerks | The gui lists it as output device so the user would not expect inputs to follow. | 18:28 |
| OvenWerks | I thnk for now I will set input to system capture | 18:28 |
| OvenWerks | Eickmeyer: but yes in future they will be totally separate... I can't change that now though because the config option is not there yet :) | 18:29 |
| OvenWerks | The main reason for letting the outputs be settable is that the user probably has only one set of physical outputs connected to amp and speakers. So the sound shouold always go there from pulse regardless of what else is set up | 18:31 |
| OvenWerks | So if the user selects their usb mic as system, the output can remain through internal speakers/phones | 18:32 |
| OvenWerks | wonko: I have looked through the code and made some changes (mostly to my own code) but I can't test it just now as I am not at the right computer. | 18:49 |
| Eickmeyer | OvenWerks: Understood. | 18:50 |
| OvenWerks | It will be probably another 3 hours before I can do that after the Yf leaves for work. | 18:50 |
| wonko | Yf? | 19:37 |
| wonko | No worries, I've got things to do. Like my job and stuff. 🤣 | 19:38 |
| OvenWerks | something with xdev is not working | 22:06 |
| OvenWerks | changing other internal devices and hitting apply (reconfig) does not change that. But if I then change the usb bridge setting and reconfig, then the xdev setting is picked up and of course restart jack works too. | 22:08 |
| OvenWerks | Hmm line 312 in autojack | 22:13 |
| OvenWerks | Fixed. | 22:18 |
| OvenWerks | ewyuck... | 22:42 |
| OvenWerks | my logic is weird | 22:43 |
| wonko | Yes | 22:43 |
| wonko | :-P | 22:43 |
| OvenWerks | wonko: in config chnage we really should be doing oldconfig as a save of the old and writing the new config to config. | 22:44 |
| OvenWerks | in reconfig | 22:45 |
| OvenWerks | that is | 22:45 |
| wonko | Yeah, I wanted to do that but I felt it better to leave it alone for now | 22:45 |
| wonko | You should be able to do oldconfig = config and then instantiate a new config. | 22:46 |
| OvenWerks | can we do a oldconfig = config, get config? | 22:46 |
| OvenWerks | How hard is it to copy the whole config? | 22:46 |
| OvenWerks | wonko: either i need to change it now or I have to make a bunch of old_param things to make it work. | 22:47 |
| OvenWerks | if I add the first internal audio device as an XDEV it works, but if I add any other it doesn't | 22:48 |
| wonko | We should be able to but I'll need to look at the code. | 22:49 |
| wonko | Xdev is probably wonky as hell if I'm guessing right | 22:49 |
| wonko | This is where it would be nice if the config file supported complex data so we could just store a list instead of this back and forth to a string nonsense | 22:50 |
| OvenWerks | Actually it is the pulse_in/out as well | 22:51 |
| OvenWerks | or it will be. | 22:51 |
| OvenWerks | The problem is that I have to have both the old and new, but at the same time have set the main to the new. | 22:52 |
| OvenWerks | because we call other bits that read config. | 22:52 |
| OvenWerks | wonko: does the config handle more than one line with the same name? like: | 22:54 |
| OvenWerks | xdev=0,0,0 | 22:54 |
| OvenWerks | xdev=2,1,0 | 22:54 |
| OvenWerks | or will it just save the last one? | 22:55 |
| wonko | I don't believe it does that nicely | 22:55 |
| wonko | Never tried. :-) | 22:55 |
| OvenWerks | probably just save the last one. | 22:55 |
| OvenWerks | I figured it out | 22:55 |
| wonko | I know you hate the idea but what about json or yaml for the config file? Would make us spend less time chasing our tails. | 22:56 |
| OvenWerks | we could split it each time... | 22:56 |
| OvenWerks | or not use the config parser... | 22:56 |
| OvenWerks | The proper way is probably to split it each time we use it. | 22:57 |
| wonko | I had considered switch to that | 23:00 |
| wonko | All let's do it | 23:00 |
| wonko | So* | 23:00 |
| OvenWerks | I really have too much time helping people fix tings already without have them send me a config file in paste that is a pain to read. | 23:00 |
| OvenWerks | but if I can old_dev_config = dev_config and still read all the params that would work fine. | 23:02 |
| OvenWerks | That would get rid of all the param=newparam as well | 23:03 |
| OvenWerks | oldconfig = config doesn't seem to work | 23:11 |
| wonko | This is where python gets weird for me | 23:13 |
| wonko | That's an object so is that a pointer or a copy? | 23:14 |
| OvenWerks | it probably needs to be a copy | 23:14 |
| wonko | https://docs.python.org/3/library/copy.html | 23:16 |
| wonko | You'll be wanting that then | 23:16 |
| wonko | Or a real language. Your choice. :-P | 23:17 |
| OvenWerks | I hate python docs.. allmost every one of them does not have just a few examples of anything. | 23:18 |
| wonko | Or they have examples that make no sense | 23:19 |
| wonko | And no explanation as to what is going on | 23:19 |
| OvenWerks | nope, those don't work either (copy deepcopy) | 23:23 |
| OvenWerks | those work for lists, not objects | 23:24 |
| OvenWerks | wonko: https://stackoverflow.com/questions/23416370/manually-building-a-deep-copy-of-a-configparser-in-python-2-7 | 23:26 |
| OvenWerks | all the answers say the same thing, save the original config as a string then read that string in as if it was a file to the copy... | 23:27 |
| wonko | Oh FFS | 23:29 |
| OvenWerks | And... they are python2 so look up what I do to do the same in 3 | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!