After the first two parts of this series, where we looked at items 1 & 2 on the below list, it’s time to tackle item 3:
- A single sound is assigned to our robot
- When the robot stops completely, so does the sound
- The same sound is assigned to each of the robot’s parts
- When each part stops moving, so does the sound for that part
- A different sound is assigned to each of the robot’s parts
- When each part stops moving, so does the sound for that part
As I mentioned last time, I was fairly happy with the results from the second option. This time I went and added new sounds for two of the larger parts (keeping the same sound for the base of the robot and the smaller parts at the end of the arm). Everything worked well enough from a technical perspective, but I did find the resulting cacophony a little overwhelming. I’m sure that with a better of choice of sound – for this particular scenario – it would work well, but that’s getting into professional sound design territory: I’m personally happy rolling back to where we were at the end of the last post.
Here’s a video of this approach in action, to give you a sense of what I mean.
I feel that spatial sound has been explored adequately, for now, but I do expect to come back to it: it’s definitely a useful tool for indicating not only the operation of the robot but potentially also collisions with its environment.
In terms of where I want to go next… I want to add some simple scaling capability – to make the model larger or smaller via voice commands – as well as putting some more effort into spatial mapping and placement: I want the user not to be able to put the robot somewhere it does fit, and – ideally – have the robot not hit walls during its gyrations, if it was placed too close to one. And then there’s the dancing piece: I want to hook up a beat detection component and have it send messages to the robot to have it movements affected by the music that’s playing (this is going to be shown at an evening event with a live DJ, so that’ll be really fun).