1. Review and demonstration (2+ minutes):
Begin by asking coders to talk with a neighbor for 30 seconds about something they learned last time; assess for general understanding of the practices and concepts from the previous project.

Explain that today we are going to create a music player app. Display and demonstrate the sample project (or your own remixed version).

Video: Project Preview (0:55)
Video: Lesson pacing (1:48)

This can include a full class demonstration or guided exploration in small groups or individually. For small group and individual explorations, you can use the videos and quick reference guides embedded within this lesson, and focus on facilitating 1-on-1 throughout the process.

Example review discussion questions:

• What’s something new you learned last time you coded?
  • Is there a new block or word you learned?
• What’s something you want to know more about?
• What’s something you could add or change to your previous project?
• What’s something that was easy/difficult about your previous project?

2. Discuss (3+ minutes):
Have coders talk with each other about music apps they use. Ask some of the following questions to guide a discussion: How can users interact with music apps? What kinds of features do their apps have? How might we recreate those features using code in Scratch?

After the discussion, coders will begin working on their project as a class, in small groups, or at their own pace.

Note: Discussions might include full class or small groups, or individual responses to discussion prompts. These discussions which ask coders to predict how a project might work, or think through how to create a project, are important aspects of learning to code. Not only does this process help coders think logically and creatively, but it does so without giving away the answer.

Example discussion questions:

• What would we need to know to make something like this in Scratch?
• What kind of blocks might we use?
• What else could you add or change in a project like this?
• What code from our previous projects might we use in a project like this?
• What kind of sprites might we see in a music app?
  • What kind of code might they have?

4. Add music and backdrops (10+ minutes):
2 minute demonstration
Review how to add music to the Stage, then explain we want to add a backdrop for each one of our songs. Demonstrate by adding in at least three music loops and backdrops. Review or introduce how to add text to each backdrop to display the song name somewhere on the backdrop.

8+ minute coding time and 1-on-1 facilitating
Give coders time to add in several music loops and backdrops to their Stage. Encourage peer-to-peer assistance and facilitate 1-on-1 as needed. Remind coders to have one backdrop for every song selected, because we will use the backdrops to trigger each song.

Video: Add music and backdrops (1:53)
Quick reference guide: Click here

Suggested questions:

• How does each backdrop match the music loops you’ve chosen?
• How can you let the user know what song they are listening to?

A note on using the “Coder Resources” with your class: Young coders may need a demonstration (and semi-frequent friendly reminders) for how to navigate a browser with multiple tabs. The reason why is because kids will have at least three tabs open while working on a project: 1) a tab for Scratch, 2) a tab for the Coder Resources walkthrough, and 3) a tab for the video/visual walkthrough for each step in the Coder Resources document. Demonstrate how to navigate between these three tabs and point out that coders will close the video/visual walkthrough once they complete that particular step of a project and open a new tab for the next step or extension. Although this may seem obvious for many adults, we recommend doing this demonstration the first time kids use the Coder Resources and as friendly reminders when needed.

5. Create a play and stop toggle (15+ minutes)
1+ minute review and explanation
Review how to create a custom button by having coders talk with a neighbor about how they used buttons in previous projects (use the resources on the right for review if needed).

Explain that we’re going to make a button that does two things instead of one. A button that switches between two states is called a toggle button. We want to toggle between turning our music player on and off with a single button.

2+ minute button creation
Give coders a couple of minutes to create a button that has two costumes: a “play” costume and a “stop” costume. Remind coders to name the costumes appropriately.

2-3+ minutes per step
Using the video or quick reference guide as a reference, demonstrate how to create a play and stop function for the Stage, program the new toggle button (with or without a boolean variable), and create a reset function.

Note: Although boolean variables are useful, they are not required to get this music player to work. However, they do make the program easier to understand at a glance, and could be used in more complicated music players. For example, functions that only trigger in other sprites (or the stage) if the music is playing.

Review Video: Create custom buttons (2:03)
Quick reference guide: Click here
Review Video: Code your buttons (2:41)
Quick reference guide: Click here

Video: Create a play and stop toggle (6:12)
Quick reference guide: Click here

Suggested questions:

• How can you change the appearance of your toggle button so a user knows if the music is playing just by looking at the button?
• What other buttons use a toggle?
• How might we randomize or reset buttons?

Potential unplugged lesson: You could engage in a discussion or lesson on conditionals (if/else statements) by working through one of the unplugged lessons on conditionals; for example, Conditionals with Cards.

6. Create next and previous song buttons (15+ minutes)
5+ minute reverse engineering
Display how the next and previous song buttons work in the example project. Ask coders if they can figure out how to create their own buttons. Facilitate by walking around and asking guiding questions.

3+ minute button creation
Using the video or quick reference guide as a reference, demonstrate how to create a next and previous song button with appropriate functions. Make sure to call the “Next song” function when the “Play” function ends, so the music cycles to the next song when completed. (note: if coders use start sound blocks in the “Play” function and not play sound until done, it will create a recursive loop that repeatedly switches and plays each song)

4+ minute application and exploration
Encourage coders to try something similar, and leave your code up on display while they work. Facilitate by walking around and asking questions about how coders might change their code so it’s not the same as yours.

Video: Create next and previous song buttons (3:45)
Quick reference guide: Click here

Alternative suggestion: If reverse engineering is too difficult for the coders you work with, you could display the source code and have coders predict what will happen.

Suggested questions:

• If our song numer is the backdrop number, how do we switch songs? (changing the backdrop number and triggering the “Play” function again)
• Are these buttons toggle buttons? (no)
  • Why wouldn’t we want to make them toggle buttons? (Because we might want to skip several songs instead of switching between two songs back and forth)
• How could you make the music stop when it finishes the final song? (We could use a “if” block to only broadcast the “next song” if it’s not on the last song; this example has ten songs)

7. Indicate a button is pressed - review or reverse engineering (10+ minutes):
If you’ve already introduced the following concept, simply spend a few minutes asking coders how they might use the concept in each of their projects. Otherwise, I suggest the following process for introducing how to do the following in a project.

1+ minute intro demonstration
Review the following example:

• Video: Indicate a button is pressed (2:55)
  • Quick reference guide

4+ minute reverse engineering and peer-to-peer coaching
Ask coders to see if they can figure out how to use their code blocks to create an algorithm that makes a sprite do something similar to what was demonstrated. Facilitate by walking around and asking guiding questions.

1+ minute explanation demonstration
If coders figured out how to get their sprite to do something similar, have them document in their journal, share with a partner, or have a volunteer show the class their code and thought processes that led to the code. Otherwise, reveal the code, walk through each step of the algorithm, and explain any new blocks.

4+ minute application and exploration
Encourage coders to try something similar, and leave your code up on display while they work. Facilitate by walking around and asking questions about how coders might change their code so it’s not the same as yours.

Video: Suggestions for reverse engineering (4:25)

Alternative suggestion: If reverse engineering is too difficult for the coders you work with, you could display the source code and have coders predict what will happen.

Suggested guiding questions:

• What kind of blocks do you think you might need to do something like that?
• Do you see a pattern where we might use a repeat?
  • If so, what kind of repeat?
• When combining ideas, what happens if you use multiple event blocks in the same sprite? (Note: this concept is referred to as parallel computing)
  • What are the benefits/drawbacks of using multiple event blocks?

Potential discussion: There is not always one way to recreate something with code, so coders may come up with alternative solutions to your own code. When this occurs, it can open up an interesting discussion or journal reflection on the affordances and constraints of such code.

Suggested application and exploration questions:

• What other code blocks could you use?
• What other sprites might use similar code?
• What other code could we add to this project?

8. Add more functionality to the music player app (40+ minutes):
40+ minute coding time and 1-on-1 facilitating
Give coders time to add more functionality and customize their music player. Encourage peer-to-peer assistance and facilitate 1-on-1 as needed.

Facilitation Suggestion: Some coders may not thrive in inquiry based approaches to learning, so we can encourage them to use the Tutorials to get more ideas for their projects; however, we may need to remind coders the suggestions provided by Scratch are not specific to our projects, so it may create some unwanted results unless the code is modified to match our own intentions.