We’ve got an exciting year ahead of us in the Cambridge Philharmonic. Not only do we have a great season of concerts, but we’ve introduced a learning & development plan for the string section as well.

A blank notebook on a wooden desk.


  1. Improved intonation on tonic and dominant chords.
  2. Playing in the same part of the bow as the front desk

We will be releasing more video and written content throughout the year relating to these goals as well as holding special workshops.


We will also be releasing a series of eight short videos covering the following topics:

  • Introducing Goal 1: Tonic and Dominant Intonation
  • Introducting Goal 2: Playing in the same part of the bow as the front desk
  • Orchestral practise tips for busy people
  • No accidental bow noises
  • Whose fingering to use?
  • Quick page turns
  • Passing messages back
  • Essential stringed instrument maintenance


One of the techniques we have learned from the software industry is to have a post-concert retrospective where we ask questions like

  • “What went well?”
  • “What could have been better?”
  • “What should we do differently next time?”

The answers to these questions are then used to guide the preparation for the next concert.

What’s next?

Keep an eye on the YouTube DeskNotes playlist, this blog and social media as we will be releasing the videos Saturday mornings at 10am starting 7 September 2019.

Cambridge Philharmonic Twitter

Paula Muldoon Twitter


I’ve recently rocketed my music setup into the 21st century and I thought I’d share with you the tech I’m using now!

Tablet & Stylus

Essential for reading music. I use the iPad pro 12.9″ with the Apple pencil. 

  • Save the trees — no more printing music
  • Easy to mark up in different colours
  • Also easy to erase — no more residual pencil marks
  • Easy to read in dim light
  • Entire music library in one lightweight tablet (yes, they are light now)

Learning curve:

  • None, really


Must-have to turn the pages. I use the Donner (https://www.amazon.co.uk/Donner-Bluetooth-Rechargeable-Reading-Controller/dp/B01MZICTQV)


  • No more difficult page turns


I use a midi keyboard to input notes into Musescore. Great for composing quickly! Doesn’t do rhythms but the pitch saves you a lot of time. Really portable as well — took it on a transatlantic flight iwth no problem.

I use M-Audio Keystation Mini 32 II, Compact Portable 32-Key USB/MIDI Keyboard Controller with Synth-Action Velocity-Sensitive Keys (https://www.amazon.co.uk/gp/product/B00IWRJSE2/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1)


  • Easily plugs into MacBook
  • Draws power from MacBook
  • 32 keys but has a big range as you can hit the plus or minus button to move your octave around

Modacity — Practice App


I use this app every day with my practice and I think I’ve barely scratched the surface of what it can do. Shoutout to Andrew Hitz at The Entrepreneurial Musician podcast for introducing me to this!


  • Make practice lists
  • Record yourself easily
  • Metronome/tuner
  • Tracks time spent practicing
  • Tracks practice streaks

ForScore — for reading music

I got this app several years ago for reading music, back when it was half the price. Not sure I’d buy it now as there might be cheaper alternatives, but I’m very pleased with it nonetheless.

PiaScore — IMSLP app

Great for downloading music from the wonderful free IMSLP library.

Musescore — for composing

Like Sibelius, but free. I compose on my MacBook Air but there is an iPad app as well which I haven’t tried.

Originally published in April 2017.

The view from St John’s College, Cambridge — taking a tea break from a rehearsal

This week 3 blog is coming out in week 4 because I turned a corner in coding this week: it was the week I started preferring to write code over blogging.

This may not seem like a big deal, but it is — I LOVE writing and for the first two weeks, I would have much preferred to write about my coding than to actually code. Now it’s reversed, and although I still love writing, I’m actually kind of irritated that I’m writing now instead of coding.

But I think it’s also really great to document what’s going on, so here goes.

My week 3 experiences:
1. It was much easier than week 2 — I was able to put into practice a lot of what I’d learned in week 2 and it all made sense.

2. Each day is so full of new coding knowledge — I was looking back at week 2 programs and they seemed laughably simple. This is encouraging, because at the time, they felt hard.

3. I was pretty disciplined about not working too hard! I know the course is about to get intense, so I made sure to get all the work done that I needed to do, but I also made sure to enjoy walking around, getting time in the sun, and chatting with friends. All of this is really important to give my brain time to rest from all of the intense learning I’ve been doing.

4. My FitBit is still great — it’s making me walk more, and walk the long way round to things, just to get in all those steps.

5. My violin recital went really well! It was super fun to play my own piece (Yankee Doodle Variations for Solo Violin, which I wrote last summer after an ice cream truck drove by my house every day for two months playing Yankee Doodle) and, despite not having played a solo recital in a few years, I wasn’t nervous at all. My pianist Tim was great to play with and we’ll definitely play some more recitals. So it’s wonderful that I will still be playing violin for fun as I become a programmer.

6. Also in violin/book news, I did 8 hours of recording sessions on Saturday in London. My train was quite delayed so my planned 20-minute excursion to Daunt Books en route to Air Studios at Belsize Park had to happen in three minutes. In a beautiful meta-comment, I bought a book on split-second decision-making (“Blink”, incidentally the title of one of the scariest Dr Who episodes). The only problem is that I am now reading eight books simultaneously, all of which are fascinating. Need to focus!

Ok, now I think I have earned some coding 🙂


The lush grounds of Madingley Hall, where I played my recital and also had an excellent roast lunch.

I’ve been thinking about how my violin skills can help (or hinder!) my programming. Thanks to over twenty years of musical training, my brain is programmed to do the following:1. Search for patterns. 
2. Pay attention to minute details.
3. Process multiple streams of information​, mainly aurally but also up to about eight different written inputs, and also visual signals from a conductor (including deciding in a split second whether the conductor’s input is useful or not!).
4. Execute the results of the “program” (i.e. the written music) in a timescale, in a coordinated effort with up to 80 other people. Execution means a) choosing which of four strings, four fingers, and roughly eight positions (which I believe is 128 possibilities, but someone correct me on the math if not; and bear in mind there is generally more than one way to execute, so this split second decision also factors in stylistic and other concerns). Furthermore, I have to understand and implement the duration of a note, both in a strictly metronomic sense and also accounting for any flexibility someone else in the group may decide is expressive.

Consider the following piece of music, one which every violinist will know by heart.

​Lots of different rhythms, pitches, all sorts of variables to be executed rapidly, accurately, and in coordination with a large group of people. Seamless integration of all the different streams of information is child’s play to an experienced violinist at the top of her game. Even a less familiar piece rapidly sorts itself out into patterns that my brain recognises and executes.

Now consider this screenshot of the command line:

Two colours (different colours, but neither one uses colours to indicate anything)
Text reads from left to right and top to bottom (except when the command line lists files, which it does in columns)
Details make all the difference — a missed “ . “ in coding can stop a program from running while a missed “ . “ can mean an incorrect note length.

Command line has no timescale

When reading music, I observe the following sequence:
1. Glance over the whole piece to get an overview
2. Mentally note any difficult spots
3. Play the piece, reading each line from left to right while keeping my eyes at least one measure ahead of where I am currently playing (this requires short-term memory to be functioning!)

When reading the command line, I find I often forget step three. It’s frustrating how slowly I read code — I’m used to reading music very quickly — so I try to solve problems using just steps 1–2 without really going through each line. So my next challenge is to accept that for a while I’ll be slower at reading code but that the time invested in learning to be really fluent will pay off later.