The Art of Programming II: Rabbits and Turtles
Yesterday I talked about programming concerts/recitals. More specifically, I talked about goal setting for your concerts, as well as the machine gun/sniper rifle spectrum of program structure. Today I'm going to talk about cute things. Today, I am going to talk about bunnies and turtles.
Once upon a time, there was a rabbit. He had a lot of friends, but because he was a bit of a dick, he didn't have any particularly close friends. On the other hand, people enjoyed his antics and generally liked having him around for parties. You were never really sure what the rabbit would come up with next. Sometimes, it was glorious fun. Other times, somebody shot their eye out while brandishing a Red Rider BB Gun with a compass in the stock.
Durdle the Turtle
On the other end of the forest lived Durdle the Turtle. He was a fine, upstanding citizen. He paid his taxes on time. He looked both ways when he crossed the street. He was very deliberate with his choices. Sometimes, it would take him weeks to decide what box of cereal to buy at the grocery store. Then he would realize, he was a turtle, and didn't eat cereal. BUT! If he did, he sure well knew which box of cereal he would get. Durdle was not very popular. He did not get invited to the reindeer games, and not just because he was not a reindeer. The friends he did have, however, were very loyal to him, and vice versa.
GET ON WITH IT!
I bring up the Wascawwy Wabbit and Durdle the Turtle to help draw attention to the most basic of economic choices: risk vs reward. The rabbit is always taking risks. Sometimes, it pays off gloriously. Other times, it ends with a trip to the hospital. Durdle the Turtle is never taking risks. Sometimes, this lets him lead a safe and comfortable life. Other times, it leads him to choose a box of cereal he doesn't really need. He's also kind of boring.
So breaking it down to extremes: High risk versus low risk; high reward vs low reward. This makes a box. High risk/High Reward, Low Risk/High Reward, etc. etc. I hope I don't have to spell it all out.
Why talk about this at all? Because certain pieces of music will carry with them a certain amount of risk, and a certain amount of reward for taking that risk. The trick is, figuring out which is which. Occasionally, it is obvious. Schoenberg, bless his heart, is a very high risk proposition in American concert halls. The reward you might get from a concert featuring Schoenberg is a bit iffy, but in America, at least, the reward is likely to be rather low. Beethoven is generally rather low risk. People love Beethoven. It's also rather high reward. People love Beethoven!
In the art of programming, we need to carefully balance our risk. It is not that we can never play Schoenberg. It's just that we need to construct a context in which the risk of programming Schoenberg is mitigated by other factors. And it's not that we should always play Beethoven. While Beethoven is rarely boring, Durdle the Turtle always is. If you're constantly making low risk programs, people will lose interest. This means that we need to take a certain amount of gambles... while carefully balancing those gambles against much less risky programming choices.
The polls don't lie. Except when they do.
The big question is, how do you figure this all out? The most direct method is to just ask people what they like and what they want to hear. This has the advantage that you know exactly what to give the people. It has the disadvantage in that the people don't know what they didn't know they wanted to hear. That is, they will only choose piece based on their existing knowledge. Beethoven and Mozart will come up a lot. Schumann less so. Why? For the simple reason Schumann is less known. It has nothing to do with Schumann being a worse composer, far from it. Whenever I've seen or played Schumann, he has always been spectacularly received. He just doesn't have the same public image, and so won't jump to mind as readily.
Another method is less direct. You take opportunities to program lesser known works and judge the audience reaction. Was the applause polite or enthusiastic? Did the standing ovation seem obligatory or spontaneous? Was the audience falling asleep in their popcorn, or were they carefully paying attention throughout? Things like that. It takes careful observation from several perspectives. How did the orchestra feel they were received? How about the CEO in the audience? What about the ushers? What did everybody see and feel? That's how you tell what the audience felt. You have to watch closely and compare notes, because everybody has a different perspective, and it's only when you take them all together that you get a clear picture.
Alright. We're getting some focus here. We've got our goals. We've got our gun spectrum. We've got our rabbits and turtles. Now what is out poor befuddled flatulaphonist to do next? How do we start bringing this information together? Join me next time for the exciting conclusion to The Art of Programming: Building your Rabbit and Turtle Army! Time to crush our enemies, drive them before us, and hear the lamentations of their women!