This is my new favourite thing! I definitely want to try it with a class.
You can access our final Scratch project here:
Play at home using the following keys on the keyboard:
C = Left arrow
C# = Up arrow
D = Right arrow
D# = Down arrow
E = Q
F = W
F# = E
G = R
G# = T
A = Y
A# = U
B = I
C = O
Our Presentation went really well! Everyone’s projects were great! It was handy being a duo with Rachelle for our project because it meant that we could take turns checking out other people’s projects.
It also meant that we could take turns getting each other more cheese… What are friends for?
We had inspirational guest speakers Erin Hendry from St Aloysius College (an alumni student of the Conservatorium of Music education course) and Keith Huxtable from Music EdNet (http://www.musicednet.com/).
Erin Hendry did a wonderful presentation on the reality of high school music teaching. She shared with us her realisation of how difficult it is to bring all of the incredible things we’ve learned into our future positions as music teachers. She explained that this is caused by lack of time, lack of resources, lack of community/school support, and also the need to avoid overshadowing other teachers as collaboration and mutual support between teachers is extremely important to maintain a healthy and successful music program.
Keith told us all about his work with Music EdNet, specifically their DAYTIME Conferences. Last Year, two lucky Con music ed students were selected to speak at the conferences about the projects they presented at their presentation of learning. He also discussed his work with TeleWare in assisting teachers who reach out for tech assistance.
Watch this space to find out who he picks this year to travel around Australia for the DAYTIME conferences of 2020!
A project by Isabel Szanto (https://isabelszanto.wixsite.com/isabelszanto/ ) featured a DIY Electronic Drum Kit. Super fun to play and definitely an awesome addition to any classroom. She used an Arduino to program the audio and had small drum pads connected to it by wires. This would be a good portable music resource for all of those pesky music lessons that are moved to an English room or computer room. It is probably more affordable and versatile than a proper drum kit. Not to mention the cross-curricular links it could achieve with IT based subjects and STEM programs.
Another highlight of the night was Erin Tillett’s (https://erinhtillettmusic.wordpress.com) Video/Picture Book/Composition that she illustrated and composed music for all on her own. Not to mention the video editing skills she had to acquire. She drew all of the illustrations from scratch, scanned them onto her computer and then edited and coloured them on her drawing tablet. The music and images collaboratively convey the story of the Greek myth of Orpheus and Eurydice.
I really wish I could have seen more on the night but since we were all presenting it was quite difficult to leave our projects for long.
I also loved Rachel Hennessy’s (https://hennessytunetech.wordpress.com ) investigation into converting DAW’s (Digital Audio Workstation) into traditional notation for HSC composition submissions and Emma Holley’s (https://holleyhums.tumblr.com ) recreation of the Hall and Oats song “I can’t Go For That” using only a hall and oats (plus her incredible singing voice).
You can see more about the incredible things my peers have been working on by checking out their blogs: https://humberstone.org/2019/08/16/introducing-the-scmtme-class-of-2019/
Finally, here are some awesome videos of me trying out our final project at the presentation of learning. Don’t judge…It’s harder than it looks!
I created a plain backdrop for the menu.
Once Rachelle had finished coding a separate “Twinkle Twinkle” game, I was able to copy the code for that into my backback and then copy it into the “Here Comes the Sun Project. See the bottom of this screenshot:
I then created three sprites that would act as the buttons on the menu page. For some reason they look different on my computer when I actually try to play the game than when I am editing it however when using Rachelle’s Mac it works perfectly fine… Anyway this gives you an idea:
Looking inside the “Freetsyle” sprite:
Looking inside the “Here Comes the Sun” sprite:
Looking inside the “Twinkle Twinkle” sprite:
As you can see, they are all extremely similar. If the given sprite is clicked it broadcasts a specific message. These messages then set off other messages such as hiding the sprites shown on the menu screen, showing the keys of the keyboard on the screen when the menu disappears, changing the background, and prompting the appropriate falling sprites.
Within each piano key sprite is the following.
This ensures that when the green flag is pressed, the only thing on screen is the menu and then when an option is selected, the piano appears.
When a certain sprite is clicked and a signal is broadcast, each of those signals trigger a background change:
Here is a screenshot of the falling sprites for D:
Both of these are written within the same sprite however will only start if they receive a specific broadcasted message (see the first blocks of each code).
In order to have the falling sprites depict the correct rhythm I had to tell them to wait appropriate amount of seconds before the next one fell.
I started out by notating the main melody that I wanted in the game. I then decided that 1 crotchet = 1 second. Here is the melody I started with and I slightly varied it when I started coding.
- 1 crotchet rest before the first B is played.
- 3 quavers (including the first B) before the next B.
- B dotted crotchet + crotchet rest = 2.5 seconds rest.
- Then there isn’t another B until the end of the first system (12 crotchet beats/seconds later).
SO MUCH COUNTING!!!
I got it! Thanks to more help from Rowena in clearing things up.
To be able to ensure a player only gets a point if the falling sprite reaches the yellow bit at the bottom I had to separate each of the sprites into one for each x-coordinate (aka each note).
For example, all of the falling sprites for B (x = 114) were clones of the same sprite which I called “B”… I’m super creative like that!
You’ll notice that I’ve also deleted all of the “switch costume to ___” which used to look like:
I had this in the original coding because our model game on scratch included this however we only needed the same costume for that sprite every time it created a clone to fall from the top of the screen.
Side Note: I tell the program to create a “clone” of the sprite so that when it passes y-coordinate = -130 and deletes itself, the sprite still exists in order to appear for the next falling sprite for that note (rather than making an individual sprite for every falling sprite).
The original sprite is always hidden and stationary somewhere on the screen as it is told in:
Back to how I figured out the scoring…
Once I had created a falling sprites for each note, I was then able to tell it when and how to change the score:
Explaining from top to bottom:
- When the clone is created,
- Show clone (unlike the original which is always hidden on the screen),
- Set to the x-coordinate stated in the other section of the falling sprite code that you can see at the top of this post,
- Set y coordinate to 180
- Once the clone is created change y coordinate by -2 continuously,
- Meanwhile, if the clone touches any yellow on the screen at the same time as the “i” key is pressed on the computer keyboard (this is triggered when B on the large scale floor piano is touched –> see my earlier post “Remapping the Makey Makey” from November 17th),
- The score is increased by 1,
- Wait 0.5 seconds (this was added to the code because the computer was adding 60+ points for 1 correct note. It turns out that the computer was just so fast that it processed the one note being hit multiple times before it deleted itself at y=-130),
- Also, when the falling sprite clone falls below y coordinate -130,
- Delete clone.
The only difference in the white and black notes is the colour that it should be touching to get a point (black notes use green dots rather than yellow) and the y coordinate that it deletes itself at is y < -76 rather than y < -130.
For “Here Comes the Sun” players can get a maximum score of 48. As I mentioned in my last post, I have created different backgrounds to provide feedback in relation to the final score. Since that last post, I also added an extra background which says “Perfect!” which (as you guessed) pops up if someone gets a perfect score.
I also changed the amount of points required to get “You Rock!” as I feel 32/48 is still a pretty good score.
I’ve now added two backgrounds. One for if someone gets a high score and one for if it’s not so great… (see above).
After the final note in the song, I have told it to wait 8 seconds before “broadcasting ‘game over'”.
Under coding for the background I have added the following:
This ensures that once the song is over, the background will switch to either “Practice Makes Perfect!” or “You Rock!” depending whether their score is higher or lower than 40. The highest score is 53.
I’ve been struggling quite a bit trying to perfect the coding for the score. So far, I have it resetting to zero whenever the start button is pressed.
I’m really struggling with the variables in the “if” section of the coding. I don’t know what exactly to make trigger a point. I want the player to get a point when they press the RIGHT keyboard key that corresponds with the RIGHT note at the RIGHT time. However the only way for Scratch to determine if a note was pressed at the right time is if the sprite is touching the right colour or at the right coordinates.
So far I have at least figured out that the first piece of the coding is “when __ key pressed” and now I need to fill in the other few blanks.
Using the original template we already had, I edited the pre-existing sprite costumes to look like the following:
Using the original template we already had, I edited the pre-existing sprite costumes to look like the following:
I later renamed each costume according to one of the notes in the song “Here Comes the Sun” (B, A, G, F#, E, D, C).
To make the falling sprites align with the piano keys, I changed the x coordinates in the code.
To portray the rhythm through the distance between each falling sprite. I told the sprites how long to wait before the next sprite fell. A quaver = 0.5 seconds, a crotchet = 1 second, a minum = 2 sec, semibreve = 4 sec. I even had a dotted quaver (0.75 sec) and a semiquaver (0.25).
I edited each of the sprites for the piano keys so that it would be clear when the key should be pressed when the falling sprites align with a circle.
In the pre-existing project that I began with, there was already coding to make the clones disappear once they reached the bottom of the screen. I edited the y coordinate in this code so that the falling sprites would disappear as soon as they aligned with the circles on the piano keys : y = -130.
After doing this I realised that the F# would prove to be a problem as the circles for the black notes were higher, therefore needed to be deleted at a higher y coordinate. I decided to create an entirely new sprite rather than create a costume for the F#. This way I could easily program that sprite to delete itself once it reached the appropriate y coordinate.
To emphasise when the falling sprites would align with a black key, I decided to change the colour of the falling sprites and the circles on the keys so that they matched. Yellow for white keys and green for black.
Since I created a new sprite for F#, I had to compensate for that in the coding which portrayed the rhythm. When an F# was played, the other sprites were told to “wait” the length in the notated rhythm + the length of the following F#. Likewise, the F# had to “wait” the length of all of the notes preceding it. You can see the waiting time between each F# in the screenshot below:
I’m loving my friend Rachel’s awesome composition! Super catchy 😁
You can also follow her on Twitter.