(Everything I say is false...)
home | about | articles | presentations | cv | contact

Make a Joyful Noise

Wednesday, 13th February 2019 (4:00PM)

I have a new tuba!

If my mention of a tuba is a surprise (it shouldn't be), check out this short student-film, by my buddy Jane, which explains all:

My new tuba isn't a replacement for my current instrument (which I got when I was sixteen years old). Rather, the instruments complement each other. What's the difference? If my current tuba is a professional "all rounder", my new instrument is a sort of "heavy duty" tuba for big orchestral pieces (most of my current playing is orchestral).

The tuba works by amplifying the buzzing sound I make with my lips into a mouthpiece. I change notes by tensing or relaxing my lips (so the buzzing sound gets higher or lower) which gives me a limited series of notes that are overtones to the "fundamental" (lowest) note produced by blowing down the length of the tube of the instrument. I use valves to add tubing to the length of the instrument to fill in the notes between the overtones so I can play all the notes I need (i.e. a chromatic scale).

What's interesting is how the two instruments are different.

My original instrument is pitched in Eb (E flat) -- which means the instrument's fundamental note is the Eb more than an octave below the bass clef (i.e. very low). My new instrument is pitched in C, so its fundamental note is even lower, thus making it an instrument more suited to lower sounding music.

The valves on each instrument are different. I have "piston" valves on my original instrument. These are spring loaded and when pressed fully down add additional lengths of tubing to the instrument. The photograph below is of the inside of the valve so you can see the holes in the piston used to connect the different pipes, depending on the valve's position (up or down).

The inside of a piston valve.

My new instrument uses "rotary" valves. These, as the diagram below shows, rotate to connect additional lengths of tubing (the passage of air is indicated by the hatched area). A sort of lever is used to actuate each valve. They're generally much quieter and more reliable than piston valves (less moving parts to make clanking sounds) although they can be slower to "engage".

A diagramatic view of a rotary valve.

The picture below shows the rotary valves on my new tuba. Notice the levers I press with my fingers to engage the valves.

Rotary valves on my new tuba.

While both tubas look "tuba shaped" my original tuba points to the right (as the player is looking at the instrument) whereas my new instrument points to the left. This simply means I have to hold them differently and there's not really any change in sound. You can see this difference in the picture below (the new tuba is on the right):

My two tubas.

The final major difference is in the number of valves each instrument has. My original instrument has four "compensating" valves which allow me to get a full chromatic scale. The new instrument has five "non-compensating" valves: the first four work like my original instrument and allow me to play a full chromatic scale, but the fifth valve is used to help tune the very lowest notes.

Why does the new tuba need a special extra "tuning" valve and what on earth am I talking about when I say "compensating"..? This, dear reader, is where maths, acoustics, logic and music come together in a spectacular fashion.

My new tuba is approximately 524.9 cm in length without any valves engaged. This produces the note, "C". The first valve adds enough pipe to lower the pitch by a tone, giving me a "Bb" (B flat) which requires the total length of tube to be 589.2 cm. Simple arithmetic tells us the total length of the tube added by using the first valve is therefore 64.3 cm (the "open" length of the instrument with the added tube should give the correct length to play a tone lower). The second valve drops the pitch by a semitone to the note "B" which requires a total length of 556.1 cm. Similarly, the third valve lowers the pitch by one and a half tones, giving me an "A" which requires the total length of tube to be 624.2 cm. Again, the simple arithmetic tells me that the length of tube added by the second valve is 31.2 cm while the length added by the third valve is 99.3 cm.

Here's where it gets interesting. If I want to play the note "G" I need to make the length of the instrument 700.6 cm. Given the note "G" is two and a half tones below "C" I could take the tone provided by the first valve and one and a half tones of the third valve and use them together. It means the resulting length of additional pipe is 64.3 cm (the first valve) + 99.3 cm (the third valve) giving me a total of 163.6 cm. However, the open length of the instrument (524.9 cm) with the additional lengths of pipe (163.6) brings the total length to 688.5 cm, which isn't the 700.6 cm needed to play the note in tune!

The solution is to use my fourth valve, which adds 175.7 cm to the length of the instrument, thus making it in tune. However, when I need to use my fourth valve in combination with my other three valves I still encounter the same sort of "wrong length of pipe" problem I describe above. I must use combinations of valves in order to get all the notes I need in the chromatic scale. So what can I do?

This is where the fifth valve on my new tuba comes into play. It has a special tuning slide I can adjust "in real time" as I play, thus allowing me to tune the fifth valve as and when I need it. It can also be tuned in such a way that it "compensates" (remember that word) for the missing lengths of tubing when I use the other valves together.

Which leaves us with the problem of keeping my current tuba (with only four valves) in tune. Thankfully, this instrument has "compensating" valves which work in a rather ingenious manner. The schematic representation of my current tuba is shown below. The mouthpiece is on the left with the bell on the right and between are the four valves and associated tubing (not to scale). None of the valves are engaged so the column of air blown through the instrument goes directly through without any "detours" (as shown by the pipe filled in with blue).

Compensating system, no valves pressed.

When I press the first and third valves down the expected two extra lengths of tubing are added, as shown by the two loops of pipe filled with blue:

Compensating system, valves 1 and 3 pressed.

Here's where it gets really clever. When the fourth valve is pressed down, not only is the expected additional length of tube added to the length of the instrument, but this tube is also diverted back through the other three valves which have additional "compensating" tubes to bring the instrument in tune:

Compensating system, valves 1, 3 and 4 pressed.

This is, essentially, a logical AND expressed as pipe-work. If the first and fourth valves are pressed then add some new "compensating" length of pipe. Clever huh..?

The disadvantage of this system is the air does two "circuits" around the instrument (once through the first three valves, and then again if the fourth valve is pressed so the compensating pipes can come into effect). This makes the instrument harder to blow (since there are more bends to blow through). My new instrument feels like there is less to push against when I'm playing.

Finally, given all the technical tuba-related geekery described above I want to end on an artistic note...

These instruments are beautiful to look at and playing them is a joy. It's hard to explain to folks who have never performed music what an amazing privilege it is. I get to play beautifully designed and precision engineered instruments as part of an orchestra, band or smaller ensemble. By playing with my fellow musicians to an audience I'm taking part in a unique social activity. No matter the mood or difficulty of the piece I'm playing, I love the sense of non-verbal communication I have with my fellow musicians and collectively with the audience. I love that I am a part of something creative, challenging, expressive, collaborative and most definitely greater than the sum of its parts. That the audience appreciate these efforts is a lovely positive side effect.

To me, this is always "joyful noise". :-)


Saturday, 5th January 2019 (3:30PM)

Lots of people want to learn how to program computers.

The success of code "boot camps" and devices aimed at the education sector (Raspberry Pi and the BBC's micro:bit spring to mind) is evidence of this desire for folks to learn "coding".

At a time when technology is finding its way into every aspect of our lives many folks appear to want to be more than just passive consumers of technology. They feel a desire to become creators of technology. They want to take control of their digital world. They want the skills to make their technology reflect their own needs.

Recently I've been experimenting with how I could use my background and expertise in music education in a way that helps folks address this desire for learning to program. The first experiment took place over the autumn and involved a group of complete beginners preparing for a "code grade".

CodeGrades are a programming version of time-proven techniques like music grades, belts in martial arts or lifeguard certification. Learners level up by applying the knowledge and skills needed for each grade to their own fun, interesting and challenging coding projects. Learners present their projects to professional software developers who assess the projects against the criteria for the grade being taken and provide a set of marks and written feedback so the learner can see where they're doing well, what needs to improve and what their next steps may be.

The autumnal experiment proved this concept worked. The initial group of learners were able to learn enough to create a "grade 1" level project in the Python programming language in about ten weeks. Furthermore, after completing their grading the vast majority asked when they can take their next grade. This outcome was far better than I had ever imagined.

Like music grades, code grades are eight cumulative steps for learning how to write code. The first grade (as taken by our "test subjects") is easy enough for most people to take as a first step into programming. The eighth grade is of equivalent standard to the skills and knowledge needed to be an effective junior professional software developer. The middle grades bridge the way so the skill gaps between each of the grades is achievable. They're like stepping stones into coding, or perhaps a modern day "Gradus ad Parnassum". ;-)

Perhaps the most important aspect of CodeGrades is how it is different to other educational offerings.

Code boot-camps will charge you north of £10k for a three month course and a guaranteed "job" as a junior developer. This is, frankly, a terrible idea. Not only are people throwing huge sums of money over a cliff edge before they make the jump themselves, but learning to code requires a long term investment of time. You cannot learn how to write effective code in just three months. What the boot-camps have realised is that you can learn enough information in just three months to appear as if you can code. It has been my unhappy experience to interview graduates of such schemes and have them answer my questions about the niceties of some aspect of coding with text-book answers; yet most have been unable to apply such "text book answers" in any useful or even credible way. Those who did create something made what can only be described as "spaghetti code". This is the equivalent of claiming that it's possible to train musicians to a professional level in just three months. Can you imagine how an orchestra would sound with musicians trained in this way? Would you want to hire such musicians to play for your wedding party?

Other educational efforts are mostly aimed at beginner developers. As a result, all their educational resources are at the beginner end of the scale and there is hardly any guidance for how to move onto more challenging programming. Put another way, it's like getting a piano with lots of beginner level music to learn, but nothing which will stretch you after you've got the basics in place. There is simply no continuity nor access to the fun "advanced" stuff.

The syllabus for CodeGrades is written by professional software developers. The grades reflect current best practice found in the software industry. They offer a framework for sustained and structured long term learning to write code. All the resources associated with CodeGrades are free, learners only pay to take the grading. CodeGrades will be priced in a way equivalent to music and ballet grades or martial arts belts.

CodeGrades help you learn to code with the confidence you need to make the stuff you want.

The upshot is that it's the start of the year, and I've decided that the outcomes from the experiment in the autumn have been so positive that I want to invest some of my own time into developing the concept further.

So, here's to an interesting 2019... I hope to work with friends (old and new) in making something that helps people learn and grow while also providing employment for developers who feel they're at a stage in their career where they want to acquire and practice the skills needed to be effective and inspiring mentors.

Happy new year.


Monday, 22nd October 2018 (1:00PM)

I write from a place of love and respect for the UK Python programming community. Some of what follows may make painful reading (sorry). But I want to be clear: if you misconstrue my words as aggressive, nasty or hurtful, then you have completely misunderstood my intent. I will never knowingly be a source of vindictive pain.

I'm going to shine a light on the (usually hidden) problems I have encountered in the UK Python community over the ten years that I've been volunteering.

It's hard to do this without appearing as if mud slinging or trying to diminish the considerable public-facing achievements of the UK Python community in doing genuinely wonderful things. I am anxious to avoid a situation that undermines all the good stuff.

But only by highlighting and acknowledging such hidden problems can action be taken to address them. I hope you bear with me as I try to find the words to explain things in a constructive, non-confrontational yet honest way.

The problems of which I speak are many in number and range from the institutional (a woman of limited means put into the humiliating position of having to beg for financial support), and petty (describing the John Pinner awards as "just a popularity contest") to plagiarism (members of the community claiming the work and intellectual property of others as their own) and an exercise of power and control for organisational gain (a sponsor taking steps to exclude others from fully participating in a community event -- they threatened to pull out if they didn't get their way). Sadly, I have a list as long as my arm full of such things.

Above and beyond these problems are personal attacks, slights and snark aimed directly at me (more on this later). Having said that, I want you to know that I bear no ill-will nor grudges.

I'm necessarily vague about the details: I don't believe finger pointing or blame is a useful or constructive way forward. Far better to honestly and constructively highlight such problems in the hope that they are acknowledged and can be avoided in the future.

If you're thinking, "that's not the UK Python community I know", then I am happy for you. You know the joyous, supportive and friendly place that welcomed and sustained me as a new Python programmer in 2007. I wish you good fortune and hope you cherish, advance and grow this aspect of the community.

However, such problems are themselves problematic because they are so often hidden. Furthermore, I've observed that those involved often don't appear to realise they are causing a problem. Upon reflection, I believe such situations are caused by a lack of just one thing: compassion (an awareness of and sympathy for another's feelings and suffering, mixed with a pro-active desire to help).

So my plea to members of the UK Python community is to show more compassion.

If you remain unconvinced of my plea, I want to explain what happens when we lack compassion.

Over the past three years I have grown despondent about the problems I have encountered in the UK's Python community. This past year the feeling became unbearable, to the extent that I sought professional help to deal with mental health problems solely arising from my contact with the UK Python community.

Last weekend a straw broke the camel's back and, after a considerable amount of thought and reflection, I finally decided to publicly reveal how I felt via Twitter. I'd been sitting on a huge amount of pent up frustration and sadness, and there needed to be a controlled release. I came to the realisation that only by "coming clean" and honestly describing my feelings would I be able to heal, move on and allow my life to return to some normality.

To say the reaction has been "interesting" is an understatement.

I'd like to start by thanking the many people who took the time to reach out with kind messages of support. You are the best of us, and the reason why the UK Python community is often an amazing place. Your compassion and thoughtfulness is an example to us all. Thank you.

However, I was reduced to tears of hurt by the initial reaction of one member of our community who went for the jugular (and it saddens me deeply that this reaction was "liked" by a number of other people in the UK Python community). I have been asked to justify my feelings to others (how dare I feel this way about the UK Python community) and I have had my words picked over in public leading to unwanted, unhelpful and upsetting comments.

These latter reactions inadvertently demonstrate why I've been feeling despondent. They show a complete lack of compassion and suppress hoped-for constructive dialogue or catharsis.

My despondency and poor mental health is directly linked to encountering and dealing with an excessive number of such problems: a sort of death by a thousand paper cuts.

"But why didn't you reach out for help?" you may ask.

I did.

I was rebuffed when I tried to find support from several individuals in the UK Python community. This led me to a downward spiral of frustration, self doubt and sadness: "What have I done to deserve this? Am I such an obnoxious person that people would refrain from showing support? Why am I not able to speak of my pain?"

I felt a complete failure, rejected and disempowered by the whole situation.

My only choice has been to step away from the UK Python community. It's not the ending I would have wanted and it makes me feel extraordinarily sad.

But my tweets brought acknowledgement from others in the international Python community. I'm not on my own in encountering such problems or the associated feelings of despondency. This is definitely not only a UK Python issue. My far flung friends highlighted patterns, features and common ground which, in turn, helped me realise, "I am not the only one".

Personally, by speaking of these things I feel I have turned a corner and have felt a great sense of release, although I still carry a huge amount of sadness and pain about how things turned out. For what it's worth, I hope people in the UK Python community never treat one of their own like this ever again.

What will I do next?

For me, this boils down to a positive assertion, through deeds and words, of humanity, honesty, compassion, patience, love and respect. What that entails depends on all sorts of complicated variables: who, what, where, when and how a situation is. Ironically for a conversation about a programming community, it's not a case of following an algorithm -- I'll have to exercise that unique and precious spark which means I'm not an unfeeling machine: my humanity.

View all articles