ruby_cover_band VS sonic-pi-cli

A guitar is a string instrument, and each of those strings make a sound when you play them. For this example we'll focus on the happy path, which is that plucking the string plays the expected note. The code I built also considers that strings can break, and attempting to play broken strings won't work. You can look at the full implementation to see how that works.

In the earlier post on dependency injection, I created a PracticeAmplifier class that did nothing so I could use it in tests, rather than the "regular" amplifier.

In this example, our synthesizer changes its memory capabilities based on the brand that it is.

In reality, the difficulty in testing the Guitar class is what led to the decision to inject the amplifier in. That's because the Amplifier class is essentially a wrapper around Sonic Pi. Sonic Pi describes itself as a "code-based music creation and performance tool", so playing the guitar with this amplifier will actually play a sound on your computer.

A few years ago I wrote about controlling Sonic Pi with Ruby code without needing to code in the IDE directly. That relied on the sonic-pi-cli gem. For my Anyone Can Play Guitar (With Ruby) talk, I took a different approach.

This is all in a string (the data type, not the part of the instrument), because we're going to pass it to Sonic Pi via the sonic-pi-cli gem. This is going to execute the note method in Sonic Pi to play that single tone.

To get around using the IDE directly, I found the sonic-pi-cli gem. Its principal use case is to be used directly in the terminal. However, it's a gem, and written in ruby, and the core functionality is available in a class that you can use in any of your code.