Metronome practice tips

In response to @HansOngchua regarding how to best use a metronome for efficient practicing, I came up with this list, which was too long to fit into a Twitter message:

Practice

  1. Plan your practice session. Organize which sections of which pieces you need to work on. Figure out how much time it is going to work on each section and to play through an entire piece if that’s part of your plan.
  2. Practice in chunks. Don’t just set the metronome and plow through your music. Mark off the sections that need attention and deal with them separately – working out the kinks – before you try to play the piece all the way through.
  3. Start your metronome at a tempo where you can play the section absolutely flawlessly – everything is in place: technique, rhythm, notes, phrasing, tone, etc. No compromises. Starting anywhere faster and you’re going to be practicing making mistakes.
  4. Take the above tempo and lets assume it takes 4 minutes to get through it at an 8th-note tempo of 60 bpm. Up to the target speed, it takes 1 minute at 120 bpm. If you’ve set aside 10 minutes of your practice schedule to work on this passage, then you should set the metronome for ♪=60, ♪=80, ♪=100, ♪=120.
  5. Don’t set the metronome for faster than you can play it. If the above scenario is unplayable at ♪=120, try a lower target and compress the in-between metronome markings to fit proportionally.
  6. Subdivide. I indicated eighth notes above, but these could just as easily turn into quarter notes, half notes, or whatever. It is not uncommon to start in eighth note subdivisions and wind up later on in quarter note subdivisions.
  7. Make sure the metronome is loud enough. Plug it into speakers or headphones if necessary.
  8. I almost never use a metronome when playing a piece all the way through. The exceptions to this are when I’m learning notes and want to build technique for a work up to a certain point. But after a while, I break it out into separate sections to work on, so that I can keep certain parts open for rubato, phrasing, and pauses.
  9. But the key question @HansOngchua asked was of course how to keep tempo during a performance. Unless the piece is some robotic vivacissimo etude, I think the tempo is likely going to fluctuate a bit based on human interpretation regardless. But in general, I try to keep an internal sense of tempo. When I’m performing a work, I go back to that internal sense of tempo from time to time to get things back on track. I think this has less of a chance of being “off” when the performer is confident and not distracted by nerves.

Why hosting LilyPond music projects as open source Git repositories is good

For those of you unacquainted, LilyPond is music notation software. Unlike other programs such as Sibelius or Finale, which are both great in their own right, LilyPond deals with sheet music creation as source code in text files using a simple language. You run the files in a compiler, and out come beautiful PDFs of your music. It also can create MIDI files so you can hear a quick gist of what you’re working on too.

Erbarme dich, mein Gott

From a coder’s point of view, it is great to be able to work in your favorite text editor and work in a largely similar way that one would when working on software: code, compile, test, publish. But it’s not as hard as it sounds – beginners can get started producing sheet music scores very quickly by just going through a quick tutorial. Might not work for everyone – some of us need to be able to drag and drop the notes on the staff, or that extra abstraction layer to source code may be just one bridge too far. But the price is right, and it’s worth a try.

For those of you musicians out there who use LilyPond, you understand how useful and powerful the software is. Your music source is in simple text files, easily displayed on the web, ported, and shared. Sharing is a foundation of LilyPond engravers, and there are tons of places to find free and open scores – most notably the Mutopia project.

But creating large projects, especially transcriptions, can sometimes be daunting tasks for one individual. Manually uploading corrections to a site might be tedious, and version control might not even exist.

Git is an excellent solution for version control. And GitHub is a free and excellent destination to host your Git LilyPond projects.

Now imagine people are hosting their LilyPond works on GitHub. Say it’s a transcription of some Baroque-period composition by an obscure composer, and photographic plates are available to view. You want to get it ready for your orchestra, but imagine hammering out all those notes alone. Enter open source: A team of volunteers can grab copies of the project, work on it, and merge code back in. Git handles this process elegantly, and everyone can work together on the same code base. The project is done in record time, and you can spit out parts just in time for the first rehearsal.

But wait, there’s more. Say the band director wants to try this out on the wind ensemble. Rather than starting from scratch, they can fork the project and leverage the existing code. Another person wants to grab the melodic fragments and arrange the same work for baritone sax and synthesizer – another fork. Check out code that is freely available, and rework it ad infinitum.

This might even apply to my stewing idea of crowd-developed open-source composition. I wonder what a symphonic work would look like developed by a team of composers? If we can put together things like Linux and Firefox using the open source model, why not a piece of music?