 Okay, welcome to Microsoft's DevSync for October 9th, 2020. This is the end of our first week of Sprint 16, I believe, and we're just gonna go around and check in on progress, especially noting any blockers or things that are giving you any work done, any surprises, that sort of thing. We'll start off with Derek today. Yeah, all right. So I've been mostly working on things related to the boards that we've got in process, the 25 new SJ201 board. So I'm getting, so if you guys check the team chat on Mattermost, I posted some images. I finally got that first 3D printed design put together and I've got now a list of things that can be improved upon for the next revision. So I'm working on that. And then there's some additional parts that Michael requested that I got ordered and yeah, just didn't think of moving to be ready to put those together. So that's basically what I've been up to. I don't really have any blockers. Okay, great. Any questions on that? We can't post images of these just yet because of well, just to be totally crank about it, we're going to be filing for a design patent on the design. And this is to protect not just ourselves, but all of our users and community from unofficial knockoffs. We fully intend to offer all of these files as open source files for people to use. But that doesn't mean that we don't have to still protect our intellectual property from abuse and people, you know, basically purporting to be micro, purporting to be things when they might not be quality controlled and all that kind of thing. So yeah, so finding the right balance there between, you know, absolutely being an open source company but also wanting to make sure that people get stuff that actually works is, you know, why we're doing this right here, why we're not releasing the images right now. So just FYI for all those obviously. Let's go to Gets. Oh, wait, there's one thing I should bring up. So one of our top contributors of the community, I think the amount of most, had some concerns about the V1 camera. And so I'm going to chase that down and we might end up looking at maybe some other options. Yeah, I saw the V2 camera being offered for sale in at least one place for the same as what I thought you were saying the V1 camera was was quoted at, I think it was like 10 bucks. So yeah, there might be some more more things to chase down there. Yeah, he said the performance between the V1 and the V2 is substantially better than the V2 and that there's some limitations to the V1 and you know, I think the reason we are considering the V2 or not considering the V2 was because you're possibly thinking about building it onto our own board. You know, if we don't do that, then we don't have that concern because it has this kind of I guess, Raspberry Pi built in a system that kind of identifies that this is a Raspberry Pi V2 camera. So if you try to build your own, it doesn't identify correctly or something like that. So yeah, provided off the shelf, we don't have to worry about that. So I'm going to look into that. Okay, how good is publishing meetings online? Yeah, so I've been focused a lot on Lingua Franca. But I think we're now going to do a one more V0.2 release with just with a few fixes and that sort of thing and then do the refactor as version 0.3 just so that, you know, in case anyone does want to stick on the old version than they can. But yeah, I don't know. It shouldn't be a break and change or anything. So it should be fine. But yeah, it's looking really good though. Keep finding a few little things to tweak, but we're getting very much closer. Yes, lots of tests. Lingua Franca would be an absolute freaking nightmare if it didn't have tests. But also like not just tests on the language methods, but also tests on, you know, some of the internal methods as well. Yeah, but jump in and if you game, jump in and have a look and comment if you think anything's missing. But it's a gargantuan change so it'll take you a while. Yeah. Anyway, what else has been going on? The log thing is working well. I've just got some logs from a PR that's throwing the stop errors that we haven't been able to nail down. So I'll take a look at those. I've been doing some recording with one of our community members Steve or Stratus. Basically, we were going through some home assistant stuff and he's like, can we just record the meeting so I can look back at it? And then we're like, well, why don't we just make these publicly available? So we've done a few sessions and going to package those up as things we can put out there, which at first just go through really simple things like getting Microsoft set up in a development environment and setting a specific version of Python. If you're running something different on your local machine and then we'll get Home Assistant set up and well, not the setup of Home Assistant stuff, but the common IoT framework. And anyway, we'll see how it goes there. And I was even thinking that we might go through the lingua franca, the new structure of lingua franca and that kind of thing. Because we want to have written documentation for all that, but as I'm sure everyone knows, lots of people would just prefer a 20 minute video on something than reading pages of text. So yeah, that's kind of trucking along in the background. Okay, very cool. There was just looking at your tickets and the Wolfram Alpha issue. Do you have, are you being blocked on that? Do you have the key that you need to make that work again? Is that being resolved? It should have been resolved. I've just pinged Johnny to see if he can get you the new key. Awesome, thanks. Okay, so let's go to Kat next. Just an aside, I think that's great, because that's part of our corporate culture, right? We're very transparent. And I think these meetings and those kinds of meetings, hosting those are just, they set us aside. And throwing that chip on there also sets us aside. So I think that's great. It's been a busy couple of days. Let's see. So I reviewed your patent. I looked at it and my only comment was that the, anytime you say optionally or alternatively, you're probably talking to patents. So the irreversible versus the cipher, I think kind of splits it into two different patents. But that's just my two cents. I'm not an expert at it sort of thing. I verified that the SJ201 code that I produced works on the other SJ201. What's odd is that one doesn't play anything out of the speakers, but I can plug the line out into headphones and hear it, even though the I2C volume isn't showing up. So I thought that was interesting that I'm still getting audio out, but I can test. So that's good. I submitted a bug fix for the current image we have. It has to do with a timing issue regarding the message, the GUI message bus on Buddha. So probably better than half of the time. It won't work because it won't get a connection to the GUI message bus because it's there before the GUI message bus is ready. And then it just stores none. And then for the rest of its life, it says none has no method called send. So the poll request that I gave you that you closed had that bug fix. That's in that interface.py code. But as you saw as well, it pulled in a bunch of stuff and that confused me. I mean, I took it from the Kibbe display branch, like you told me to, Chris. And it got a bunch of other stuff besides my Negr fix. So I don't know what's up with that. And I don't know how we're going to get that bug fixed communicated or actually put into the code, but we should probably do it before we cut another image. I'll leave that to you guys. You have the code. Jarvis raised a minor stink on that PR, too. What's that? He said Jarvis raised a minor stink in that PR, too. I've been communicating with him. He's an interesting fellow. He's the guy from Portugal. He's really bright and he's nice and he's very helpful. And I really appreciate his input. He forked our code. Nothing wrong with that. He's got a code that can do things, or else can't. So he's like, why don't you just put that there? And I'm like, I'm looking at the code. It doesn't do that. Oh, that's on my fork. Anyway, so I formally submitted the SJ201 pull request. Thank you, Chris, Chris Gez for reviewing it. It's in your court now, Chris V. I saw you got back to a couple of notes on that. A couple of issues came out of that that I'll bring up just briefly. One of them was I named that subdirectory SJ201 underscore rev A. Chris was thinking maybe we could name them after the board revision. My pushback on that was that I just wanted to call it SJ201. The only reason I even put rev A was that I was hearing that the next board may behave differently. But my concern is if we start naming them after board revisions, there could be five or six boards that all work with the same software. So I'm not sure how to address that exactly. That was the first issue that came out of that. So I don't know. I'm ambivalent. I'll name whatever you want. We're not really going to go back with data, are we? Once we move past a board, we're not going to go back and start using an old version. So I wonder if that's necessary. Yes and no. Certainly none of the prototypes we're ever going to go back to. But we could very well release something for the dev kits, for example, which is the first set of boards that we're going to produce in any kind of large quantity. And we may find that there's something that we want to tweak before we go out and start making $5,000 for fulfilling the Kickstarter and whatnot. It might be something as simple as, oh, hey, we're changing our, maybe we find a way to implement the DPI interface instead of the DSI interface and that saves us $10 on the display. So most of it will be the same, but there'll be a little bit of a software for you on the display side. So I think ignore my thing. It sounds like it'll be Reve until things are out in the wild and then we need to make some kind of real change. So ignore me. I understand the confusion and the concerns there and I do appreciate Chris V's thoughts about tying it to specific hardware revisions. And I think that's actually something we should pursue a discussion of because right now we don't actually have the ability, as far as I know, to identify which version of the hardware you have by querying the hardware itself, right? And that's something that we need to develop. And I don't want to be lost in this discussion as I'm not a fan of naming things after parts. You know, we probably shouldn't be naming anything SJ201 if we can avoid it in the code. I wouldn't think. But... Well, the enclosure code will make sense, I think. But yeah, let's have a discussion about that because we do have the ability to put custom code on the boards that we can read so we know exactly which build it came from and which, you know, even which lot it was produced in and that sort of thing. Well, I'll simply parrot my response to the comments. I'm ambivalent regarding the naming. Just update the ticket with what you want and I'll do it. The second issue that came out of that review from Gez was, and I noted it in the comments, obviously, that I chose to use 10 of the 12 LEDs for the volume. And there was a method to my madness. Not the least of which was it was the easy way out, right? So, you know, if I increase volume one-tenth with an up and decrease it one-tenth with a down and I turn on 10 LEDs, it's a really easy mapping, right? 12 is a pain. I don't care about that. That's just math. The real issue there was that I'm anticipating somebody at some point in time saying, gee, wouldn't it be nice if we had a LED dedicated to the mute slider so that we knew if the microphone was muted? And maybe somebody might say, gee, on the old versions of our hardware, it had an indicator LED that showed when it was listening to you. And so I was assuming that somebody might want at least a couple of LEDs available for other functions than just showing volume going up and down that were somewhat consistent. And again, I don't know that it's that big a deal. I can refactor it. So I'm just pointing out those two things were there. It's not blocking us or holding us back for anything. And once we solidify what the interface and functionality should be, I can go in there and pretty easily change it to handle anything we want. So it shouldn't hold anything up. I just wanted to point those two things out that were brought up there. I reviewed some pull requests. I reviewed some database schema with Chris V, which looked really good. I talked with Chris about, as you guys probably know from previous discussions, the LEDs that we're using require pseudo access for two of the modules that come from the Adafruit library. And so I figured out where to put those in our setup. And I mentioned to Chris, maybe we just replace the section that says re-speaker with that. And then Chris, you had some input on that. So why don't you share that? And just to finish up, the other thing beyond that is that I started on the VK tests for the tagger. The first couple of levels are very simple, like I uploaded a sample. It was valid. Did I get a valid response? I uploaded one with a bug. Did I get a bug response? Anything beyond that is going to be challenging because of the disjointed nature of the processing that's going on behind the scenes. So I can't say, hey, I just uploaded this to there. Let me now pull it in the next request for wake words, right? Because we don't know what the algorithm is going to produce. We don't know when it would actually get moved and processed into its formal location, probably that midnight. So some of that stuff is going to be a challenge. But the initial VK stuff, I should have the first couple of tests banged out by Monday. Thank you again, Chris B, for your input because I was blocked until I spoke with him. But Chris, why don't you share the issue regarding pulling the re-speaker stuff out of the setup? Yeah, I was just worried that how many people we've been kind of touting the re-speaker by DevKit for a while. I don't know how many people out there have got re-speaker mark twos, base mark twos, that we need to or want to support. So just like the SJ201 different versions, I don't know where we stop with these older mark two OTC or OTS versions and what we're supporting and what we're not. So if we want to be able to support older OTS versions with the re-speaker array on it, if it's worth really replacing it or if there's worth giving some sort of option that either you're using a re-speaker or you're using the SJ201. And beyond that, all you're doing in that piece of code in that setup script is you're flashing the one channel firmware onto the re-speaker board, right? Right. Yeah. Well, you know, that's a good point on we don't actually know how many people have built those because we kind of put that call to action. Hey guys, we've got got these plans now. If you guys want to go build your own. So maybe that's worth investigating to see how many people out there have actually done that. Which setup script are you talking about? Well, the question is, are we moving forward going to support the re-speaker build? I guess it's the simplest way to put it. I think we'll continue supporting it on piecraft, for example, but we haven't released anything. Well, the image we have right now, the KIVI image I have right now is basically the re-speaker image. We haven't released the KIVI image. I modified it for the SJ201, but it is a re-speaker image. We've never released the KIVI image, so you can do whatever you like. I get that. The question is, should we? Oh, well, yeah. Do we want to support it moving forward? I mean, we haven't released it, so you can change anything at the moment, and you're not breaking anything. No one's using KIVI on re-speaker, except for us. Well, I guess let me phrase it a different way. I don't know that this is where Chris V was going, but this is where I was going. Does it make sense to freeze the KIVI display build or image that Chris V has created? Go and rename it re-speaker. Take the changes I've applied on top of that for the SJ201. Create a new KIVI image called Mark II. I don't know. I'm just saying, because otherwise, you're technically throwing away work, because it does support the re-speaker pretty well. Yeah, I mean, we have to make the old images, and if we can put something in the naming convention so that we know which hardware it's built to support, or have it changed log somewhere, then that's good. I mean, I think if we're... Yeah. To be clear, I'm talking about, we're talking about the enclosure Mark II repo. Right? I don't know what the repo is. No, it's Core. Oh, wait a minute. I get confused here. Yeah, it's the Mark II repo. That's correct. Core was the bug for the Buddha. Yeah. I guess the real question then is, is that repo is public? Is anybody using that repo to build older re-speaker versions of the Mark II? And if they are, do we cause issues with those people? Are you talking about the Mark II Pi skill thing? No, the enclosure Mark II repo, it's got the recipe for building a Mark II invention. It's got an auto-run .sh script in it. I'll try and find out what we're talking about. What we're talking about is that there is a flag, a file that's put on the image called first run in home, actually in root. No, it's in home. And the first time you boot up your device, it checks for the presence of that file. If it's there, it deletes it and assumes it's an initial setup. Now, that's where I would place the code to install the two root-required or elevated privilege-required modules. So there would be a sudo pip3 install these two libraries there. Right now, there's code to flash the default firmware onto a re-speaker array. So that's technically what we're talking about. But from a higher level, we're kind of talking about, do we want to continue to support re-speaker builds because maybe there's a lot of people using it. Right. I think that that's an excellent question. I don't think we can resolve it right here. Philosophically, I'd like to continue to support something that we've been supporting for some reasonable period of time. Whatever reasonable it is, I think it's going to depend on how many people are using it. If it's 100 people, then we should support it for maybe three or six months. If it's two people, then we'll send it to an SJ201. Right. It'll be cheaper. Yeah, we're all seen cards. So I think we just need to find out how many people have built those devices. That'll tell us how much support we need to get them. But it should be noted that the SJ201, if people want to get a similar experience to what they're getting with the re-speaker, we should have the SJ201s available as a standalone part along with the dev kits. So at some point in time. And so buying one of those will totally replace the re-speaker and give you total compatibility with everything else that we're doing. All right. And just to appreciate, at a technical level, the new build will not work until that line has been inserted at that location in that file. Yeah. My question is just, should there be an if statement there instead of, you know, the checks for something rather than replacement? Yeah. You know, I wasn't really seeing that. That's something that surprised me too. I wasn't seeing like a hardware identifier variable in there. I have seen it in other places that says like Mark II, like in the enclosure code. But I wasn't seeing that in the auto run script. Am I missing something or is it just not in there? This is an important discussion, but this isn't the right place for it. So, yeah. So let's, I don't mind problem solving a little bit, but if it drives on, we should really punt it to you guys talking offline or, you know, make a ticket about it. You guys obviously won't be together whenever you want. I encourage you to do that constantly. Yeah. But with everybody here, you know, let's try to keep it a little more focused. So, yeah. Okay. All right. Thanks, Ken. So, Chris. Yeah. So as Ken alluded to in his update, he and I had had a discussion yesterday about the database schema. So I did implement the database schema as we talked about it before with one change. Basically, we talked about having a derived table that delineates all of the quote unquote final tag values. So once we know that a Minecraft wake word has actually been determined to be a Minecraft wake word, then we put that that final determination on a separate table. So it makes it easier to determine, you know, whether or not we need to, well, from my point of view, whether or not I need to bring that file back up for more tagging. And from Ken's point of view, you know, what he can bring into the training, you know, for different things. And that we think that will help us with some performance instead of traversing a table that has every single tag everyone's ever done. I'm trying to find out, you know, which ones are correct and which ones aren't. So that is now a part included in that schema. I have a branch now of Selene for the tagger. I have the eight, I basically stubbed in the API. I did all the database work. And I am now working on the API call. Probably the hardest part of this is going to be the API call that says, what do I send to the UI? What files do I send to the UI and what tags do I send? So that's going to probably want to be a pretty nasty SQL statement. And I'm kind of working on that right now. On the other hand, that's the pump part. Yes. Yes. It's more challenging part. I welcome a good challenge. And everything else has been pretty easy up to now. So it's taken a while. So that's what I'm working on. I also, as you mentioned, I started to look at Ken's PR, but I have not finished looking at Ken's PR. I just kind of started that before the meeting. That's in time. So yeah, that's where I am. So my progress really depends on how long it's going to take me to figure out. There's like seven or eight tables that hold this information. So writing this query, getting that right is going to be a big deal. So we talked about last time, I think, just implementing a query, right? As long as it could be a simplistic query, it doesn't have to be totally perfect in terms of giving you the optimal answer as long as it gives an answer that could be roughly considered correct. Just to implement something and then get on with implementing the system as a whole, right? So that we can present the user with a bunch of choices and they can actually tag them and that sort of thing. Are you still going to go that approach or are you trying to solve the... Yeah, I'm not trying to solve a huge problem, but I need to know if it's been final tagged or not. I need to know what tags... I need to know what tag needs to be done for a file, what doesn't need to be done for a file. So some of that logic needs to be in there. But yeah, I'm not going to get crazy. I just want to make sure that I return something that actually needs to be tagged. And I don't know if there should be any randomization in there as far as... If we have five different tags... Well, now that's a good segue to my question, which is reproducibility, because I am jumping into VK tests early next week head on. And I'm going to introduce you a term that you may or may not be familiar with regarding testing. It's the concept of a clean versus a dirty system test. So on the back end, and I'll just explain it technically. Typically, if I can wipe the database, recreate it from scratch, and run my tests off of that, that makes it a lot easier to produce reproducible results when you're testing. If I have to go against a back end database that's constantly changing, and I can't wipe clean, that's called a dirty environment and all sorts of weird things can pop up during the testing process and you have to work around that. So from a very high level is our testing environment for the back end dirty or clean. As of right now, what I do is... So what happens is the database gets bootstrapped before any tests are run, but it doesn't get bootstrapped before every test is run. So basically, you bootstrap the database, which is a complete empty copy of the database, and then you run the test against that empty copy of the database. That's a clean system. Okay, so as long as you don't need to be bootstrapped between tests, then we're in good shape. That's fine. That'll make it a lot easier to produce, to be reproducible. Yeah, there's a lot of code in the tests themselves to populate database for those tests, but yeah, very easily, but the code is there assuming there's no code, there's no data in the database at all. That's perfect. Thank you. So yeah, that's me. So the rest of today and Monday, we'll be getting this API call done. Once that's done, it'll be plugging it into the UI stuff I built. Okay, awesome. Maybe we can get another show and tell next week. Yeah, I'm hoping for a working one. Wouldn't that be cool? Yeah. Josh, do you have anything to report on? Sure. So a couple of things. So I printed good closures as quick as the printer. We'll print them, assembling them. I ended up buying a little amp so that I can test them for sound quality and whatnot without having to hook them up to the device. I got on the phone with our friends at Bellina. I had a meeting with them yesterday. I've allocated Monday through Wednesday of next week to evaluate the update processes. The Bellina thing also includes the Wi-Fi update, or the Wi-Fi setup, and operating system updates. And then they foot stomped pretty hard that they're willing to work with us on price. They would value having a big open source community using their software. So I'll be looking at that. I'll also be looking at Pantacore, and then I'll be evaluating Ubuntu are the three that really fell out of it. I've been playing with the coral chip a little bit, not as much as I both should and shouldn't. I should be playing with it from a familiarization standpoint, but I shouldn't because it's the project I want to apply it to. Initially, it's a distraction. But I have at least booted it up and validated that it does provide speedups for code that is compiled across to it, or for TensorFlow models that are compiled, I guess, is probably not the right word, but trained to it. I don't know. What else did I do? I think that pretty well sums it up. I've been, oh, and then we're taking apart the patent control. So we've been having some discussions about that and then fundraising as well, which are both, I guess, separate from the dev meeting. Yeah, that's all I have. So by Wednesday and next week, I should have an answer on what makes sense from my perspective for updates. I'll ask for some feedback on that. And then I would suggest that as quickly as possible, especially given that we have hardware coming, we adopt the update process and start pushing updates to our various devices using the official process so that we can brick our own devices internally rather than bricking hundreds or thousands of devices globally. And I did find out that Bellina does have an open source component called OpenBellina that we could use without paying them. But I see some significant value in working with a partner who can support us there. And they also have a mechanism that allows us to pass chunks of devices off to new administrators, which means that once we sign up a project-like project rollover and get them configured and get all their devices squared away, we can actually turn administration of those devices as a chunk over to the administrators at that company and then collect a monthly fee for helping to administer them. And in that case, the fees, the public fee structure for Bellina makes a lot more sense. Okay, yeah, that's an interesting feature. All right, thanks. I don't, oops, I don't have any updates on the development side here. I've been working on business stuff. But I have, you know, as a little bit of a side project, I've been brushing up on my Python. So maybe I'll get my hands dirty one of these days. Yeah, that's it for me. So anything else? I wanted to go down real quick on the query I'm running. I did want to mention that I am considering performance right now. I may not be considering the actual algorithm, but we're talking about several tables and each of them having millions of rows on them a piece. So I am doing my best to consider how the query will perform. You know, not as much, you know, what returns, but not making sure it returns in more than less than a second maybe. Yeah, and once you have all your queries and stuff in place, we can run some explain plans on them and see if we want to add some compound in the season such. Okay, great. Yeah. I want to make sure that I wasn't further than you cared. I mean, I know you were trying to limit what I do first run, but I mean, I can just write something to just return something. And because, you know, on the first day, we're not going to have a million. But we will have, you know, a lot soon. So I didn't know if that was something we could, you know, if you want me to optimize for performance later and just get something written that works. Or if you want me to optimize for performance now. Well, trust your judgment on it. I think you should make note of anything that you think might be an issue down the road. And at what point, you know, we will have to revisit it and re optimize the performance. Right. So yeah, I wouldn't trust your judgment as to what level of optimization is appropriate for right now. But, you know, imagine that every one of our you know, 9000 contributing members was using the system, you know, would it work for them? Right. You can you can do some math and figure out, you know, what the peak load on a system like that would be. And, you know, scale it appropriately. So, okay. Any other questions? Nope. All right. One other thing I wanted to mention, and sorry, was there's a ticket right there right now assigned to me in the sprint, which is converting the existing API call in core to call the new API. Since you're in the VK test, Ken, did you want to tackle that as well so that I can concentrate on the tagging stuff? Yeah, I actually alluded to that. The API call is going to be tricky because that's where you're going to have big delays. In other words, the initial just, hey, did it upload properly or did it throw an error when it should have? Not a problem. It's the fact that it's not actually going to make its way into the system until midnight that night. How do you test that? It's possibly not going to get tagged right away. And one does get tagged. It's, you know, potentially going to be maybe another 24 hours before it actually technically gets moved. So those are the challenges. But yeah, I was planning on doing all the API tests too. Yeah. Not just the test, but actually the code and core that does the call making sure that's going to work with. Oh, the code inside of you're talking about in core that posts? Yes. Yeah. I mean, all I would do, I assume, is add the authentication, right? It might be that easy, but I just wanted to make sure that was something you were considering. Yeah, I mean, I would leave the two fields that you're not using in there so that I haven't forbidden the future. You change your mind. We're not going to break anything by being there. And I would just leave the call as is and add authentication. If you want me to do that, I'll do that. Yeah, that'd be great. Just one of the things on my list that, you know, if you could get. Not a problem. Not a problem. Okay. Do you have a ticket for it? If you do, just assign it to me. Okay, I will do that. Shoot. And I had something else, but I forgot what it was. Well, if you think about it, you can always send Ken a letter. Okay. Thanks, everybody. Appreciate your time. And always pleasure. We'll have a good weekend and we will talk again on Monday. Cool. Bye. Ken, do you have anything for just a second?