Musical Instrument
Experience: 1st year, 1st quarter
Practice: Developing and Using Abstractions, Creating computational artifacts, Testing and refining computational artifacts, and Communicating about computing
Concept: Algorithms and Control
Length: 40+
Overview and Purpose
Coders will trigger sound blocks to play a musical instrument made out of different sprites. The purpose of this project is to review creating sprites and triggering sound blocks when a sprite is tapped. Another purpose of this project is to also introduce remixing.
Lesson plan
Overview videoPreparation (At least one day prior)
Suggested preparation
Share the sample project file to other devices if remixing the sample project; click here to learn more about sharing files.
Ensure all devices are plugged in for charging over night.
(10+ minutes) Read through each part of this lesson plan and decide which sections the coders you work with might be interested in and capable of engaging with in the amount of time you have with them. If using projects with sound, individual headphones are very helpful.
Resources for learning more
- BootUp ScratchJr Tips
- Videos and tips on ScratchJr from our YouTube channel
- BootUp Facilitation Tips
- Videos and tips on facilitating coding classes from our YouTube channel
- Block Descriptions
- A document that describes each of the blocks used in ScratchJr
- Interface Guide
- A reference guide that introduces the ScratchJr interface
- Paint Editor Guide
- A reference guide that introduces features in the paint editor
- Tips and Hints
- Learn even more tips and hints by the creators of the app
- Coding as another language (CAL)
- A set of curriculum units for K-2 using both ScratchJr and KIBO robotics
- ScratchJr in Scratch
- If you’re using ScratchJr in Scratch, this playlist provides helpful tips and resources
Getting Started (10+ minutes)
Suggested sequence
1. Review and demonstration (8+ 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 to the class we are going to create/remix a musical instrument project that makes sounds when we press different instruments. Demonstrate the sample project or your own musical instrument, but don’t display the code.
If remixing:
Demonstrate how to open the remix project and encourage coders to change the project as much as they want. Spend the rest of the class facilitating 1-on-1.
If creating:
Review how to open ScratchJr, create a new project, and delete Scratch Cat. Review pressing the plus sign on the left and demonstrate how pressing the paint brush in the upper right corner allows you to create your own sprite.
Demonstrate using a couple of different tools on a musical instrument in the paint editor. Press the checkmark in the upper right corner when completed. Review how to record a sound.
Resources, suggestions, and connections
Practices reinforced:
- Communicating about computing
- Creating computational artifacts
Video: Project Preview (0:44)
Video: Lesson pacing (1:48)
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?
Remixing vs creating: If you’re remixing this project, coders will already have access to a variety of drumset related sprites and they will be able to change the sprites to do something new. This makes it very easy to get started right away with coding; however, some coders are more invested in projects they’ve created. Perhaps start with one approach (e.g., remixing) and encourage those who are not engaged to try the other approach (e.g., creating).
2. Discuss (2+ minutes):
Have coders talk with each other about how they might create a project like the one demonstrated. If coders are unsure, and the discussion questions aren’t helping, you can model thought processes: “I noticed the sprite moved around, so I think they used a motion block. What motion block(s) might be in the code? What else did you notice?” Another approach might be to wonder out loud by thinking aloud different algorithms and testing them out, next asking coders “what do you wonder about or want to try?”
After the discussion, coders will begin working on their project as a class, in small groups, or at their own pace.
Practices reinforced:
- Communicating about computing
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 ScratchJr?
- 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 at a concert, jam session, or performance?
- What kind of instruments might we hear?
- What kind of code might they have?
Project Work (30+ minutes; 2+ classes)
Suggested Sequence
3. Create a musical instrument project (20+ minutes):
Ask coders to create a project with instruments that make music when tapped. Facilitate by walking around and asking questions and encouraging coders to try out new blocks.
Resources, suggestions, and connections
Standard reinforced:
- 1A-AP-10 Develop programs with sequences and simple loops, to express ideas or address a problem
Practices reinforced:
- Testing and refining computational artifacts
- Creating computational artifacts
- Developing and using abstractions
Concepts reinforced:
- Algorithms
- Control
4. Reverse engineering even more ideas (10+ minutes each):
1 minute intro demonstration
Demonstrate one of the following example sprites on the board without displaying the code (they are in order of complexity):
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. If coders haven’t figured it out, demonstrate how to record a sound and add it to their project.
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.
Standards reinforced:
- 1A-AP-10 Develop programs with sequences and simple loops, to express ideas or address a problem
- 1A-AP-11 Decompose (break down) the steps needed to solve a problem into a precise sequence of instructions.
- 1A-AP-14 Debug (identify and fix) errors in an algorithm or program that includes sequences and simple loops.
Practices reinforced:
- Communicating about computing
- Testing and refining computational artifacts
- Creating computational artifacts
Concepts reinforced:
- Algorithms
- Control
Video: Suggestions for reverse engineering (4:25)
Video: Learning the parts of the drum set (3:29)
Resource: Learn more about parts of a drum set
Note: It is not recommended to show each of these ideas at once, but to show one idea, give time for application and exploration, show another idea, give time for application and exploration, etc. This process could take multiple classes. Also, some of these examples may be difficult for young coders, so go slow and encourage copying and modifying code as it’s good practice.
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?
- What trigger blocks do you think I used for that sprite?
- Did I use one trigger block or more than one?
- What makes you think that?
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 sounds might we hear?
- What sounds do different instruments make?
- How do they make those sounds?
- How does the size of the instrument change the way it sounds?
- Can you create these instruments in ScratchJr?
Assessment
Standards reinforced:
- 1A-AP-15 Using correct terminology, describe steps taken and choices made during the iterative process of program development
Practices reinforced:
- Communicating about computing
Although opportunities for assessment in three different forms are embedded throughout each lesson, this page provides resources for assessing both processes and products. If you would like some example questions for assessing this project, see below:
Summative (Assessment of Learning)
The debugging exercises, commenting on code, and projects themselves can all be forms of summative assessment if a criteria is developed for each project or there are “correct” ways of solving, describing, or creating.
For example, ask the following after a project:
- Can coders debug the debugging exercises?
- Did coders modify the original project so it’s not the same as the project preview?
- Note: The project preview and sample projects are not representative of what all grade levels should seek to emulate. They are meant to generate ideas, but expectations should be scaled to match the experience levels of the coders you are working with.
- Did coders use a variety of block types in their algorithms and can they explain how they work together for specific purposes?
- Did coders create a musical instrument with at least ## different sprites with different algorithms?
- Choose a number appropriate for the coders you work with and the amount of time available.
Formative (Assessment for Learning)
The 1-on-1 facilitating during each project is a form of formative assessment because the primary role of the facilitator is to ask questions to guide understanding; storyboarding can be another form of formative assessment.
For example, ask the following while coders are working on a project:
- What are three different ways you could change that sprite’s algorithm?
- What happens if we change the order of these blocks?
- What could you add or change to this code and what do you think would happen?
- How might you use code like this in everyday life?
- See the suggested questions throughout the lesson and the assessment examples for more questions.
Ipsative (Assessment as Learning)
The reflection and sharing section at the end of each lesson can be a form of ipsative assessment when coders are encouraged to reflect on both current and prior understandings of concepts and practices.
For example, ask the following after a project:
- How is this project similar or different from previous projects?
- What new code or tools were you able to add to this project that you haven’t used before?
- How can you use what you learned today in future projects?
- What questions do you have about coding that you could explore next time?
- See the reflection questions at the end for more suggestions.
