- Open this Song Player project, and save it to your account. It includes a
command block that takes two inputs: a note to play (pitch) and how long to play it (beats). - Change the inputs to the
play ♪block and then click it, and then change the inputs and click it again to see how the note changes. - Attach several
play ♪blocks together one after another to begin creating a song.- You can use
to create breaks in your song. - You can use
block to repeat any command (or group of commands) a specific number of times. Any code you put inside the C-shape of the repeatblock will be repeated. - You can also use
to change the instrument, 
to change the tempo (beats per minute), or 
to change the volume. Wherever you put one of these blocks, the sound will change from that point on.
Did an earlier lab already give repeat a thorough introduction? I was surprised to see it so casually introduced, since looping is usually A Big Deal when I teach it in text-based coding classes. It's certainly easier in block-based, but I feel like it warrants its own section, so that you can talk about what goes in the loop vs. out of the loop (i.e. set-instrument can just be outside the loop, no need to repeat it twice). -PF 2/10/22This is here on the principle of "experience before formality." The idea is that they have the opportunity (not required) to play with it and try to see what it does before it is formally thought. I thought that might work well with REPEAT since it does exactly what is says. ;) I added a little extra text to help. We can ask teacher for feedback about it... (Mary TODO) Does that seem sensible? What do you think, Brian? --MF, 2/10/22
I think the informal introduction is fine, and I don't think looping has to be such a big deal, but I really don't like "Anything above it will happen before; anything below will happen after" because it makes it sound as if the REPEAT block somehow affects the sequencing of what comes before and after it. I would just not say it, but if you think something has to be said, it should be more like "the entire REPEAT loop counts as one step in the larger script of which it's a part" or something like that, to make it clear that the overall sequence of steps isn't messed up by the loop. -bh 3/3/22
Hm, my point about not repeating set-instrument inside REPEAT is probably too subtle for an "experience before formality" type introduction to repeat. Maybe something to point out in the teachers guide, like "if you notice a student has nested blocks inside the repeat that don't need to be repeated, you could suggest moving them out" with a screenshot of the set-instrument example. And then you can delete the "Any code...." line here since bh doesn't like it and I also don't think it adds much. -pf 3/3
Brian, I took that out for now, but this is their first experience with sequencing, and I was trying to explain a bit about how it works. Pamela, I'm not convinced that the TG remark you suggested is needed because this is just a chance for them to play around. I'd rather the teacher not critique a fine point like that. I deleted the line Brian suggested; aren't you asking for the "Any code you put inside the C-shape..." to be removed also? --MF, 3/6/22
Here are two examples:-
Mary Had a Little Lamb
In little-lamb, the two notes just before the REST blur into one for me. Other instances of consecutive notes at the same pitch don't do that. This sounds like a deficiency in Snap! music handling, but do you understand why? Also, I think that huge long rest sounds wrong; I would leave it out. -bh 3/3/22
set-instrument-3 is a horrifying sound to me (sawtooth). really grating. I find 2 and 4 more soothing. -pf 3/3
If you wanted an example song that didn't feel like a lil kids song but that everyone knows, you could do Happy Birthday to You -pf 3/3
I made no changes here because these are matters of taste, and I need to move on to the next lab. --MF, 3/6/22
- Super Mario Theme
- You can use
A command block tells the computer to do something without reporting a value.
I think this is a comment for Michael. --MF, 3/6/22
The pitch tells the computer which note to play. It can be any whole number from 0 to 127. The number 60 represents the note known as middle C. If you click the triangle (▼), a piano menu will open, and you can hear the note you are selecting.
The number of beats tells the computer how long to play the note. By default, Snap! plays 60 beats per minute (bpm), so playing a note for 1 beat takes 1 second. You can change the number of beats per minute by using .
I find both of these inputs problematic. The first one is called "pitch" because you want "note" to mean something else. Avoiding "note" is fine, but "pitch" implies frequency, in Hz, not MIDI note number. I would suggest "note#" or I guess you could get away with "pitch#" or even "pianokey#" or "MIDI#". But "note#" is closest to what the rest of the world calls it.
As for the second input, when I learned about this stuff a million years ago, a "beat" meant one of whatever the denominator of the time in the key signature is, e.g., in 4/4 time it's a quarter note. You're using "beat" to mean a whole measure. The default of 60 bpm is something we inherited from Scratch, and they did it that way because at first they didn't have a REST block in Sound, so they used WAIT () SECS for rests, so they wanted the unit of time to be seconds for music too. More typically, you see bpm=120 or 180 at the top of a score; it's the number you tell your metronome, for how often it should tick. 120bpm means that a quarter note is 1/2 second, and a measure takes two seconds. That's a fairly slow meter. 180bpm means a quarter note is 1/3 second, so a measure is 1.333 seconds, which is more lively. I suggest that the project should set tempo to 180.
I can see that it makes a certain amount of sense to have an input value of 1/4 for a quarter note, but then "beats" is the wrong name. The really right thing, since you're using a custom block anyway, is to have that input be a pulldown menu from which you can select quarter note, half note, etc., both spelled out and with the Unicode music symbol. And the label could be "note type" or "length" or "duration." I know changing this means lots of changes throughout the lab, probably, but any kid who does know something about music, which is a lot of kids, will find this nomenclature strange. --bh 3/3/22
i know nothing about music so I defer to brian's expertise. --pf 3/3Thanks Brian. I'm leaving this for us to discuss next year as it's a bit too late to change the whole lab now. I hear you on what's wrong here, but I disagree with the dropdown as I find it limiting. Looking forward to discussing further when we come back around to this lab. After reading your paragraph, I'm leaning toward play ♪ number: () length: (). Or even just play note, number: () length: (). --MF, 3/6/22
That's what we've been doing in CSP. I took Pamela's suggestion and included the Unicode. --MF, 3/6/22