(energetic electronic music)

Hello and welcome to the first Coding with Blocks in VEXcode Live Session. My name is Lauren and I'm very excited for you to be joining me tonight. I have a lot of really exciting things to show you. If this is your first time joining a Live Session, let me just talk about how it's actually going to run before we dive into all of my different examples.

We do have another person from our Education Team in the chat. If you have any questions as I'm talking, please feel free to put those questions in the chat and either Audrey will answer them in the chat or we can follow up with you after the session in a PD+ thread. This session will be recorded. If there's anything that you have questions about during the session or maybe after if you're still processing it, again, please feel free to put any comments, questions in the thread in our PD+ community so that we can discuss different things there.

I will have a slideshow for this particular session as well as some examples that I made here for my IQ base bot in VEXcode IQ. I will be sharing both the slides and all of those different projects that I created in our thread in PD+ after the session, as well as the recording. So you will have access to all of those materials afterwards, so don't feel like you have to hastily build a project or anything as we're doing the session. I will give you all of that once this session is completed.

All right, that being said, let's talk about what we're going to do today and a little bit overall what this type of session is for. I will be showing a bunch of examples today in VEXcode IQ, however, you can take any of the concepts that I'm going to show you today and apply them in VR, V5, really all over the different continuums and platforms that we have. I am just using IQ for this particular example, but again, please feel free, you can use this for any platform or multiple platforms that you're using.

All right. Now diving into the concept that we're actually going to look at today or the problem that we are going to try and solve. Okay, let's talk about this problem. Specifically, we know that you can manipulate a robot, multiple different types of robots. Maybe I have different mechanisms or manipulators like an arm, a claw, an intake, something else, maybe I have different sensors like a Touch LED, a Bumper switch, optical sensor, and maybe I'm trying to manipulate some of these mechanisms such as my arm, claw, intake, or maybe something like a lift that uses a motor group.

But I want to control multiple mechanisms within the same program. But I know that my device configuration in VEXcode is limited and it's limited and we'll take a look at this when we actually dive into VEXcode itself, but it's limited in the way that, number one, I am limited in the number of buttons that I can use and also, I need at least two buttons per motor or motor group. That means, for example, let's say I'm trying to manipulate something, maybe a claw or arm, in order to open and close the claw or arm, I need to have one button to open it and the other to close it or one button to turn a mechanism on and the other button to turn the mechanism off. Same thing with really any of the buttons that you see here on the controller, maybe the F Up and F Down, one to turn it off and on and the other to do the same there. So again, at least two buttons for one mechanism.

Now as you can see, if there was a way in order for me to only use one button to turn a mechanism on or off or maybe open and close the claw, that would free up a lot of other buttons that I could potentially use on my controller. So how are we going to do this? We are going to create a toggle switch.

Now I'm calling it a toggle switch and not a specific switch like a Bumper switch or a Touch LED because there are many different hardware components in VEXcode and VEX in general that I could use to emulate a toggle switch. I can use buttons on my controller, a Bumper Switch, a Touch LED, or a limit switch. There are numerous options in the VEX ecosystem that I could use to emulate a toggle switch.

A toggle switch is very similar to a light switch or a light button, where I push a button to turn something on and push the same button to turn it off. It's similar to using a TV controller, where the same button turns the TV on and off. This is optimization, as I don't have to use two buttons to turn the TV on and off; I can do it with the same button. That's exactly what we are trying to make here.

Now, this toggle switch that we're going to make can do many different things. It may start and stop my Drivetrain, turn my Touch LED on and off, or control my claw to open and close it. There are lots of different things, motor groups, lifts, and many mechanisms that I can control using a toggle switch.

We're going to dive into the states of the toggle switch, what it means to be on and off. Also, maybe we're not turning something on and off; maybe I'm toggling my Touch LED between two colors. There are lots of different things that I can see here.

My favorite part of this entire concept is that there are many ways to achieve this. There are lots of different ways to write the same outcome in code, and we're going to take a look at many different examples that I created, what they mean, and how some may be more advantageous in certain situations compared to others.

Let's take a look at this first example.

Now, this first example, let's see what I'm actually trying to get my robot to do. The goal here is to make this a little smaller for one second and bring my robot into view. The goal with example one is when I touch my Touch LED, it's going to oscillate between green and off or no color. When the Touch LED is green, my robot's going to drive forward. When the Touch LED is pressed again or the color is off, my robot's going to stop driving. I'm using this as a button to start and stop the Drivetrain, but I'm also going to get visual feedback as well. When the Drivetrain is actively running or driving forward, this is going to be green, and when I press it again and this is off or there's no color, my drivetrain will stop.

Why is this an advantage? Well, I am just doing this with my Touch LED, but I could use the same logic in this code and apply it to one of the buttons on my controller. Maybe I want to use just one button to toggle the drivetrain on and off. There are lots of different variations, but that's what this first example is going to show us.

So let's talk about the code here. This is my first example that I'm going to show you because it's the simplest. This goes through, and the logic just makes sense from top to bottom, and we're going to talk about why that is. When I start at the very top of my forever loop, why am I in a forever loop? I'm in a forever loop because I need to continuously check when that Touch LED is being pressed. That's why we have this in a forever loop.

Now let's go through each of the blocks here. I'm going to wait; my project is going to wait or not execute anything until that Touch LED is pressed. When it's pressed for the first time, I'm going to set my Touch LED to green, and the robot's going to start driving forward, okay?

The robot's gonna continue to drive forward until I am not pressing the Touch LED anymore. Basically, when I take my finger off of the Touch LED, it's gonna continue to drive forward until I push it again. When I push the Touch LED a second time, it's going to set the Touch LED color to none or turn it off and then stop the Drivetrain from continuing, essentially turning my drivetrain off or stopping it from moving. I'm then gonna wait until my finger is off of the Touch LED again, and the cycle continues. It's basically going to wait until I push it again.

Now let's actually see what this looks like in action.

(robot beeping)

All right, so I'm gonna run this, make some room. Okay. Now, as you can see, this is exactly what's happening. The Wait until, right. It's waiting until I push this for the first time. When I push that for the first time, the Touch LED is gonna turn green and my robot's gonna start driving forward. It's gonna continue to do that until I take my finger off the Touch LED and press it again. This will then turn red and the robot will stop. The Drivetrain will stop.

(servo motors whirring)

It's driving. Stop. You can see when I pushed it again to stop, the Touch LED turned off.

(servo motor whirring)

(servo motor whirring)

And that's gonna continue over and over and over again. Really forever.

(servo motor whirring)

Because I have it in a forever loop. Now, let's talk about some reasons why I wouldn't use this particular example. We talked before about the project flow or really that, that Wait until block kind of stops my project, as in no other behaviors or actions will be executed until that Wait until block is true or until the condition in the wait until block, which is the Touch LED being pressed, happens. So if I'm trying to put other things in my project, maybe the claw opening and closing, the arm lifting up and down, I have an intake. Basically, if I wanna include any other behaviors into the project other than what you see here, it's going to be very complicated, because those behaviors won't execute until I go through all of these different Wait untils.

So really the advantage for this example is, yes, it is the simplest, it's the easiest to create and it makes sense from a top-down view. However, if I want to add more complicated code or behaviors, this can get very complicated very fast, because of the limitations of the project flow, if that makes sense. So if I added more blocks to the bottom as we can see it here actually in VEXcode, if I wanted to add information down here about the claw or arm for example, I would get stuck up here and here in the Wait until, and those wouldn't be executed until that happens. So this is great for simple programs, if all I wanna do is turn the Drivetrain on and off or maybe turn the Touch LED on and off, that's fantastic. But also, as you can imagine, because project flow goes from top to bottom, if this became very large or I had a lot of blocks in there, you could also see that block execution would start to get very slow, because I'd have to go through all these other blocks at the top before I got to the other blocks at the bottom. So again, great example, if I have only a little bit of code, goes through execution very quickly, and it's easy to create.

Let's look at the next example, example number two. First thing that's different is we have two hat blocks, so two event blocks at the very top here. You can see the first one is my When started on the left and my second is that When bumper on the right. But before we dive into that, let's talk about what this project is actually going to do. When I push the Bumper switch on my robot, it's going to toggle the Touch LED between two colors, red and green.

Thank you for following along with this demonstration. I hope it provided valuable insights into the programming process and the considerations involved in creating efficient and functional robot behaviors.

When I push it again, it's gonna turn green and so on and so forth. You can change out these behaviors. For example, maybe when I push the Bumper, the Drivetrain starts and stops, et cetera. But what we're looking at here is not necessarily the behaviors but the way that the project is actually created and the project flow.

All right. That being said, let's get back into these hat blocks at the top here. What's the difference between the When started and the When bumper, and why do I have two of them? Well, the When started on the left is really used for initialization, if you will, or this is going to run as soon as I start my project. So as soon as I hit run on my project, it's gonna set my variable here to false and it's gonna turn the Touch LED red.

Now differently, with the When bumper over here on the right, that's not going to execute until the Bumper is pressed. So if I start the project and wait two minutes, the Touch LED is still going to be red, because I haven't done anything with that second stack yet, because it's not going to execute until the Bumper is actually pressed. So that's the difference between the two hat blocks at the top. This When started is going to run immediately when the project is started. Again, this is used for initialization.

What is initialization? That's when I start my project, basically setting anything that needs to be set before I talk about the rest of the project execution. Let's dive into that a little bit more. What does that mean? Well, looking at the project flow for this particular project, I'm gonna open it in VEXcode.

Now let's see what's happening here. I have a Boolean variable, which is my bumperPressed. Boolean variables can only report true or false. As soon as the project starts, I'm gonna set my Bumper press variable to false and I'm gonna turn the Touch LED red. Okay? Why am I doing that? Because, again, this is false. So when I am thinking about this being executed, the right-hand side here, the When bumper, as soon as the Bumper is pressed, I'm going to go through and I'm going to see, okay, is my variable true or is my variable false?

If the variable's true, I'm gonna execute this first stack and change it to red. If my variable's false, I'm gonna set the Touch LED color to green and then swap my variable to true. So let's start from the very beginning. I start the project, we set the variable to false and my Touch LED is red. Okay? I press my Bumper for the very first time. I now have to check is my variable true or false? Well, it's false, because I set it to false in the initialization, so I jump down to the else portion. It's then going to set my Touch LED to green.

So this, again, only happens as soon as I push the Bumper. So now my Touch LED is green and I'm gonna set the variable now to true. Okay, the variable is now true. I push the Bumper again, what happens? I'm gonna check is my variable true or is my variable false? Well, the variable's now true, because I said it is true when I changed the Touch LED color to green. So because it's true, now it's gonna change to red and it's gonna set my variable to false.

All right, I push the Bumper again. What happens? Is it true or is it false? Well, it's false, because I just set it to false when it was red, so now it's gonna oscillate back to green. So you see, this left side, this When started, was really only used for that first pass through of the right stack there. Once that's finished, it's gonna oscillate between true and false.

Now this is hard to understand conceptually, so let's actually take a look at what this looks like on the robot.

(robot beeping)

Okay? Project's running. Soon as it's running, variable set to false, Touch LED is red, which is exactly what we have right here. Set bumper to false, my Touch LED is red. I'm gonna push the Bumper for the first time. I'm gonna check is my variable true or false?

Thank you for following along with this explanation. I hope it helps clarify how the project flow and initialization work in this context. If you have any questions or need further assistance, feel free to reach out.

Well, again, we already set it to false, so I'm gonna come down here to change it to green and then set my variable to true. As soon as I push this, the Touch LED should turn to green, and then we're gonna set the variable to true. Exactly what happens.

All right. I'm getting ready to push the Bumper again. When I go and push the Bumper again, is it true or is it false? Well, we just set it to true. Because it's true, it's gonna change my color to red and then again, set that variable to false. So when I push this, the Touch LED should turn red. Okay? That process goes over, and over, and over, and over again. It's now just going to oscillate between red and green, and you can imagine, I could also oscillate between on and off.

Okay? So when I'm talking about initialization, that's what I mean on that left side. I'm basically just setting the variable to what I want it to be so that I get my intended behavior when I press the Bumper for the first time.

Okay. Let's take a look at our next example. Example three. Very, very similar to the example that I just shared with you before. We have a Boolean variable. I am setting the initialization for that Boolean variable, setting it to false start. And as you can see there, I'm also setting my robot to stop driving at the very start.

Okay. Let's look at this example in VEXcode. Okay? Same logic here, except, let's take a look at the buttons we're pressing and the intended behaviors. The button that we're pressing here is no longer the Bumper, it's now the F Up button on my controller. Now what's going to happen? Well, when I oscillate between the F Up button, it's going to start my robot moving or the Drivetrain, and then when I push the button again, it's gonna stop the robot from moving.

So very similar to our previous example when I pushed the Touch LED and it started and stopped the Drivetrain. It also changed the color of the Touch LED, but similar behaviors. However, the layout of this project flow is very, very similar to the previous example that we just saw. So here I have my button press, my initialization here. I set that Boolean variable to false and the robot is not driving. I then push the controller button for the first time. If it's true, it's gonna run the first stack or the first set. If it's false, it's gonna run what's in the else branch here of this conditional.

Well, I just set it to false in the initialization. So as soon as the button is pressed, we're gonna jump down here to the else condition, the robot is gonna start driving forward, and then I'm gonna set my variable to true. Okay. The robot's driving, the robot's driving, and remember, this only executes when the button is pressed, so nothing changes. The robot is still driving. The variable is still set to true until I push the button again.

Okay, I push the button a second time, is it true or is it false? Well, it's true, because I just set it to true. So this first stack runs, the robot stops driving, and then I set my variable to false. The robot is now not moving and remains not moving until I push the button again. When I push the button again, is it true or is it false? Well, I just set it to false. We're down here at the else stack and you can see that's gonna oscillate between the two.

Let's see what this actually looks like. Make sure my controller's paired first before we do anything else. Okay, it's paired. I'm gonna keep this here so you can see. I'm using the F Up button by the way, so that you can watch me press it and see the behavior there. Okay, project's running. Again, nothing happens until I push the button. I'm gonna push the button, the robot's gonna start driving. I'm gonna push the button again, the robot's gonna stop driving.

(servo motors whirring)

Okay. So you can see, again, very, very similar behaviors as the previous example there, going through the same type of project flow.

Thank you for following along with this demonstration. If you have any questions or need further clarification, feel free to reach out.

Happy coding!

(servo motors whirring)

Nothing happens until I actually push the button a first and second time. Okay. So what's really nice about viewing these different examples is that you can see a lot of different behaviors can be reached with the same similar type of example or project layout, really, project flow. The way that we're constructing these examples. I'm gonna go back through these two again, you can see side by side, they're very, very similar in the way that they are structured. Okay?

Okay. Now I just wanna mention one thing here about the controller. Going back to our very, very first couple of slides here. Why do I want to study this behavior? Why would I want to build a project like this? Again, now that we're actually getting into controller movements, you can see I can control the entire robot, starting and stopping, with just one button. Let's move on to our next example.

Okay. Now let's get a little bit more complex in our design of our project flow. Something that we've talked about in previous examples is that we were setting our Boolean variables to false in the beginning. Now, one thing is, is that all Boolean variables are actually set to false by default without that initialization. But if we were to do that in the last example, if I did not have this here, it would be really conceptual and a little bit hard to understand why my project flow is automatically jumping to the else condition or the false part of the condition if I didn't know that I already set that initialization to false.

Basically what I'm trying to say is that if we don't make that initialization visible, it may be hard to understand the project flow. However, that doesn't change the fact that all of the Boolean variables are actually set to false by default. So I don't need that initialization. In this example, I want to show you what the project flow looks like without that initialization. Okay?

This particular example, basically, I could have set that bumperPressed variable there to false in the beginning and it would've been very similar to some of our last examples. But in this particular example here, what's happening? I'm using the Bumper. When I push the Bumper button, it's going to oscillate between green and red on my Touch LED. So we've seen this example before in one of our earlier examples. It's just a different way to code the same behavior.

Again, getting into, there are numerous ways to code to get the same behavior, and this is an example of that. This code is more optimized. What do I mean by optimized? In order for code to be optimized, I can use less lines in the code. For example, if I'm doing text programming and less blocks if I'm doing block programming. That doesn't just mean that the less number of blocks, the more optimized it is, because we still need the behaviors to actually execute. However, when we're talking about streamlining, of course, if we have less blocks, we are optimizing the code. But as I mentioned before, the trade-off is that it's less explicit and it may be more difficult to actually understand what's happening.

Now you can use comments in VEXcode to offset this and put in what's actually happening and that could help. But again, there's just multiple different ways to code the same behavior. Okay, let's talk about this project flow. What's happening right here. We have this Set Bumper, which is basically the inversion of setting the Bumper to false and true. Let's see what this looks like in VEXcode. Okay.

All right. We know right off the bat that our Boolean variables are set to false, so that's why I didn't use the initialization on the left-hand side in the When started block. So the Bumper's already set to false. When the Bumper is pressed for the first time, what's going to happen? Well, as soon as I start the project, I know two things. Number one, the Touch LED is gonna glow red, and number two, the Bumper's already set to false.

Okay? This particular thing right here, this Set Bumper, what's happening? As soon as I push the Bumper for the first time, remember, it's already red, so I want it to turn green. When I push the Bumper for the first time, I'm gonna set the Bumper variable to not what the current variable is. So because the current variable is false, when I set it to not false, that means it's true. So this right here, setting the Bumper, the inversion, is making the Bumper variable true. Then I'm gonna check, is the Bumper true or is the Bumper false? Well, I just made it true. So it's gonna set the Touch LED color to green.

Now, very similarly to some of the other examples that we looked at, we're now just going to oscillate between the whole program, going back and forth between red and green and setting the variable between true and false. So we just had the Bumper is true, my Touch LED is green. It's gonna remain green until I push the button again. I push the button again. What happens? The inverse. It was true, now it's false. Turning the Touch LED red. I push the button again, what happens? Well, it was just false. It's now true because of the inverse and because it's true, it's gonna be green. On and on and on, setting the variable between true and false and setting the Touch LED between green and red.

Again, is there an advantage to doing this particular type of code layout? Well, it is more optimized, as I mentioned before, there's fewer blocks. But again, the trade-off is that it may be not as explicit, so it may be harder to understand the project flow. Both of them are correct. This one and the one we've seen in other examples are all totally valid ways to code the same behavior. Again, just depends on the intended outcome of what I'm trying to do.

Let's see what this looks like in action. Gonna make this just a little bit bigger for us.

(robot beeping)

Okay. Project started, what do we know? I know two things. Number one, the Touch LED is red and number two, that the Boolean variable or yes, the Boolean variable bumperPressed is already set to false. My Touch LED is red. What's going to happen, soon as I push the Bumper, I'm gonna set my variable to not false, which is true, which means it's gonna change the Bumper to green or I'm sorry, the Touch LED to green. It does. Okay, I'm getting ready to push the button again. I know that the variable is true, but because of the inversion, when I push the Bumper, again, it's going to be false, pushing me into the else part of the condition, setting the Touch LED to red. And it's basically gonna go back and forth between true and false in red and green every time I push the Bumper.

Okay? Again, more than one way to code the same behaviors. All right. Let's look at the last example and my personal favorite example, because I'm a math nerd and this one uses math. More specifically, it uses remainders, which is fantastic.

Okay? All right. Let's talk about what's going to happen in this particular example. This one is going to do the same exact behavior as the last example. When I push the Bumper switch, the Touch LED is gonna oscillate between red and green, Okay? However, when I made this example for the first time, because math is my passion and my background, my brain automatically went to using math in order to make the logic work. This is just another way to code the same behaviors. Now, I didn't use a Boolean variable in this particular example. I just used a regular variable.

Now let's talk about what I want to happen here or what's happening with this project flow. I wanted to alternate between the states of red and green or on and off, for example, and I was like, "How could I do that? How can I track that?" Well, if I could assign green to even numbers and red to odd numbers, then I could just oscillate my variable between even and odd numbers and that would change the state.

So instead of changing the state between true and false, I thought, "Well, let's change the state between even and odd numbers." Same type of logic, just a different way to present it.

When the project is started, I have this variable here called pressedNumber, and it's gonna start as one or odd. Anytime the number or the variable here is odd, the Touch LED is going to glow red, and every time the variable is even, the Touch LED is going to glow green.

Okay? Let's look at this in VEXcode to investigate a little bit further. Again, starting with my variable as one or odd. Right away, it's gonna continue through the rest of the execution, right? Because this is the when started block. That means I'm not waiting to push the Bumper at all. It's gonna run immediately when the project is started.

So immediately when the project is started, what happens? My variable is set to one or odd. I then go through and check the condition. If my variable is even, what does even mean in this code? Whenever I am dividing numbers, if whatever I'm dividing by comes out with a remainder of zero, for example, the number two, two is evenly divisible by two, which means that I have no remainder. Two divided by two is one so there's no remainder there.

Three divided by two, for example, because three is odd, there would be a remainder as in, two does not go into three evenly or an even number of times. Two goes into four an even number of times, but does not go into three or an even number of times, meaning that there would be a remainder. So what this is doing right here is it's saying, if there is no remainder, that means the number or the variable is even. If my variable is easily divisible by two, meaning that there is no remainder or the number is even, then I'm gonna turn my Touch LED to green.

So all even numbers are set to green on the Touch LED and all odd numbers are set to red. So again, let's start over. My variable's set to one, I go through my loop here, my condition. Is the number even? No. One is not even, there's a remainder. So I jump down to the else condition and I set my Touch LED to red.

Okay? Now this, again, is happening in the When started block, which means it's continuously running as soon as the project's started. So as soon as the project's started, my Touch LED is gonna set to red. Now this forever loop means that it's continuously checking. Is it even? Is it odd? Is it even? Is it odd? Is it even? Is it odd? Well, I didn't do anything to change the variable at all, so it's gonna remain odd or the Touch LED will remain red until the variable's changed.

I know you're all thinking, Lauren, when does the variable change? The variable changes when I press the Bumper. When the Bumper's pressed, I'm gonna change my variable by positive one, meaning I'm gonna increment up by one.

So let's run through this again. Soon as I start the project, odd number, it's gonna be red. When I push the Bumper switch, it's gonna change it up by one, meaning that my variable is now two. Because the variable's two, that means it's even. I'm gonna check through my condition and it's gonna turn green. And it's gonna remain green, because the number's still even until I push the Bumper again, changing it to odd, push it again, change it to even, push it again, change it to odd, et cetera.

Okay? Very, very similar behaviors to the true and false that we've seen in the prior examples, except now I'm associating that with even and odd. I know, if anybody else is a math nerd here with me, I'm sure you're just very excited. As excited as I am for this particular example.

(robot beeping)

Let's see what this actually looks like in action. Okay? Soon as the project's started, number's odd, Touch LED is red. Gonna push the Bumper, make the number even. Because the number is even or it has no remainder, Touch LED's gonna turn to green.

Okay. Still remaining green until, again, I change my variable.

The variable changes when I push the Bumper. It's now going to be three 'cause I'm incrementing it up again. Start it at one, change it to two, it turned green. I'm gonna press it again. It's now three, which is odd, red. Push it again, four, even. Five, odd. Six, even. Seven, odd. Eight even. Okay? And it'll continue to do that pretty much forever. All right?

That being said, I had five examples to go over with you. We went through all of those five examples. Now let's kind of talk about everything that we saw today. First thing, there are many, many ways to code the same behaviors. We saw what? Three examples, if not four. I think three examples, maybe four, that showed the difference between the Touch LED changing red and green using one button press. We coded those in completely different ways. Now, all of those are completely valid. However, it just depends on the certain situation and your outcome.

Maybe you want to use a little bit more advanced coding, you want to optimize a little bit more, use fewer blocks. You can absolutely do that. Maybe you're doing it for the first time and you want things to be very, very explicit and you wanna be able to read the blocks and understand project flow, also completely fine. Maybe you have a lot of blocks in your project, because you're controlling things like the Drivetrain, an intake, a flywheel, an arm and a claw, motor groups. Many different things. If your projects are getting very, very big or you're manipulating a lot of things at once, you may want to think about using some of the latter examples that we saw here with things like multiple events, and the events as in the When bumper or maybe the When touchLED, or even the When F Up button pressed events. Using those in multiple stacks, because as we mentioned earlier, those only run when the button's executed. That frees up project flow from the When started stack.

So you can see why there are infinite ways to code multiple behaviors, but it just depends on how I want to do that with the code that I'm using, how many manipulators I'm having, multiple situations. So I hope that all of this information was helpful in walking through different scenarios, the project flow for those particular scenarios, and when I would want to use certain types of code layout or code examples to do certain situations.

That being said, I know we're ending a little bit early here. I'm gonna leave one or two minutes for any questions that you guys have. If not, and you're thinking about them later, totally fine. You can put any of those in our thread in the PD+ Community, as I mentioned at the beginning of this Live Session, all of those examples, including my slides, I will post in our thread in the PD+ Community as well, so that you have access to them later. I'll just leave one second here to see if we have any questions.

Audrey, did we have any questions in the chat before I continue on? We did not. Okay. All right. I'll wrap it up here then, guys. I wanna let you off a little bit early here.

Thank you so much for joining me in the Coding with Blocks Live Session, and I can't wait to see you at the next session.

(energetic electronic music)