 Okay, so anyway, welcome to the meeting. I'm Dan. I'm hosting the Circuit Python weekly meeting for November 28, 2022. This is the time of week when we get together to talk about all things Circuit Python. What is Circuit Python? Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit. So if you want to support Adafruit at Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.it slash discord. We hold the meeting in the Circuit Python dev text channel and the Circuit Python voice channel. This meeting usually happens at 2 p.m. U.S. Eastern time at 11 a.m. U.S. Pacific time except when it coincides with U.S. holiday. In the note stock, there's a link to a calendar you can view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you would like to receive these notifications, ask us to add you to the Circuit Python U.C.'s Discord role. As I mentioned, there's a note stock to accompany the meeting and recording. The note stock document contains timestamps to go along with the video so you can use the doc to view only the parts of the video that interest you most. The meeting tends to run 30 to 60 minutes, so this gives you an opportunity to skip around. After each meeting, we post a link for the next meeting notes document to the Circuit Python dev channel on the Discord, and we pin that link, that post to the pin messages for the Circuit Python dev channel. You can check the pin messages to find the latest note stock, so you can add your notes for the next meeting. If you wish to participate by Canada 10, you can leave hug reports and status updates in the document for us to read during the meeting. This meeting is held in five parts. The first part is community news. This is a look at all things Circuit Python and Python on hardware in the community. It's a preview of our Python and Microcontrollers newsletter. The second part is the state of Circuit Python libraries in Blinka. This is a numerical overview of the entire project, quantitative overview. It's a chance to look at the project by the numbers separate from what we're all up to. The third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. The fourth is status updates. Status updates is an opportunity to sync up on what you've been up to. Take a couple of minutes and talk about what you've been doing the last week since the last meeting and what you'll be up to over the next week until the next meeting. And finally, the fifth part is in the weeds, which is an opportunity for more long form discussions. These discussions can come out of status updates or be something you've identified ahead of time as too long for status updates. With that, I'll do community news. I'll take a timestamp. I've screwed up my timestamping. Okay, timestamps by hand from now on. Okay, don't press the reset button on the timestamp. Okay. So, I have a few items from the newsletter. First of all, we've gotten over 10,000 subscribers to the Python and microcontroller's newsletter that happened on November 22. Thank you. Our goal for this weekly newsletter is to be the best source for weekly updates in the Python and hardware space. It's our readership who inspire us. Keep making. And thank you so much to Ann, who does this newsletter each and every week and encourages people to subscribe and collects all kinds of news, both contributed and based on her own plowing through news sources. So thank you very much, Ann. Another milestone this week was Discord. We reached 36,000 subscribers in Discord. The Adafruit Discord community, where we do all our circuit Python development, the Open, reached over 36,000 humans. Thank you. Adafruit Believes Discord offers a unique way for Python and hardware folks to connect. Join us today at hdtsadafru.it-slash-discord. 36,000 is a lot of people. My hometown only had 30,000 people in it all together. The last piece of news I want to highlight this week is that the Raspberry Pi Pico, which is made in various places, including in the UK, and I believe maybe, I'm not sure if it's made in China or not, but now it's also being manufactured in Kenya. There's a picture in the notes document, the first pieces of the first run of the production of the Raspberry Pi Pico was manufactured in Kenya, and there's a link to the Twitter thread for that. All right. So to explain where this news comes from, let's talk about the sort of Pythonically newsletter. It's a community-run newsletter emailed every Tuesday. The complete archives are in a link in the notes document. It highlights the latest Python and hardware related news from around the web, including CircuitPython, Python, and MicroPython developments. You can contribute your own news or projects in the newsletter by editing the draft in GitHub and submitting a poll request, or you can tag us with hashtag CircuitPython on Twitter or Mastodon or email cpnews at Adafruit.com. Now we'll move on to the next major section. Let me take another timestamp. The state of CircuitPython libraries in Blinka. As I mentioned, this is a quantitative overview of the entire project. We'll now start talking about what's going on in the project. So overall, in the past week, there were 67 poll requests merged by 10 authors. There's some new authors I see, M. Montal, Mr. Pank Zero, T. C. Franks, M. Kalkukuska, and those are maybe not brand new, but they're relatively new. So those 67 poll requests were reviewed by seven reviewers, and there were 18 closed issues by eight people and 13 opened by 13 people. So let's go on to the core. Scott, would you be interested in reading the core? Sure. Okay, so the stats for the core. We had five poll requests merged from four different authors. Pixel Clay is a new author, so thank you to them. We had three reviewers, so thank you to all of our reviewers. We have 30 open poll requests, which is kind of a lot, so it would be great to get this down. I kind of like, it really bothers me when it's more than a page, which I think is 25. So we should take a look at these, and I know people like leaving drafts open, but maybe we should have a discussion in the weeds about how to actually do that, because it bothers me. Anyway, I'll add that later. For issues, we had seven closed issues by five people, and seven opened by seven people for a total of 577 open issues. This number does tend to slowly increase, but we categorize issues so that we have an idea of urgency, particularly in terms of prioritization for folks who are eight different funded. So we have 28 open issues on 8.0, which is the stuff that eight different funded folks are working on kind of first and foremost in order to get 8.0 stable out. We have 503 open long-term issues. These are the ones that are kind of the lowest priority for eight different funded folks. And then we have five issues not assigned to milestone. These are the things that we haven't triaged yet, and that we should triage and will triage today. So that is the state of the circuit path in court. All right. Thank you, Scott. All right. So this applies to all of the Adafruit Circuit Python libraries, which is everything that begins with Adafruit underscore, CircuitPython underscore, as well as a few extras, including our cookie cutter and the community bundle. So over the last week, we had 59 pull requests merged from four different authors and four different reviewers. This seems like a lot. I will explain why when I'm done, when we get past this part. The longest standing one was 23 days, so it's good to see we're still getting through some older PRs. A majority of them were three to two days old, leaving us with 87 open pull requests. And as I stated last week, when the number was almost twice that, we made basic changes, not functional changes to across all the libraries, and all of those are getting merged finally. So that is why there are so many PRs. And you'll notice later that there are not very many updated libraries. Because Eva was waiting to do the merge sweep before doing the release sweep. We had 11 closed issues by four people and five open by five people, leaving us with 588 open issues. 98 of those are labeled good first issue. If you're interested in contributing to CircuitPython and the Python side of things, check out circuitpython.org slash contributing. You'll find all of this information and more, including open pull requests listed out and all of the open issues. If you're new to everything, good first issue is a great label to start with on the issues. We have a guide on contributing to CircuitPython using Git and GitHub. And we're always available on Discord to help you out. We don't let the process intimidate you. We want to make sure that you can contribute in a way that works for you. If you're interested in reviewing, check out all the open pull requests. If you have the hardware, please test it. If you do not, take a look at the code. Let us know how it looks, syntax, spelling, stuff like that. Any kind of assistance like that is super helpful. And we love to hear it. So leave a comment. Let us know you did that. And once you're comfortable with that, we can talk about leveling you up to our review team. This week in library PI PI download stats, the total library downloads over 323 libraries was 183,107. And the top 10, the first four are still pretty standard. NeoPixel is up higher than it has been in the bid. And the rest of this is actually looking kind of changed up this week, too. So if you're interested in that, it's in the note stock. As I stated, there are a few updated libraries, but no new libraries this week. So keep an eye out for that. And also the list should be pretty long next week, as the sweep should be done this week sometime to release everything. That's what I've got. Okay. Thank you, Katnick. Okay. Next up is State of Blinka, and Maker Melissa usually reads that if you're able. Yeah, I'm here. So Blinka is our circuit Python compatibility layer for MicroPython and Raspberry Piboards. And so for the Blinka section, this includes Blinka and the platform detect and the pure IO and a couple other Blinka specific libraries like the display IO and the extended, but extended bus library. And this week we had three pull requests merged by two authors and one reviewer leaves six open pull requests amongst all those different places. And there were zero closed issues and one opened, leaving a net of 86 open issues. We had 21,816 Pi PI downloads in last week, and we are up to 8,010 Pi Wheels downloads in the last month and we're at 98 boards currently. Actually, we're really at 99, but we need to add it to the circuit Python work and then it should appear as 99 here. And that's it. Okay. Thank you. Thank you very much, Melissa. We'll now move on to hug reports. Hug reports is a chance to highlight folks in the circuit Python community and beyond for doing awesome things. I'll start with the hug reports and we'll go down the list alphabetically to give everyone a chance to participate. If you're text only or missing the meeting but have hug reports in the notes document, I'll read them off as I get to you in the list. All right. So I'll start. I'd like to thank MicroDev for keeping an expert eye on the expressive related PRs. They often are able to spot things that, being very familiar with expressive development, they're often able to spot things that I might miss if I make a PR. And thanks to Nerodoc who is paid to do all kinds of continuing support in Discord and in the forums. And thank you very much, Nerodoc. He does it with expertise and patience. We really appreciate it. Now I'll move on to attic data. Thanks to Bill88T and Paul1 for the, let me just take a timestamp before I forget, for the PicoWiFi AP. And thanks to MakalPakusa for major improvements in the Adafruit HDTV server library. And I'd also like to thank Makal for those changes. You get a great job of cleaning up the library. Thank you very much. Next is DJ Devin. Go ahead if you're available. Okay. Thank you. I'd like to give a hug to Nerodoc and Hem for helping me out with the Rainbow PWM code so that I could get the RGB mod working on the step switches. And a group hug to everyone who makes Adafruit, CircuitPython, and cool stuff happen every week. Okay. Thank you. Let's now move on to FoamyGuy. All right. Thanks, Den. This week, hard reports. First one for Mark Gambler for help testing and fixing some errors, as well as implementing the SliceGator inside the PixelMap that I've been working on this week, as well as also thank you to Mark for pointing me towards some resources to use basically for debugging on the ESP32 S2 more in depth than normal. So thanks to Mark for that stuff. Thank you to Jeff who started the PixelMap stuff initially, the stuff that I've been working on this week with help from Mark, as well as Jeff pointed out a feature on GitHub to me this week that I hadn't seen before like an except change from I guess a proposed change as part of a PR. So that was a very convenient way to approve somebody's proposed change. Thanks for that. Thank you to DJ Devin3 who found and shared a link back with me from an old video where I was working on debugging hard faults. And I was attempting the same thing again, but I had forgotten the process. So that old video actually helped quite a bit to get caught up to where I needed to be. And then thank you to Scott, Tanu, for reviews and discussion on the DisplayIO API change, as well as a point in the right direction for where to find the initialization that happens inside there where we needed to make some tweaks. And then a group hug for everybody. Thanks. Okay. Thank you. Okay. Next up is Jeff. Hello. So I wanted to thank Tim and Mark for picking up work on the Encore PixelMap class. I tend to pick up a lot of shiny things and then not necessarily finish them. So I'm counting on you two now to get this over the finish line. To Katni for chatting last week, both personal and technical, to Ann Kudos for reaching a milestone of newsletter subscribers, to Ingrid, my spouse, for helping me tidy my work area this weekend. It was a little bit out of control. And last but not least, a group hug. All right. Thank you, Jeff. Okay. Next up is Katni. Thanks, Dan. So first up a hug for Jeff for helping me with some last minute changes to a personal project I was working on and was able to finish it by my goal of before Thursday. To Dan for some suggestions on how I could make an outdoor project completely quick disconnect, I left one of the wires, one of the sets of wires hardwired and didn't think about it until it wasn't working. And I wished I could easily bring the whole thing in the house. Hello to Jeff for a wonderful chat and catch up last week to Liz for writing up the code for my upcoming project guides. I'm sure I missed people and a group hug. Okay. Thank you. Okay. Next up is Maker Melissa. I just want to give a group hug. All right. Thank you. Okay. Next up I've got a couple of people who are text only first Mark gambler. Thanks to Paul Cutler for having me on the circuit python show this week. And thanks to Jeff and foamy guy for working on the pixel map class. And then micro dev gives a group hug. And thanks to Scott for fixing a bug in the continuous integration script. Okay. And next is Scott. Hello. First a hug report to Melissa for hosting show and tell and also all over her work on code.circuitpython.org. Hug report to Geekma projects for trying out the web workflow and posting about it on nested on hug report to Lord Rybeck and our dagger for digging into building circuit python. I think both of them came along in the forums and I suggested that they do that. So it's it's cool to see people taking me up on that. Thank you to bad lock B for the PR that they're working on adding code spaces support. I think what this will allow you to do is you like use the online GitHub code editor to edit and build at least cortex and boards should be awesome and hug report to foamy guy for making the root group set of all which is an API change. We talked about starting with circuit python 8. And then lastly a hug report to the ship who Narada Kiyoshi and foamy guy for helping folks on the discord channel particularly with the help with channel. So thanks to everyone there. Okay, thank you Scott okay and finally Tectric who's text only gives a group hug okay now we'll move on to status updates which is our time to sync up on what we're doing. I will start and we'll go through the list alphabetically as before when I call on you take a couple of minutes to talk about what you've been doing since the last meeting and what you'll be doing until the next meeting. This is also an opportunity to provide tips and tricks relevant to what people are working on and what you're doing does not have to be exactly circuit python related if you've renovated your kitchen and you're proud of it and that's what occupied your time that's fine too whatever whatever isn't you think would be interesting. Okay I'll start take another timestamp. This was a week due to Thanksgiving I was out of town for several days. First of all I fixed a couple of APIs in Wi-Fi.radio whose signatures were not quite right in the documentation and also the code that checked the validity of the arguments that were passed in was also not quite right. So I fixed those things. On SAMB51 and related chips I fixed playing monophiles when stereo output is requested. Before this fix there would be a buzzing noise sometimes like about half the time when you were playing monophiles but you were outputting to two DAC outputs so that's fixed. In both of these cases I was fixing trying to fix something else which I could not reproduce but in the process of trying to test things I discovered these other problems so it seems to be my life in the past couple of weeks. I'll continue working on 80 issues this week and I think we'll make another beta this week so I'll do that not exactly sure when but when the Pico when Scott finishes and the PicoW Web workflow and it's reviewed that's probably a good time to do that. Next up is DJ Devin. Go ahead. Thank you. I don't know if this was really last week or yes this week. I successfully modified the Adafruit step switch into an RGB step switch. It's a hacky modification not a drop in a soldering iron and a dremel or sandpaper are required to make the modification because you have to fit a four pin LED into the two pin housing. This now offers a way for anyone doing a project with step switches to make them RGB if they really want to and I have a 10 minute video on my YouTube channel that shows the entire modification process from start to finish. I have yet to make another revision I have to make another revision of my TR cowbell board in order to accept the new four pin RGB LEDs which also requires PCA multiplexers because four times 16 step switches is a lot of pins. The step switch breakout boards from Adafruit only accommodate holes for two pin LEDs so they initially forwent the four pins so they might have to update their next board revision to accept the RGB LEDs and put those four pin holes in there which is going to make their board revision a little bit different looking. I finished up the cyber ski goggles from a proof of concept to reality. I used a QV Pi S2 and a 350 milliamp battery for that. I went on show and tell last week and showed off both the ski goggles and the step switch mod and I put a link to the circuit python github code powering both of those so those two are easily searchable on my github. I started working on a request API for Instagram only to figure out that you need a Facebook developer account because I never realized that like Instagram was face I don't use them so I didn't know that they were both owned by Facebook. So if anyone and then I decided against it because I don't really use Facebook and not a fan of it so if anyone wants to do a Facebook or Instagram API there are now plenty of request API examples in the request library example folder in order to create one. I've decided not to be the one to do that instead I've decided my next API to tackle probably be Octopart and I switched Macedon servers this week on to the Hackaday social which is a new Macedon instance that just popped up and because it's kind of maker related I figured that's kind of more appropriate for me to go there and I really wish out of it would make one so I would join that immediately. So you can find me at treasuredev.hackaday.social that's it. Okay thank you all right next up is Formyguy. All right thank you so last week I worked on a couple of different things primarily in the core one of them was making the root group setable on display objects this was the display API change that we discussed a few weeks back in the weeds in particular I was working mostly last week on what happens when you set it to none it used to be you would set it to none to show the circuit python terminal in the new version though none will actually just show nothing but when I first attempted to make that change I ran to a hard fault tried a couple of different ways to debug it which took some time getting back into the swing of things with debugging core stuff because I hadn't done that for a little while and I haven't done it enough to just be familiar with it but we eventually got there I found out the ESP32S2 actually makes that super duper easy just has a pin available there to read it so that was pretty straightforward I did eventually end up getting it resolved by using that debug pin on the on the feather TFT and then parsing the results that came out of there figured out what part of the code needed to be fixed and got that done not before taking the teacher detour though as I was trying to debug that hard fault one of the things I tried to do was use a metro M4 device because it has the little debug header that can connect to a J link so I thought that was going to be making stuff easier to debug and when I did that I ran into different hard faults I've got something else I think something unrelated to look into this week they'll try to narrow down a bit further I did make an issue for it with my initial findings but I'm gonna try to pair it down to less less code to try to figure out where it's at more specifically the other one inside the core that I worked on last week was the pixel matte PR I spent a bit of time figuring out how to get it reverted back to a good version after I messed up the merge I try to merge main to get it updated and I must have done that incorrectly because I ended up with a broken one for a bit but I got that straightened out and then worked on the Python layer the Python code that will essentially use that new core class I did the wrote the actual code for it or really just adjusted what's there today since it's an existing Python class it just needs adjusted to use the core one so I did that and then test it out the existing examples with it for this week I so far today I was working on some of that stuff the display IO API change I got that worked out the rest of the way this morning and put in the latest commits that I think resolve everything I also uploaded a tester script that runs through all the different scenarios and prints out the results after each step so it's easier to figure out what it's doing and when it's doing it hoping to get the pixel map effort finished up this week I'll be pulling in the slicing getter code with help from mark and then if we decide we want to do it move the Python code to its new home and I have a entry in the weeds to discuss that a bit later and then the other thing that I did so far today was work on the HTTP server that was changed recently I think it was mentioned a bit ago actually it was changed recently and one of the changes was making it into a package I guess a folder instead of a single file and so the import syntax needed updated somebody found a learn guide today in the help with channel that was not importing correctly so I looked into that and figured out that was the reason and submitted PR to change the imports for that and that's what I got going on thanks all right thank you okay next up is Jeff hello so like many of you last week was a short week due to the holiday although I started and completed the code for the next keyboard to USB HID adapter with circuit Python and then just kind of lazily over the weekend I printed the parts and built it the annoying Pedro are doing a collab with me holiday theme so I'll put some LED strips on it and then we can start working on some code and I'm not sure exactly when that will come out because it's also dependent on a new product going into the store so this week my number one is circuit Python core bugs that were assigned to me a couple of weeks ago last week assigned to me last week when we went through the bug list in a separate meeting I will maybe work on completing the guide text for the next keyboard although my goal is for that to be published in December so I've got time as I mentioned I may start writing code for this holiday themed LED object and finally if you are waiting on me for something please ping again my inboxes got out of hand I archived a bunch of stuff so I may have snubbed you and just just please ping me again and that's what I got okay thank you Jeff okay next up is Cadney hello so last week was super short I met with Liz to discuss the code she sent me for my upcoming project guides to get a better understanding of it and suggest changes Liz made all the changes and sent the updated code back to me I worked through some of it to change up a couple things it was mostly formatting and comments I have to finish that up this week and so this week I'm getting caught up from last week and it's some point hoping to meet with Tectric about an adbop PR but it's really not critical we keep putting it off so that's fine file an issue on the Adafruit IO library about IP based time not working properly short version is that the Adafruit IO library doesn't give you the opportunity to pass in a specific time zone so it tries to guess based on your IP and that is not happening so it really it just uses a UTC I need to finish cleaning up the project code and get it back to Liz so it can get up on learn and then this week I plan to begin the countdown holiday countdown display project and work through it work work through the end of the week on it so we'll see where I've gotten by then and in personal news which I have way more of I wrote up a feather version of the previous pie based receiver for my Laura mailbox notifier I didn't write the original pie code so I had no idea how to modify it and add an ad in Adafruit IO code as well the pie was overkill from the beginning and with and the feathers with built-in TFTs hadn't been released yet so the pie with Laura bonnet including the display made the most sense this version uses the status new pixel for the status LED instead of a barrier LED displays info on the built-in TFT sends the mailbox and battery data to Adafruit IO which sends you an email when the mailbox door is open and when your battery is low the new pixels nestled between two taller components so in an effort to make it more obvious I ended up hot gluing a chunk of hot glue tube over the new pixel worked like a charm it's essentially adding a small light pipe but it's short and is about the same size as a chunky bare LED that I had soldered to the pie made a number of attempts to make the boot button easier to press it's rather tiny and rather close to the reset button none of the methods I tried worked but it's worth noting that all of them involved hot glue hot glue is difficult to apply precisely so it just blabbed everywhere in the button wouldn't work I did manage to make a tiny dot of it once but the method didn't stay on the board for more than a minute so that was pointless and it's more compact than the pie obviously and in the event of issues will be much easier to troubleshoot this is interesting because this is why we made circuit python what it is I realized two days later that I had not copied the code off the feather after making further edits and that meant I didn't have a current copy of it my dad is not exactly tech savvy but I walked him through plugging the feather into his computer finding circuit pie copying code up high to his desktop and emailing me it took four minutes over the phone it worked perfectly I still want to clean up the sender code and update the receiver to match so that's part of why I needed the receiver code the other half is that I can update my github repo with the feather version I lucked into pi zero W's from a co-worker for the original project for most folks they're basically on obtaining him for now so it'll be nice to have a more readily available version finally I ordered some super glue to try to glue something on top of the button and make it simpler to press we'll see if my idea works or not that's what I've got okay thank you cat the okay next up is maker Melissa hello last week I worked on code.certified.org and fixing bugs related to the level of flow and I'm currently redoing the USB workflow using some functions that work with the other workflows this week I'm gonna add some new or I need to add some new Blinka boards to the two certified org we get to underboards and then continue working code.certified.org and then maybe I'm improving my ability with bonus that's our map okay thank you okay next up is Paul Cutler. Hey Stan there's a new episode of the circuit Python show out today with Mark Gambler we chat about how we got started with computers going viral with his monster eyes project and contributing to the circuit Python core thanks okay and now Scott hello I've been getting back into the swing of doing reviews and issues I'm sure you all noticed me commenting on stuff I have a PR out for adding the web workflow to the PicoW without MDNS so you have to use the IP but I do have MDNS working with some LWIP modifications and we'll PR that next and hopefully it'll get in this week I'll look at other web flow issues after that and I also just realized that there was two API changes I was suggesting that I should probably do this week as well so I'll add that to my list I fly to Michigan on the 14th of December so we had like two and a half weeks until I'm like away from my desktop and all of my stuff so I'm kind of starting to think ahead about like which dev boards and what do I want to bring my salier or my J link and stuff like that so thinking about that and then this weekend kind of impersonal stuff I spent the weekend thinking about how to catalog what files are on what external drives in terms of keeping track of backups and where back where files live in backups and like if they're on Google Photos as well that sort of stuff so if you have tips and pointers please bug me in the discord about that too and that's it for me okay thank you Scott and finally I'll read tech tricks contribution text only last week wedding turkey day and sickness oh my so nothing to report on last week this week continue working on the Pi Pi stats update with catney start working on the pylon upgrade for the learn guide examples continue working on the command line tool for uploading circuit Python firmware to boards so this is not circa it's kind of like you have to up or whatever and looking at things on a backlog to do and prioritize so review and to prioritize so reviewing that this week in personal projects it's time to make the circuit Python Nokia on mass for friends and family that's a Hanukkah menorah based on circuit Python and I received the PCBs and it began ordering components all right thanks you everybody our next section is in the weeds where we do long form discussions of various kinds and we just start up right away I'll take a time stamp here and Jeff has something to say about the colony schedule yeah so I know a lot of folks take time away from their computers during December and I greatly support this so just a heads up that in the upcoming meeting calendar we do not have a meeting December 26th or at all that week but I did want to find out what people would like to do about the meeting that would normally be January 2nd we could hold it on January 2nd on January 3rd or skip it on the third on the third mm-hmm okay anyone else with an opinion all right then I'm hosting I'm hosting that one in the third works fine all right that's good to know all right then I will generate the 2020 2020 2023 meeting calendar based on that and that will include no meeting the week of December the 25th 2023 which is just around the corner 13 months from now thank you okay next is foamy guy who has an API question all right thank you my question is basically around the new pixel map so for folks that don't know Jeff started working on this too well let's let's take one extra step back further actually for folks that don't know in the LED animation there's a class called pixel map it helps you basically take a grid of LEDs and treat groups of pixels within that grid as a single LED for the purposes of animation so you could turn them all on to the same color at the same time that class today is inside LED animation Jeff worked on a new one that lives inside the core that's more efficient because it is inside the core instead of Python code the root of my question is there will be still a Python class called pixel map should it stay where it is today which is inside the LED animation library that's inside I think a helper to stop high file if I recall correctly or should it move to a new library like Adafruit circuit Python pixel map and then it would get imported as Adafruit pixel map and it would be all on its own separate from LED animation but of course LED animation would still use it or the examples there within I guess any thoughts on that from anyone I have this idea that might be can you it seems to be a might be useful in other contexts than the animation library yes yeah definitely display tech scrolling or something I don't know something else yeah certainly in an animation yeah definitely agreed I was thinking about that as I was writing some of the testing scripts that weren't using that that weren't actually using animations at the time and yeah I was kind of musing on it a bit thinking that it was there's lots of uses for this idea basically just treating arbitrary groups of pixels as one especially because you can make multiples of these maps on the same strand so you can kind of like one second be treating certain groups together and then the next second change and be treating an entirely different set of groups together and that's totally independent from the animation library so you can do all of that by itself so maybe that points towards it being on its own then probably I would think right yeah that's what I'm saying yeah because it's like oh this is actually a general purpose thing that was made for a specific use case but there are other use cases yeah exactly okay I will work on cookie cutting up a new library for that then right now I have a draft PR submitted in LED animation just so how to place put the code but I'll cookie cut that into its own library and get that going this week okay all right thank you all right and finally Scott has some questions so I was looking at the PRs that we have open and a number of them are draft and I'm very sensitive to the number of PRs that are open at the top like the 29 and I'm wondering what policy we should have for draft like when do we leave them open when do we move them to issues because I'd rather them not just hang around I feel that it's kind of a deficiency of the GitHub UI that they're mixed up with the regular PRs right they are open but they're just long term you know or they're on hold or something and there's no way to indicate that right in that list it doesn't you can't sort it you can't push them all to the end or anything so right we can make a mechanism that says oh yeah we'll close them but like you're saying like keep an issue open for them but they aren't really closed you know they're not really closed so I feel kind of funny closing them because then they fall off people's radar well that's that's why I was thinking like having issues that link to those branches yeah so 10 of the 29 open ones are draft I mean I think we can I think it's a good idea to have issues for them because it's always nice to have a corresponding issue right I don't know that's it we might ask for instance Deshipu you might ask him about it some of the what some of the other ones are hanging out in various ways but yeah what is bothering you the most is it this list it's an existing period it's the number it's the 29 on this list like I'm asking because I'm almost certain that we might be able to do something with the API to eliminate the draft PRs from this list in a lot that doesn't involve closing them well yeah I don't think I think there's I think it's a it's a tag and we can we can tell Adaba to ignore that tag are you talking about but Scott Scott you're talking there are two places where we see the list one is in the weekly in the status yeah it's at the top of these notes and that's not my concern okay that's what I was concerned is like on the page for circuit pipeline right because like I look I look at a lot of projects and the health of the project is indicated usually by how many pull requests there are in the backlog right and I pride us in keeping up with that except that number just gets higher and higher is if we collect PRs so suppose that we just changed the title so it had draft in all caps as the first let word or something would that make it easier to sort mentally well it doesn't change the number that bothers me we can't change the way that like without closing we can't change the way that that get had counts for that number at the top yeah that's true I mean what you really want is long-term PRs we don't have right we don't have that so I think that each of these is a sort of a well I don't know yeah I don't have a solution it doesn't bother me as much mostly it bothers me because I have to keep reading them over and over again the number isn't bother me as much as the fact that they're intermingled so and they're kind of like I'd rather see them on a separate page or something like that right and you in the search you can say drafts colon true or false yeah Scott I'm curious and maybe thinking about this and and articulating kind of what you're feeling will help me understand better the number of issues is much higher why don't you want to go close all the issues that we mark long-term and so that that number is smaller I I mean ideally that would be the case too right but I think the reason that I am the reason I'm more sensitive for the PR number is because that usually indicates work that people have done right where issues are just like people with random thoughts or bugs or ideas but PRs usually indicate like how promptly things get done and so like if I run across a project where there's 30 PRs open like I'm less likely to propose another PR because I don't think that it's gonna get in so you're you're thinking that people who stumble on Circuit Python are put off by the number of open PRs yes okay I think the more PRs you have open the less likely people are to make another one so sounds like it's I'm the only one that bothers which is part of the reason I wanted to bring it up well I mean I feel a little bit like it's a case of we when you you start measuring something for a good reason like the number of open pull requests but then it turns from you know just just one one signal that's used for good to now we're gonna manipulate this number to be lower because we think the number should be lower and that feels that feels like you know the system made us do something and it is that really serving our best interest and you make a case for how it serves our interest in how other people are responding to that number and that's all that's all true but I'm a little bit sad that just because of this number that get have chose to put in a spot we're gonna for instance make it tougher for people to get information about whether the thing that they're working on builds on all the boards that doesn't that doesn't require a PR though right like at various times I've had trouble with actions in my fork and for maybe that's not the case right now but right now actions is often my fork and I create draft pull requests in part to get those built if I need to change what I'm doing that's fine and of course like you know we might also say a different people are gonna do one thing this is what we want a different people to do and they'll do it but it doesn't really bother me if it's like in draft for two days like it bothers me if it's and been in draft since July right like I guess I guess part of my point is that like it's actually just all PRs that are really old but I I think like drafts drafts are new and drafts are a way to indicate that it's not ready yet and like should it just should it just hang there if nobody's working on it well when there's like the code can still exist in other places and be linked to in other ways I mean I think the ones that are hanging out based on some some blocking thing we could turn those into issues and and and maybe even we could even put a title at the top it says like we open reopenable or something like that you know and then the issue would be there so I think we could look I think that there were some that are that fall into this category and some that don't and we should probably just look at them in more detail rather than making a policy like I mean Jesse Poo has one that's open for a board that he hasn't had time to work on so yeah I could it would make sense we could close that realizing that it will be closed temporarily it's kind of like gone on vacation right this PR right on vacation and or you know this restaurant has gone on vacation and when it comes when the people come back then it will you know the restaurant will reopen again that's right like and we can reopen PR's as well yeah yeah and we can even comment on PR's that are closed right right so let's let's look at the ones that we have and try to do something with each of them and make up a make up an issue like you say and that that is the way to track them and which I had thought of something to add that's related to this which we can move on to if which is I there are a lot of long-term issues some of them are very aspirational and we're probably never gonna do them some of them are bugs and bog long-term bugs tend to disappear and that's kind of bad and it's true that they're tagged as bugs but people don't look at the list that way so I was wondering if we should have two milestones at least for long-term bugs and long-term enhancements that's fine with me that would be that would be interesting is anybody think that's a bad idea because I mean it we really be able to see like okay there's a bunch of aspirational things here and yet and then there are other things that are kind of a priority but somebody could work on this and it's a kind of a defined task and that's what I'd like to see or somebody who wants to know whether like you know how wise what are the audio problems or something like that well I think I think what are the audio problems is better served by like looking for the label audio bug right rather than audio long-term right I wouldn't make audio long-term but I just like to split long-term into into feature you know enhancement versus bugs just so that we can have a count yeah just so we can have a count and so we can and so things and so long-term bugs don't get lost out of our long-term out of our long-term issues but they are labeled 170 of them are labeled bug and the remaining 381 are not labeled bug so just as a statistic that's one-third our bugs okay but I think the some of the older ones are from before we started consistently labeling ones as bug or and there's also like bug in enhancement so they could certainly be labeled one or the other probably some that are not labeled anyway that's just that's just something that I might clean up if you don't object to that then I'll do that I actually would push back on the idea that it needs to be a milestone because it sounds to me like you're really wanting better labeling like that's really what labels are and the nice thing about labels is that you can have multiple on there like I really like labeling them by port as well yeah well maybe we should have it's like we should have be able to add some project defined buttons at the top of the issues thing which we can't do right now these are here's that that's another github feature okay for like common common like breakdowns yes yes like oh that you know show me the all the long-term bugs you know right now you have to type in either you keep a bookmark or you have to make up a search right I find I find the port specific labels probably even more helpful yeah yeah and and for the further like well-defined things like that really should be like good first issue should be for the like this would be great if somebody would be able to pick this could pick this up like there yeah I guess I would push back on the idea that a milestone makes it any easier okay it's really cuz right a milestone is being used as a as a super tag kind of in this case and right I'm trying to think of milestones as a different dimension yeah it's a time dimension right or a prioritization right although lots of people I think lots of projects do use labels for priority as well right right we don't have 801 bugs and 801 enhancements we don't have make that split right now right but milestones have the benefit that you can see like how many there are open and how complete they are all right so the action item is to review the draft ones and figure out if they can be closed without hurting something as long as we make a corresponding issue so let's let's let's check on that yes and we may we may not do that to all of them but we made you do it to a bunch yeah I mean generally we just it would be good to go through all these yeah peers and I think it would also be good to actually to label the draft ones in the statistics in the adabot actually yeah and I open an issue for that but haven't done it yeah maybe we like maybe we should start labeling these better too like I added a board label explicitly because that's really common yeah and maybe we should be better about labeling PR so we can do better find a green breakdowns there as well right all right I think I think I think this is good oh yeah projects has more advanced milestones all right we'll check on that thank you micro dude yeah thanks oh it's like a con bon board okay well projects we don't use projects and we could yeah okay I will I'll wrap up because it's been almost an hour let me put a timestamp here this has been the circuit python weekly for November 28th 2022 thank you to everyone who participated thank you very very much if you want to support Adafruit and circuit python and those of us that work on circuit python consider purchasing from the Adafruit shop at adafruit.com the video of this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will be available on major podcast services meeting will also be featured in the python for microcontrollers newsletter visit adafruitdaily.com to subscribe the next meeting will be held next Monday as usual at 2 p.m. Eastern US time 11 a.m. Pacific that's December 5th the meeting is held on the Adafruit discord which you can join by going to adafru.it slash discord and if you want to be notified about this meeting and any changes the time or day you can ask to be added to the at-sign circuit pythonistas role on discord and you'll get pings about that hope to see you all next week or hear from you thank you everybody and I will stop recording now