 Hello, and welcome. This is the Circuit Python Weekly for May 8, 2023. This is the time of the week where we talk about all things Circuit Python. I'm Scott, and I'm sponsored by Adafruit to work on 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 and Circuit Python and myself, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join any time by going to adafru.it-slash-discord. We hold the meeting in the Circuit Python Dev Text Channel and the Circuit Python Voice Channel. This meeting typically happens on Mondays at 2 PM Eastern, 11 AM Pacific, except when it coincides with the US holiday. In the NoteStock, 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'd like to receive these notifications, ask us to add you to the Ad Circuit Pythonistas role. There's a NoteStock to accompany the meeting in the recording. The final NoteStock includes timestamps to go along with the video. So you can use the doc to skip around and view the parts of the video that interest you most. The meeting tends to run 45 to 60 minutes. And after each meeting, we post the link to the next meeting's NoteStock in the Circuit Python Dev Channel on the Adafruit Discord. Check the PIN's messages to find the latest NoteStock so that you can add your notes for the following meeting beforehand. If you wish to participate but can't attend, you can leave hug reports and status updates, and the host will read them off for you. This meeting is held in five parts. The first is community news. This is a brief look at all things Circuit Python and Python on hardware in the community. It's a preview of our Python on microcontrollers newsletter. The second part is the state of Circuit Python libraries in Blinka. This is a quantitative overview of the entire project. It's a chance to look at the project by the numbers separate from our status updates. Third, we have hug reports, which is an opportunity to highlight the good things folks are doing and take time to recognize folks in our community. Fourth is status updates. This is a chance for us to talk about what we've been working on and what we plan on working on in the coming week. And lastly, we have in the weeds. This is an opportunity for any more longer form discussions or debates that we need to have and make some decisions. Generally, these are identified ahead of time. But if you think of something during the meeting, feel free to drop it in the note stock, even if we're in the weeds talking about something else. Note stock is the place to get a topic on there. And that's how the meeting will go. And with that, I will switch docs and take a timestamp and get started with community news. So this is a brief preview of the Python for microcontrollers newsletter that comes out tomorrow. So it covers all things Python and Makery and that sort of stuff. So first up, we have quite a list. But I wanted to talk about a number of these things. So the first thing on the list is there is a new Raspberry Pi OS update. And it includes the Linux 6.1 kernel. This is the first update to the official operating system for Raspberry Pi devices in three months and is notable for being the first version powered by Linux 3.1, which is an LTS kernel. The previous kernel was 5.15. The newer kernel offers improved hardware support, new drivers, performance boosts, and better security. Gamers will appreciate the addition of new gamepad drivers. The update also features updated software, including Chromium 113, Mathmatic 13.2.1, Matlab, Raspberry Pi Imager, and big updates to LiveX Camera, Live Camera Apps, including improved thumbnail rendering and Pi Camera 2, which includes exit date and time tags. And there's a couple covered links there. Thank you, PhomaGuy, for dropping those in. Next on the news list, we've got the European KeyCAD conference. We'll be held September 9th and 10th this year. KeyCon, the KeyCAD conference, is the largest gathering of hardware users and developers using KeyCAD. Following the success of the first KeyCon in 2019 in Chicago, this is the second annual KeyCon and the first one in Europe. If you're interested in KeyCAD as a user, developer, or contributor, this is the place to be. It will be held at Plexco Conference Center in Acronia, Spain. Hopefully I didn't butcher that too bad. From September 9th through the 10th. And there's a link there to keycon.keycad.org. Next up, we have CircuitPython and version control. The MovingElectrons blog discusses CircuitPython and version control in projects. Just like coding on a computer, CircuitPython would benefit from some form of version control. A simple Linux bash script is created to manage the Git workflow and copying files. Next up, EduBlocks is acquired by Anaconda. Anaconda is the provider of the world's most popular data science platform. Today, announced the acquisition of EduBlocks, a free web-based drag-and-drop Python coding platform built to help K through 12 students learn fundamental skills. With EduBlocks, Anaconda expands its reach and offerings for K through 12 schools, as well as for beginner level professionals. And those of you who may know that Josh has been a huge advocate of CircuitPython and EduBlocks has CircuitPython support as well. OK, next up, what's the best language for microcontrollers? MicroPython, CircuitPython, Arduino, or C. This make use of takes a look at four popular methods and finds that it can truly depend on what type of user is looking to program for their project. There's a link there. Rust is not one of the options. Speaking of compiled languages, nice segue there, if I do say so myself. Mojo was just announced. It is a new programming language for AI developers. Mojo combines the usability of Python with the performance of C, unlocking programmability of AI hardware and extensibility of AI models. You can find out more by going to modular.com slash Mojo. Eugene Yan ran a simple benchmark, Mandelbrot sets between Mojo and Python. The speedup is impressive and it benefits from Python's libraries. And there's a couple more things there. Oh, they have some numbers. So in Python, it took 1,100 milliseconds. In Mojo, it took 27 milliseconds. Vectorized Python was 240 milliseconds and vectorized Mojo was 2 milliseconds. I did take a brief look at this as my commentary now. It's a superset of Python, so there's additional like struct and different function types. It's kind of like the native decorator and micropython. But it basically takes Python in and compiles it using like LLVM tooling and stuff, I think. So it's created by, one of the founders in modular is a guy who did Swift and LLVM. So that makes sense. Why Mojo is based on LLVM? Oh, is it my, oh yeah. Can you hear my mic is up against my t-shirt? Hopefully that's, I'll switch it so it's not there. Okay, hopefully that's better. Thank you for the heads up, Catney. All right, let's move to the next comment. I was like, why don't I hear the static? Because I can hear my voice. Next up, a universal circuit Python computer. Bob Riches has expanded the capabilities of his microcomputer based full keyboard projects include the Pico computer, 28 universal circuit Python computer. It accommodates a Raspberry Pi, Pi Pico, Pico W or an ESP32S3 as the processor and supports either a 2.8, 2.0 or 1.3 inch display. It also accommodates a Lora module, grove modules and a speaker. There's an optional battery add-on as well. A pretty neat interface. I do say so myself. Okay, next up, well that was the last item of news. So as a recap, a newsletter details. The Circuit Python Weekly newsletter is a circuit Python community run newsletter emailed every Tuesday. The complete archives are available at AdafruitDaily.com slash category slash circuit Python. It highlights the latest Python on hardware related news from around the web including circuit Python, Python and micro Python developments. To contribute your own news, edit next week's draft at the GitHub repo which is github.com slash Adafruit slash circuit Python dash weekly dash newsletter and submit a poll request either there or you may also just tag a tweet or toot for mastodon with hashtag circuit Python on Twitter or email cpnewsatadafruit.com. That's it for community news. We have lots of stuff. Thanks to Ann B who puts that together every week. Next up, State of Circuit Python Libraries in Blinka. This is a statistical overview of the broad circuit Python project. We'll go into a little bit more detail kind of in the sub projects but first I will give you some overall statistics. So overall we had 35 poll requests merged from 24 different authors which is awesome. I think this is largely seeing the impact of the sprint work at PyCon. So thanks again to everybody who ran those. Some new names here that I don't recognize. Ross K1, Z Bauman 3, Zemi Blue, Lanza, S. Domo Zau Lai 13? Question mark? Brass75, Uberi, Jan Volk, Kelman, Zachariah Piper, Jay Rickerson and Gerico are all new names there. And then we had 12 reviewers for those 35 poll requests. So thank you to all of our reviewers who've helped out reviewing all those sprint PRs. Issues-wise, overall we had 24 closed issues by 15 people and 21 opened by 18 people. So it's great to see us in the teens in terms of people involved and also net down three. Okay, with that I will move on to reading the core. So the numbers for the core are we had 10 poll requests merged. I won't read off the new authors because I just did that. We had five reviewers, so thank you to all of our reviewers. We have 20 open poll requests which gives us a nice little cushion in terms of the everything should fit on the first page. We have a number of drafts that are actually quite old. So take a look at those if you're, yeah, Catney's on the core review list. So thank you, Catney. A number of drafts if you're involved in any of those, please take a look and see what is remaining to be done. Love to still close those off. The oldest one is 446 days old. So it is older than a year. So it'd be great to get that done as well. Core-wise, issues-wise, we had 10 closed issues by six people and eight open by six people. So we're net down two, which is great, for a total of 634 open issues. We have eight active milestones. Again, 8.0x. Milestones are used to prioritize work for 80 fruit-funded folks. 8.0x has zero open issues still, which I think is safe to say that we're not going to release any 8.0.x anymore. Thanks to Dan for getting us this far. 8.1x has nine open issues, which I think you made 10 earlier this morning, but is going to be our next focus in terms of stable release. And that would be great to do because that'll unlock our 9.0 development, I think. So we'll want to take a look at those and we'll coordinate with Dan when he's back from vacation. That's a bit about our milestones now and with that, we do have two issues now to sign the milestone that we'll want to triage as well. With that, I'll hand it over to Catney for the library update. Thanks, Scott. So this section applies to a lot of things. It applies to all the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore circuit python underscore. And it also applies to all of our community libraries, which can be found in the community bundle. And these are libraries submitted by community members and also maintained by them as well. In terms of pull requests across all these repositories, we had 22 pull requests merged from 16 authors. A number of the new folks are on this list as well. So thanks so much to all of them. And nine reviewers, which is pretty high and that's also excellent to see because the more reviewers we have, the more authors we can support. In terms of merge pull requests, 80 is the oldest, 80 days is the oldest one we merged. So I'm really glad to see that we're still working through some of those older PRs and the rest were a week or less. Leaving us with 63 open pull requests. In terms of issues, we had 14 closed issues by nine people and 11 open by 11 people. Leaving us with 598 open issues. 56 of those are good first issue, which we were, before Python, I think we were pushing 79. So that's really great to see. If you're interested in contributing to CircuitPython on the Python side of things, check out circuitpython.org slash contributing. You'll find all of this information and more, including a list of all the open pull requests and a list of all the open issues. If you're interested in reviewing, check out the open pull requests. If you have the hardware, test it. If you don't, take a look at the code, let us know if you see anything. And that way, once you're comfortable with that, we can talk about leveling you up to the review team. If you're interested in contributing Python code or documentation, et cetera, check out the open issues. If you're new to everything, good first issue is a great place to start. Those are issues identified that we identify that folks who are new to contributing to open source would be able to do. As well, don't let the process intimidate you. We have a guide on contributing to CircuitPython using Git and GitHub. And we also are always available on Discord to help. In terms of weekly PyPI download stats, the total over 311 libraries that we're tracking on PyPI, the total downloads were 91,945. And if you check out the notes, there is a list of the top 10 PyPI downloads. The top ones are almost always the same, but the top three, rather, and then the rest are always changing up. So if you're interested in who's downloading what, check that out and you'll get a feel for what people were working on this week. In terms of library updates in the last seven days, we had three new libraries this week. Adafruit CircuitPython Wave. We had a biplane from Uberi and CircuitPython LPS-28 from Jose David. There are some updated libraries as well that I will not read off, but they are in the notes if you're interested. And that's what I've got for the libraries. Awesome, thank you, Katny. Next, we'll go to Melissa for an update on Blinka. Hello, let's see here. Blinka is our CircuitPython compatibility layer for Raspberry Pi, or MicroPython Raspberry Pi and other single board computers. And I am not seeing the Blinka in the notes here, so... Oh, I found it. There was just some new sections added in the last one, so we got lost. This week we had three pull requests merged by three authors and two reviewers. There are currently six open pull requests amongst all the repositories. There were zero closed issues by zero people and two open by two people, leaving a net of 98 open issues. There were 13,862 Pi PI downloads last week and 11,314 Pi Wheels downloads in last month. And we are currently at 106 ports. And that's it. Thanks, Melissa. All right, and that's it for the state of CircuitPython libraries in Blinka. Next up, we have Huck Reports. This is the first of two round robins where I will start and then we'll go down the list to folks listed in the note stock. Tends to be alphabetical, but doesn't always have to be. We'll just go by the note stock ordering. Anybody who's marked lurking or text only, I will read off. Otherwise, I will call on you when it's your time. Huck Reports is a chance to say thank you to folks in the community for the cool work that they've been doing, the awesome work or helpful work. It's both nice to recognize folks and also reinforce as a community what we value. So I will start. First, a hug to FurBrain for a PR adding memory map support to NRF. I just merged that this morning. Huck Reports to Jeff, Jepler for awesome SynthIO improvements. I'm excited to hear people get their 8-bit bleeps on, I guess. And then retroactively Ian from Dangerous Prototypes, who created the Bus Pirate, both for Ian and everybody who's worked on Bus Pirate. Really thank you, huge thank you to being liberally licensing everything. It's all like public domain and it's great to be able to reference code and not worry if I'm copying it over too much. So that's a neat project and I'm happy that they did that in the past. All right, next up, I'll read from AnikData, who says, Huck Reports to Naradok to Shippu and FOMIGuy for helping me get builds and debug builds going again after a year of hiatus. Next up from DJ Devon3, we have Huck to FOMIGuy for the streams this week and everyone in the Help With Hardware Discord channel for ideas on how to pivot from a PCB design fail into a PCB design win. And with that, let's go to FOMIGuy. All right, thanks Scott. Huck Reports for me this week. Thank you to TechTrick for input and conversation around some typing details to another Huck Report again for Michael Pokusa, who has submitted even more improvements for HTTP server library over the past weekend. Huck Report for AskPatrickW for sharing the WLED project on Discord, which I had not heard of and looks to be like a pretty cool thing. To Jose Davide, thank you for some feedback on a PR for the DisplayButton library and then a group hug for everybody. Thanks. Thanks FOMIGuy. Next, let's hear from Jeppler. Where is that pesky mute button? So I want to start off with a group hug. Hugs to Scott and Liz for helpful advice about audio synthesis. And finally to JP and Todd Bot for testing on the Cynthia Elpo request. That's what I got. Thanks Jeppler. Next up, I have notes from Jose Davide, who says, Huck Report to FOMIGuy for all of the PR reviews. Next up is Katny. All right. So Huck Report to Jeff for a lovely chat last week. Also another Huck Report to Jeff for offering to help me with an issue in my code that is potentially related to the core. Thanks to Naradok for some help over the weekend with my code. I was trying to do a couple things that were baffling me and I received some excellent answers there. To Alec for some great chats as well. To Spavlot on Discord for sending me some feedback related to support regarding the Adafruit IO web UI causing some issues for users. I will be passing that on this week, but I really appreciate it because obviously we're not always providing the support on Discord. It's the helpers that are doing a lot of that. And so feedback regarding support issues can really help us. And then to FOMIGuy for keeping up with all the PyCon PRs and a group hug. Thanks Katny. All right. Next up is Maker Melissa. Hello. I wanted to give a hug to everyone who submitted the boards lately. I've been adding new boards and realizing how many new ones there were added recently and a group of different notes. Thanks Melissa. Next I have notes from Mark, AKA Gameboy. 21 says hug to Paul Cutler, Mad Bajor, C Grover for recommendations on MIDI controllers. And next up is Paul Cutler. Thanks Scott. I have a hug report for Spavlot for all their help and Discord. Especially showing incredible patients helping one user over multiple days. And a group hug for everyone else. Thanks. Thanks Paul. All right. Next up I have two more text only. So I'll read those off. First from Todd Bot, a hug report to Jepler for SynthIO improvements. And next up we have notes from Tectric, who says hug report to Hier effect, Gallagher, Guy Dupont and others from the Boston hardware meetup this weekend. It was awesome getting to meet everyone very excited for the next one. A hug report to Katny for great conversations over the last week and a group hug. And with that is hug reports. Next up is status updates. This has a similar format, but this time we want to hear about what you've been working on in the past week and what you plan on working on in the coming week. I'll start and then we'll go down the list and I'll read off text only is just like I did before. So first up, I spent most of the week working on Circuit Pirate, which is a circuit Python based re-implementation of the bus pirate serial interface. I also added a prompt toolkit circuit Python port. It's basically for making repels, which is really handy. It manages up arrows and entry editing. I'm gonna primarily work on that this week, but I do have a couple odds and ends that I'm thinking about. One is to, I fixed some of the displays that had the wrong byte ordering, but the SSD 1681 didn't get fixed because I didn't have the screens at the time. So I have them now. I should take an hour or two and get back to that. Speaking of ink, I also got the Pimeroni inky frame five inch, which is a very awesome all-in-one board that has a PicoW soldered down. It's staring at me and I wanted to do a weather display on that. So that's something maybe I'll take a little time and do as well. And then in things I've ordered news, I ordered a Pico ice, which is an RP2040 plus an ice 40. So I've always wanted to do circuit Python and FPGAs and having an FPGA alongside circuit Python is pretty interesting. So we'll see when I find the time to actually poke around with that. But it should be on its way at some point soon. So I'm excited for that. Okay, let me read off DJ Devin threes update, who says, a workshop lamp PCBs arrived. Unfortunately, I mixed up diameter with radius during a design change and never noticed. Now I have a 19 inch ring instead of a 9.5 inch ring. Getting supplies this week to turn it into an illuminated lazy Susan. I 3D printed an FPV camera mount for an RC car. It's been a lot of fun to play with in the yard, learning a lot about RC lately in an attempt to shrink the sewer bot even further. I got a very slimmed down version of my offline weather station running on the feather RP2040 DVI. Unfortunately, when attempting to use it with the airlift feather wing for pulling online data ran into memory allocation issues. Same thing attempting to run GIF IO. There's not much RAM left after DVI gets through with it. It's a good start. Thank you to the developers working on this. It's cool to see circuit pipeline on an HDMI monitor. And maybe I'll tease that we have talked about a DVI feather wing. So it would be the reverse where you would treat the feather wing as a regular display. So you would have a second RP2040 just to do DVI and that would mean that you don't have to share memory with it. Anyway, I'm excited for that as well. Okay, let's go to FOMI guy. All right, over the past week or so I've been still doing quite a few PR reviews from the PyCon PRs. I think we are pretty well caught up. All the ones that are out there have been responded to and are awaiting changes or at this point are merged. There's loads and loads that have been merged. The remaining ones I think have been responded to. So if anybody listening to this does have a PR that's open that hasn't been responded to definitely let me or somebody know. I was also working on a more advanced HTTP server example last week. This uses the 14 by four segment feather wing as well as NeoPixel feather wing and allows the user to set what text will scroll across the segments as well as set the colors of the NeoPixels on the NeoPixel feather wing or you can set an animation if you want instead of individual colors. This was just kind of a project I didn't really have the specific use for but was interested in making. And now that I have kind of the concept of it working I actually am inspired to pull out the NeoPixel portion of it and try to make a more general standard ish rest API for interacting with NeoPixels and dot stars. So I'll work on that next. Something else that I did that kind of was tagged on to the side of that project was make it basically modify the library for the 14 by four segments to be able to support non blocking marquee text the existing functionality blocked but I need it of course to be non blocking so it can do the server the NeoPixels and everything else all at same time. This week I am going back through the GitHub PR pages and issues and things as well as some of the reports that Adabot spits out to tabulate stats and lists from PyCon related contributions. And I also have pegged on my notes over here to submit a change in the color sys library to make it match the CPython API more closely. And that's what I've got going on. Thanks. Thanks funny guy. Next up let's hear from jet jet blur. Can't decide whether I'm gonna say or use the name or your name. Go ahead Jeff. Oh that's fine. I do answer to vote. Right. So I've been working on Centio and the pull request the next pull request is ready to review like on a technical basis. So it adds tremolo and vibrato. It adds the ability to select a note in an arbitrary frequency and Hertz rather than just being confined to MIDI notes. That lets you build like in your Python code a frequency sweep which is pretty cool. I revamped some of the way that multiple notes when you're playing multiple notes how they are mixed together. You need to not like do arithmetic that wraps around past the 32 768 to negative numbers. That sounds bad. It's been a so before what I would do is like if there were six voices playing I'd just divide everything by six but then all of your individual notes ended up not being very loud. So one thing that I've tacked on to this pull request is a new algorithm for that. So people should look at it. I think it's pretty cool. My tests all sound good but your results may vary and I need to hear from you if it's bad. Next up for Centio we're gonna do at least one more kind of set of things. A noise wave form is missing so I haven't tried to synthesize a hi-hat or that kind of thing. And so supporting percussion would be good and then we also talked about doing filtering like a high pass or a low pass or a band pass and the tech for doing that is called an FIR and there's an FIR toolkit in the ARM SimSys that LeMore suggested I look at. Although we might want this to run on expressive chips so I'm not sure how that would affect it. Anyway, next up JP discovered trying to work on a demo last week for show and tell that MIDI in doesn't work in 8.1 beta with the Metro M7. I reproduced it and filed an issue. Liz offered to test on Pico to see if it's like board or port specific and I will at least bisect and figure out what pull request introduced the problem and if there's like a clear solution I might solve it. Based on internal discussions there are some maybe coming up things or longer term things once we start to look at nine and those could be merging Python 1.9 and looking at some kind of, I called it an IO and data processing block system. All right and my version number was wrong, it's 1.20. I don't know where that number came from. So this is like providing a better answer to the story of I want to pull in a block of data from a DAC and process it and then produce some kind of output to another system like a speaker, I2S, ADC but we'd like it to cover a range of use cases and kind of we talk about doing a block or a declarative system and the first step is just to sketch what would the API look like? What kind of program would you be able to write? What would it do? And then in fun news I'm recapping power supplies for my Xerox820 machine, which while I was using it last week gave out a big old puff of magic smoke. So I've got like, I think I've got all the caps that I want to replace desoldered from this board and then I'll be able to boot up the main unit again and see if it still works after the smoke came out. So that's what I'm up to, thank you. Awesome, thanks JetBlooder. All right, next up I've got notes from Jose DeVee. Who says, sorry, time codes. Finally got some time to install Circuit Python and the Lilligo watch that Nerodoc added support to. Learned a lot of stuff including web workflow. Not sure who was involved in that but I think it's great. Worked in the Bosch BMA423 Circuit Python support as this is the accelerometer that the Lilligo has. I need to read some more data sheets to add the step counting feature. Added Circuit Python support for the LPS-228 and the BMP-581 sensors. Next up, let's hear from Katny. Hello again. So last week the Feather RP2040 RFM95 guide went into moderation. The guide is quite nearly a direct copy of the RFM69 the images have obviously been updated because the boards themselves look different but all the pinouts are the same and the only thing that differs really is the radio example because obviously the RFM95 has a different library than the RFM69 but the code is almost identical and you just replace the libraries. So if you got an RFM95 and you're wondering what to do right this second before that guide comes out the RFM69 guide will help you. And then on Friday and over the weekend I worked on a project that I am doing as a collaboration with NOAA and that is a canary nightlight. The code uses Wi-Fi to get time and it was also requested that it blink red if the internet connection is down not necessarily the Wi-Fi but the connection out and that is where I ran into a possible issue in the core. I think my code is actually running at the moment pretty consistently but it was definitely failing very consistently on Friday and Saturday. So this week I'm gonna work with Jeff to maybe sort out this bug if and or where it exists. I need to moderate a guide from Liz that was finished up last week. There is a feather every 20, 40 USB host guide that was moderated by Lamor and she found some base issues in it and it is almost, those issues are copy paste from my previous guides, my previous, the recent feather Rp2040 guides. So I am going to be going back through all of my recent guides and fixing that stuff up so that we're not copy pasting that into the future. And then I have a short list of various guide updates that need to be done. Those are shorter things than a whole guide obviously because the guide already exists and I just need to run updates. But I want to get the, and I also didn't write this down but I want to get the canary code done solid and ready to go this week. So that's what I've got. Thanks, Catney. All right, next up is, let's hear from maker Melissa. Hello, last week I worked on Ketching Up on Messages and I started working on a PR for a cloud project that I'm working on with Erin which is a stergop that would generate unlimited stories for you but I was running into some issues in that. I added a large batch of new Stryka Python boards and if you blink the boards to StrykaPython.org and I also did a big merge into the code editor for Stryka Python and ended up finding an issue and fixing that so it should be working now. This week I am adding a bunch more Blinka boards and I'm finishing up my PR for my cloud project and then I'll work on some GitHub issues that I've been putting off that are related to platform detect Blinka in the Raspberry and installation groups and that's for Matt. Thanks, Melissa. All right, next up is Paul Cutler. Thanks, Scott. There's a new episode of the Stryka Python show podcast out today with Ben Shockley. Ben is the creator of the Mini Fig boards, little Lego mini figure sized dev boards which are just adorable. And then all this talk of Synth.io has rekindled my interest in playing music so I went out and bought a MIDI keyboard controller that arrived this weekend. I took piano lessons for nine years as a kid so I'm curious to see how rusty I really am. That's all I got, thanks. Thanks, Paul. All right, and lastly we've got two text-only folks so I'll read those off. First is from ToddBot who says, Synth.io Algorithmic Composition Fund with LFOs and AMP Envelope on the QDPI RP2040. The YouTube video there that I'm holding myself back and not watching right now. ToddBot noticed that Bus.io UART on Circa Python 8.1 MetroM7 requires timeout equals 0.0001 parameter, otherwise you are 80 fruit MIDI fails to receive working on creating a succinct bug report to characterize the issue. And side note for me, that sounds like exactly what I'm procrastinating on testing by doing the circuit pirate stuff. So that'll be super helpful for me, thank you, ToddBot. Not circuit Python related, Todd says, but Arduino version of the PicoStep sequencer now has rock solid syncing and sourcing MIDI clock and USB MIDI to serial MIDI forwarding. All right, and last up we've got notes from Tectric who says, last week my parents were in town so nothing in the world of circuit Python. And this week taking a look at my backlog of assigned issues and starting to tackle them. And that's it for status updates, thank you all. The fifth and final section is in the weeds. This is a chance for any for longer form discussions that we've got. So if you have any topics, there are a few already, so you have a chance to add more if you have them. Just stick your username and then a brief blurb of what you'd like to talk about. So first up we'll hand it over to FOMI guy to introduce their topic. All right, thanks Scott. I actually have two that are both kind of related to the typing changes that we are in the process doing across the libraries. The first one is around the usage of assert lines that basically assert a thing is not none. That's the specific use case that came up. Basically these fields on a class get set to none inside of a constructor. And then later on in a different function or property they get set to a real value and then used for something. And I don't know the exact warning or error that comes out of it, but from what I understand MyPy perhaps with strict or perhaps with the default configuration I need to look further into that bit of it, like what exactly it says and how to get it to say it. But MyPy flags these cases as problematic in some way. And one of the ways that you can get rid of that error for MyPy is by adding these assert lines that say like assert this thing is not none. I wanted to raise the question to the larger team though, because unlike the typing annotations I think those assert lines will actually end up consuming space inside the MPY file. Now it's obviously not that much depending on how many of those lines are in a particular file or whatever but I figured it was worth thinking about since it is more than zero at least as far as I understand it. Or unless if MyPy actually cuts those out which is maybe something else to test that goes along side of this. If they get cut out somewhere kind of like the annotations then it's pretty much a non-issue. So that's kind of the first one. I guess I can either open up the floor to see if anybody has ideas around that or I can do the second one which is also kind of typing related but not specific to this. Let's talk about the first one first. Okay. Yeah, I can jump in on that. I think I may have advised this person to do it this way. I'm not sure. I did advise somebody to put in an assert. So yeah, it's true that that will take some byte codes and so it will take more storage. A possible alternative for this one is I'm not sure why the constructor couldn't assign it an empty list and then it could give a non-optional type. So that would be another alternative. Okay, yeah, I like that. So that line 322 would assign it an empty list instead of none. And I don't know that there's anywhere else within there that like it's tested for none. I didn't see that but I didn't look through the whole file but that's a possibility. Okay, yeah, I do definitely like that. Like that solution better. I had not considered changing it up in a knit. But yeah, if we do some kind of, as long as we set it to whatever the final type will be, it can be empty but that should make my pie happy as well. So I'll look into that specific one in that library and try the change that way and make sure that everything else still works fine but if so then I think that's probably the way to go and in which case it won't really need the asserts because my pie should be able to figure it out. So thank you to Jeff for the report on that. I think that is the best solution. I just, I also want to reiterate, I think spending code size for better error messages through argument checking is worth it usually and asserts are one way of doing that although they don't provide great error messages. So I would say if assert really is the right thing that you want to use then use it and we'll deal with the size stuff later. Okay. The other one is around an alias for colors. So we have inside the circuit Python typing library, we have an alias, I forget the exact name of it but it's essentially represents a color either in hex color format, so an integer or in the tuple format which some of the libraries take in particular like NeoPixels and dot stars and things you can set them to either color format. We have a bunch of places in display IO that also have similar constraints around colors like they can either be int with hex color or they can be tuple with ints inside zero to 255. So is it bad is it a faux pas to use that existing type alias that is inside a file called led.py even though it represents the types we need is it bad to use that for display IO? And if so, would it make sense to create a more generic color type somewhere else inside typing further up the chain so that we could use that for display IO as well? Or would it make sense to make a display IO specific one or something that's like pixel color as opposed to led color? Or is it not worth messing with alias and then just keep the union of tuple and ints? Is there kind of the options that came to mind at me to me at least for different ways we could do those colors? I think generally if you wanna use something broader it should be moved like more generic kind of like you're suggesting. Okay. I'm not sure it makes sense to have the like led color definition overlap with display IO's version but the other place to put it is like since display IO is a core API maybe it's maybe that's the best place to put it as well. Like you want the type really where the interface is defined I think so. Maybe. If we declare, can you declare a type in the, well, I don't actually know. I don't know the details of the typing stuff but. Okay. I will check into that. I think all of the ones where we've added alias so far end up in that circuPython typing library. And before that we were doing some I think maybe in Blinko or some similar types of things but they're all in typing now. I'll see if there's a way I can go in the core like maybe this if the stubs get pulled into there somehow I'm not sure. Yeah, cause it would be good for the stubs to have those types as well then. Like if we wanna standardize it we'd like to standardize the stubs to it too. Okay. I will plan on submitting like a PR that makes it more generic one of those and look into if it can be added in the core where it shows up in the docs. Okay. Yeah. And we just have to make sure that that's actually the types. I'm not sure where display.io takes tuples for example but maybe we do. It's been a long time. Well yeah, not display.io core but display button and I think ultimately display shape is the one where it comes from our shapes. I think it's plural. Yeah, so maybe if it's a library only then maybe circuit by then typing is where it goes. I don't know. Okay. I think that was it for mine. Thank you for everyone with feedback. Thank you, foamy guy. All right, next up Carter has a question or a topic. Yes, question. Do related to a weird behavior that's RP2040 specific and I've linked to a pull request there that kind of kicked this off. Apparently I think Liz is working with Noe and Pedro to work on something using the Noon Chuck and it wasn't admitting with the RP2040 and she's got a pull request that fixes it but I looked into it a little further and I noticed it's kind of just a combination of the RP2040 is doing something specific and the third party Noon Chuck doesn't like it whereas the official Noon Chuck is okay with it and keeps on rocking and rolling. And I'm just wondering if there's any, if anyone knows like RP2040 specific internals as to why that behavior is happening and so that we could possibly make the fix in the Noon Chuck library a little more elegant. And I guess let me... Didn't Jeff reply on this? Jeff responded with some possible helpful info and I appreciate that that it was related to switching to software to bit bang to get this pushed out. Yeah. And that's, I mean, it's kind of, if it's that, that's great but I didn't really finish off like how I could use that as a workaround. And so then I just posted an image there. It's like, why is it? So what, if we're doing software bit bang, that's great but the big question is like why that gap there? I mean, I would look at the bit bang code. But I guess what I would also say is like to narrow it down whether it's a core issue or an issue with the library, like I would try it on a different device that a different port that can manage to do the zero length rights. Yes, did that. So I did all this on an M4 and there's no gap like that and it works great. Yeah. And both Noon Chucks are super happy and work fine. So this is a specific to RP2040. You think almost millisecond gap there is the problem. It seems to me, yeah. Cause the other thing is if you just do this a second time, it's fine for whatever reason. What do you mean if you do? Yeah, the third party Noon Chuck is okay. It's kind of like you just do this once at NAT and I don't think you can see in that image I post but it's it's it's snacking there. If you do it the second time, it acts and you're okay. And from there on out, it's totally happy. Whereas the We Noon Chuck on the very first time it looks exactly like that. It's got that gap and everything, but it acts. It's like it's okay with that weirdness. So the second time you do the zero length, right? It doesn't have the gap? It doesn't, let me look. Is that in the PR notes? I guess what I'm thinking of is like if that's bit bang code is in flash, it's going to slow it down the first time it's used, which could explain the gap. That's possibly in what I dumped in Discord. Like I don't think it's doing any switching. Oh, okay. So it's not in the second one. The gap's not. Yeah. Yeah, so that would be my guess. That would be my guess why is that it's a function of there's some flash transaction happening there to load the code, which is unfortunate. Like between the start bit and the rest though. Interesting. Yeah. So well, do you think this is something that's worth digging in further in terms of possibly being a weird core issue? I've got a lot of other things out there may start acting weird when that happens. I mean, I feel like we would have found it. Yeah. Cause like this is how we're doing the scan, right? I think this is how we scan for devices. Yeah, exactly. Yeah. This is the I2C device discovery, but it's essentially the I2C scan is the exact same thing just through all the addresses. Yeah. I would open a core issue for sure and say that maybe in BitBang.io for this, we wanna preload from before we run it. Like, I think there are, like we could run a loop that basically loads the code into the cache before we run it. I don't think we wanna stick it in RAM forever, which would also solve that problem. But then that's like literally like bytes out of the circuit pipe and heap that we've gotta spend for something that is probably not, well, maybe it's run quite kind of often, but I don't know, I'd make a core issue and maybe we can figure out what's happening between those two things. And we'll have a documentation of what was done. Yeah. Yeah, that would be it. Whatever it is, whatever it is. It's weird, it's weird, but yeah, like that's almost a millisecond, that's a long time. Yeah. What else is weird is like, why is one okay with it and one not okay with it? But that has nothing to do with Circuit Python. Yeah, it could be, like, however they implemented iSquared C and how tolerant it is. Exactly, because it has some other weird quirks too. Yeah, interesting. Okay, thanks. I'll look into the source code a little bit just in case maybe I can find something, but I will open a core issue also. Yeah, one thing I do to debug this sort of stuff is like have a third pin that you can set from in the BitBank code, kind of just as a way for you to align what you're seeing in the output and what you think the code is can be helpful. Yeah, in terms of a precise timing. Yeah, like if there's a bunch of code that happens between the start bit and the first byte, maybe that's your suspect thing or maybe somehow there's a run background task call there that shouldn't be. Okay, okay. Yeah, Milisek is a long time. Yeah. Okay, thanks, that's all I got. Thanks, Carter. All right, next up, we have topics from maker Melissa. Hello, so I have a question about Blink in here. So Blink as boards are added, there isn't really a great way for users to know which OS the boards were tested with when they were added. So for board, like the Raspberry Pi, this is pretty easy, but for instance, some of the orange pi boards were originally added with Armbian, but there's at least one other distro of Debian that runs on it now. I was considering adding a markdown document that people can add to, but wondered if there's any other ideas for that. My first instinct is to put it on the CircuitPython.org pages. Oh, okay, that's an idea. Because that's, I assume, where people are discovering that it supports it, but maybe that's not true. Okay, that's actually a good idea. I could add that on field on it. Yeah. How about, go ahead, tell us. How about, don't you have versions of CircuitPython and put in parentheses, which OS? This is for Blinken at CircuitPython. Yeah, I'm talking about Blinken. Oh, okay, I'm sorry. Go ahead. No, no, when you're loading CircuitPython, it's like the library? The Blinken library. How does it, you know, it's two separate board detects entries. One for Armbian and one for Debian. So it knows which one. Yeah. I mean, that's what we're looking at doing is improving it so that it can work on both. But I mean, just kind of as a way when I'm not aware like some new OS has been added and works on the board, for instance. Yeah, and somebody wants to use it, use Blinken with it. Exactly. I've run into that problem, but you know, I know enough to go looking to see what versions, what OS's are available when that happens. But not everybody is willing or knows how to do that. Yeah, okay. I do like the idea of adding it to CircuitPython.org. Yeah, but that, yeah, that doesn't save you for the people that don't look there. And it also doesn't save me from the people who add the board. But I guess that could be added into the pull request. Yeah, I do like Charles's idea of like having board detect kind of like make it explicit. No, then if they try to use Blinka on an OS that is not known to work, it will say, can't do that. Well, that's essentially what it does now. But it's like, which one should they use is kind of. Yeah. Right, like if they want to get around that check. That suggestion can only be made on CircuitPython.org. Okay. And then Catney mentioned having documentation that points to CircuitPython.org. So that could be added to like the Blinka Readme. Yeah, I want, yeah. I forget how it's instantiated, but I wonder if you could say like by default check that the distribution's right and fail if it's not. And then allow them to add a flag that says ignore distribution check or something. Well, I like to not limit it because sometimes it works on the new distribution without any intervention from us, but then sometimes like somebody will try something and even though we claim it works, we're not telling them which OS that they're. Okay, so that is kind of like CircuitPython.org is the source of like support truth. Yeah. The policy, it's more of a policy thing than a. I don't think it's a bug necessarily. I think it's just that you have to be, have a way to tell people, you know, if they want to know what the solution is. Right. Okay, well, I think CircuitPython.org is the place I would put it. Okay. Is it like, did you check here? Like, are there any notes that you have to be aware of? Right, right. Okay, so I'm thinking like having the readme point to CircuitPython.org to mention to check which OS and then adding it to the CircuitPython.org. And also making it so when people add a new poll request for a board, it can be, it can ask them which OS they added it on so that it's easier to read to you. Yeah. Yeah, make sure that that's something that they mentioned for sure. Yeah. All right. I think that's it. Thank you. Thanks, Melissa. Okay, next up we have the wrap up. So I will take another time code and hit the right button. So this has been the CircuitPython Weekly for May 8th, 2023. Thank you for everyone who participated. If you want to support Adafruit and CircuitPython and those of us who work on CircuitPython, 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. It will also be featured in the Python for microcontrollers newsletter. Visit AdafruitDaily.com to subscribe to our podcast The next meeting will be held next Monday, as usual at 2 p.m. Eastern, 11 a.m. Pacific. This meeting is held on the Adafruit Discord, which you can join by going to adafru.it slash discord. To be notified about the meeting and any changes to the time or day, you can ask to be added to the at CircuitPythonNESIS role on the Adafruit Discord. With that, we hope to see you all next week. Have a great week and thanks for stopping by. Thanks, everyone.