Rethinking traditional scale practice on the cello

By , December 20, 2014 2:28 am

(Please note that while this post was written with the cello in mind, several of the principles apply to other instruments too.)

I’ve previously blogged about how back in 2011, I decided to get serious about trying to become a jazz cellist. Since then I’ve had some really interesting and fulfilling musical experiences, but it’s also been a struggle in some areas. I studied and performed classical (in the western sense) cello for many years, but the demands of jazz are so different to most things I worked on during my classical training that I’ve had to fundamentally rethink many aspects of the way I practise.

Scales are one good example of this. I was taught to practise B♭ major something like the following:

standard classical cellistic approach to practising a B♭ major scale

The first interesting thing to note about this is that it omits almost the entire bottom octave of the instrument! There’s really no good reason for this; the bottom octave deserves attention just like the rest of the instrument. It’s only taught this way because the tradition has become incredibly “tonic-biased”, with no awareness of the different modes which even beginner jazz students get taught about.

So one of the first adjustments I made (and I probably stole this idea from one of my mentors, the great jazz violinist Christian Howes, who calls it “extended range”) was to always start from the lowest note of the scale reachable on the instrument:

starting B♭ major on C

Similarly, if the top tonic is not near the top of the range you want to practise in, just keep going until you hit a note high enough to make you think “OK, I don’t need to practise any higher than this!” Whether or not that note happens to be the tonic of the scale should be irrelevant; the most important thing is that you are practising the full range of the instrument which you need to use when performing.

Turning it all upside-down

Another bias which exists in the western classical tradition for dubious reasons is that everything is bottom-heavy: almost all exercises start at the bottom, go up to the top, and come back down again. This inevitably results in the bottom end being practised more than the top, which is particularly bad because the top end is way harder to play well. So let’s swap it all around!

starting B♭ major at the top

(By the way, along similar lines I recommend this great blog post on back-to-front learning by Anton Schwarz.)

Developing new “real world” fingering systems

The next odd thing to note about the classical tradition is that scales are almost always played using a single fingering, and that fingering is typically tonic-biased in another way: the tonic notes are very commonly played using first finger. Perhaps the classical pedagogy evolved this way simply because a single fingering system for each scale was perceived as easier to teach and also for students to memorise. But this approach is hopelessly inconsistent with the real world. If you don’t believe me, take a look at every fragment of a B♭ major scale present in the solo part of Boccherini’s cello concerto in B♭ major, and count for how many of those fragments it would make sense to use the fingering system shown above. If we don’t use those fingering systems when playing actual music, why spend so much time practising them?

So it seems clear to me that practising multiple fingering systems is beneficial for technical reasons, and in the case of jazz for musical reasons too: the improvisatory nature of which means that unless you rely very heavily on licks, you rarely know far in advance what notes you want to play, let alone what fingerings to use. So for any given tonality and position on the instrument, you should practise as many fingering positions as possible, so that when you are in the moment of improvising a solo, whichever hand position you’re in, as many notes are physically accessible from there because you’ve already covered those transitions in practice.

A system for practising all fingerings

But where do we draw the line? After all there are an enormous number of different possible fingerings for a 3-octave scale, and there’s just not enough time in the day to practise even a fraction of them. Or is there?

Violin fingerings

On the violin, this is a bit simpler to understand because pretty much any scale can be played in any hand position without shifting (at least, until you hit the top or bottom notes in that position). So on violin, you can simply practise any scale in any position, and carve up your available practice time accordingly: for example on Monday you could focus on 1st position, on Tuesday 2nd position, and so on.

Cello fingerings

On cello, it’s not possible to play any diatonic scale without a considerable amount of shifting of the hand position, so the problem of how to methodically practise all possible fingerings is far less obvious.

I think the answer lies in considering how to group notes into hand positions. It’s clear from the above examples that typically the hand position shifts every three notes, i.e. the majority of notes in scales on the cello are grouped in threes: 1-2-4 or 1-3-4 in the lower octaves, and 1-2-3 when playing higher up the string. Most exceptions to this are when the open strings are played (but they could be considered as “outside” the groupings anyway), and in the higher octaves of most cello scales, where 2-note groupings are common (e.g. the 1-2 1-2 1-2-3 type of fingering system is very commonly taught in the classical tradition for the top octave of a 3-octave scale).

My opinion is that practising 2-note groupings is really not that useful (at least to me as a jazz cellist), because

  1. the shift distance is smaller so the shift is easier,
  2. 2-note groupings require 50% more frequent shifts when compared to 3-note groupings, which is a big hindrance when attempting to play at speed,
  3. every 2-note finger grouping is already covered by a 3-note grouping, and
  4. I’ve already logged years of classical practice covering 2-note groupings anyway!

So I decided to practise all my scales in only 3-note groupings:

using 3 note finger groupings

Notice here that I’ve also stopped using the open strings (except for the bottom C, since there’s no other way to play it). I made this decision for three reasons. Firstly, in jazz it’s important to be able to transpose to another key at any moment, so I don’t want to become too reliant on scale fingerings which use open strings, since they only work in one key.

Secondly, it makes it very easy to extend this system so that it covers every possible fingering of the scale using 3-note groupings! This is possible simply by shifting the starting hand position by a single note:

starting with the hand position offset

and then shifting it once more:

starting with the hand position offset twice

String variations

Thirdly, it allows freedom to introduce variations on which string is used for a particular group. For example bars 5 and 6 of the above example could be played like this:

string variations

I don’t use a strict system to ensure I always cover all possible string variations; instead I like to improvise the choice of string on the spur of the moment, since this matches more closely what can happen when improvising on stage.

Connecting the dots

Of course this system of 3-note groupings with 3 different starting positions for every scale triples the amount of scales to practise! However since I would normally practise each scale more than once anyway, I aim to seamlessly join up the different offsets in order to cover all combinations without requiring significantly more practice time:

connecting different hand position offsets

and so on. Actually the hand position “offset” can be changed at any point in the scale, and this is also something I like to improvise on.

Changing the tonality

So far the examples have all used a major scale. The classical tradition also covers harmonic minor and melodic minor (which is different ascending to descending). In the jazz world (especially for more modern jazz), the ascending form of the melodic minor is particularly important, so I practise that in both directions:

melodic minor practice

Jazz also uses the harmonic major scale and many other scales, so I mix some of these into my practice, although I find it easier to spend a few weeks/months focusing on one particular scale rather than attempt to cover all scales in every practice routine, which just seems too ambitious. Incidentally, back in 2013 I built the “Scale Matcher”, a web application to show which scales can be used for improvisation in any given chordal context.

Changing the key

Fortunately not all music in the world is written purely in B♭. Unfortunately this means we have to practise other keys too! I try to change key seamlessly without stopping, because this is one of the most fundamental requirements in jazz for improvising over a series of chord changes. Again I like to avoid any tonic bias by changing key on other degrees of the scale. For example, after completing one cycle of all 3 hand positions in B♭ minor, I could shift tonality up a semitone to B minor, changing near the top of the instrument:

seamlessly changing the key at the top

or on the lowest note of the instrument:

seamlessly changing the key at the bottom

or even somewhere in the middle:

seamlessly changing the key in the middle

This is a fun workout for the brain as well as the fingers!

Hand position “windows”

Above I’ve suggested a system for dealing with the cello’s limitation of not being able to play a continuous scale in any key without shifting the hand, which ensures that every possible fingering of a given scale can be methodically covered during practice.

However there’s a completely opposite approach, which is to embrace this limitation and simply fix your hand in a single position and only play the notes of the scale which you can reach from that position, dropping the others! This is particularly useful when improvising at speed, since it drastically reduces the amount of shifting required. I learnt this idea from three of my all-time cello heroes (Erik Friedlander, Mike Block, and Rushad Eggleston), and then extended it to apply to every scale I work on:

position windows in B♭ minor

I’ve found that improvising within a given “window” can result in some interesting melodic shapes.

Patterns / shapes

Rather than simply ascending or descending, there are an infinite number of patterns to choose from for varying the shapes generated by traversing the scale. Here are a few simple examples:

position patterns in B♭ minor

(The last two were shamelessly stolen from Christian Howes.)

Rhythm / metronome usage

So far I haven’t said anything about rhythm or use of the metronome (which in my opinion is an essential part of scale practice). In fact this topic is so huge I’ll leave it for another blog post at another time! But of course there are an infinite number of ways to vary rhythm, and the western tradition tends not to examine these in much detail. One thing I enjoy doing is freely improvising the rhythm when playing scales, even if everything else (notes, fingerings etc.) is fixed.

Articulation

How to articulate with the bow is another huge topic, but this post is already way too long!

Conclusion

It’s clear that there are zillions of ways to vary scale practice and keep it interesting whilst challenging yourself in new ways. Perhaps the most important thing for any diligent musician is to constantly invent their own new practice systems, rather than just copying someone else’s verbatim.

If you’ve made it this far, congratulations! This is pretty dry reading, but I hope you found it useful or at least interesting. If you have any feedback of any sort, I’d love to hear it, so please leave a comment!

P.S. For the curious geeks, this blog post was created from a single text file with the combination of some incredible free software: the GNU Emacs editor, GNU Lilypond music typesetter, Org mode, org2blog, and the Org-babel-lilypond backend to Babel.

Share

How to build an OpenStack cloud from SUSEcon’s free USB stick handouts

By , December 11, 2014 3:28 pm

Once again, SUSEcon was a blast! Thanks to everyone who helped make it such a great success, especially all our customers and partners who attended.

If you attended the final Thursday keynote, you should have been given a free USB stick preloaded with a bootable SUSE Cloud appliance. And if you missed out or couldn’t attend, download a copy here! This makes it possible for anyone to build an OpenStack cloud from scratch extremely quickly and easily. (In fact, it’s almost identical to the appliance we used a few weeks ago to win the “Ruler of the Stack” competition at the OpenStack summit in Paris.)

Erin explained on stage at a high-level what this appliance does, but below are some more specific technical details which may help in case you haven’t yet tried it out.

The appliance can be booted on any physical or virtual 64-bit x86 machine … but before we start! – if you would like try running the appliance in a VM using either KVM or VirtualBox, then there is an even easier alternative which uses Vagrant to reduce the whole setup to a one-line command. If you like the sound of that, stop reading and go here instead. However if you want to try it on bare metal or with a different hypervisor such as VMware or HyperV, read on!

Continue reading 'How to build an OpenStack cloud from SUSEcon’s free USB stick handouts'»

Share

“Ruler of the Stack” competition, OpenStack summit, Paris

By , November 5, 2014 7:32 pm

Today at the OpenStack summit here in Paris, we continued SUSE’s winning streak at the “Ruler of the Stack” competition :-)

ruler-of-the-stack2-25.jpg

This time, the challenge from the OpenStack Foundation was to deploy an OpenStack cloud as quickly as possible which could withstand “attacks” such as one of the controller nodes being killed, and still keep the OpenStack services and VM instances functional.

It was considerably more complex than the challenge posed by Intel at the Atlanta summit in May which my teammate Dirk Müller (pictured right) won, since now we needed a minimum of two controller nodes clustered together, two compute nodes, and some shared or replicated storage. So this time an approach deploying to a single node via a “quickstart” script was not an option, and we knew it would take a lot longer than 3 minutes 14 seconds.

However as soon as I saw the rules I thought we had a good chance to win with SUSE Cloud, for four reasons:

  1. We already released the capability to automatically deploy highly available OpenStack clouds back in May, as an update to SUSE Cloud 3.1
  2. With openSUSE’s KIWI Image System and the Open Build Service, our ability to build custom appliance images of product packages for rapid deployment is excellent, as already proved by Dirk’s victory in Atlanta. KIWI avoids costly reboots by using kexec.
  3. I have been working hard the last couple of months on reducing the amount of manual interaction during deployment to the absolute minimum, and this challenge was a perfect use case for harnessing these new capabilities.2
  4. The solution had to work within a prescribed set of VLANs and IP subnets, and Crowbar (the deployment technology embedded in SUSE Cloud) is unique amongst current OpenStack deployment tools for its very flexible approach to network configuration.

I worked with Dirk late in our hotel the night before, preparing and remotely testing two bootable USB images which were custom-built especially for the challenge: one for the Crowbar admin server, and one for the controller and compute nodes.

The clock was started when we booted the first node for installation, and stopped when we declared the nodes ready for stress-testing by the judges. It took us 53 minutes to prepare 6 servers: two admin servers (one as standby), two controllers, and two compute nodes running the KVM hypervisor.3 However we lost ~15 minutes simply through not realising that plugging a USB device directly into the server is far more performant than presenting virtual media through the remote console! And there were several other optimizations we didn’t have time to make, so I think in future we could manage the whole thing under 30 minutes.

However the exercise was a lot of fun and also highlighted several areas where we can make the product better.

At least three other well-known combinations of OpenStack distribution and deployment tools were used by other competitors. No-one else managed to finish deploying a cloud, so we don’t know how they would have fared against the HA tests. Perhaps everyone was too distracted by all the awesome sessions going on at the same time ;-)

I have to send a huge thank-you to Dirk whose expertise in several areas, especially building custom appliances for rapid deployment, was a massive help. Also to Bernhard, Tom, and several other members of our kick-ass SUSE Cloud engineering team :-) And of course to Intel for arranging a really fun challenge. I’m sure next time they’ll think of some great new ways to stretch our brains!

Footnotes:

1

Automating deployment of an HA cloud presented a lot of architectural and engineering challenges, and I’m painfully aware that I still owe the OpenStack and Chef communities a long overdue blog post on this, as well as more information about the code on github.

2

The result is a virtualized Vagrant environment can deploy a fully HA environment in VMs from a simple one-line command! It is intended to be used by anyone who wants to quickly deploy/demo/test SUSE Cloud: developers, Sales Engineers, partners, and customers alike. I also needed it for the hands-on workshop I co-presented with Florian Haas of Hastexo fame (slides and video now available), and also for an upcoming workshop at SUSEcon.

3

Once the nodes were registered in Crowbar, we fed a simple YAML file into the new crowbar batch build command and it built the full cluster of OpenStack services in ~20 minutes.

Share

OpenStack Paris workshop: Automated Deployment of an HA Cloud

By , November 1, 2014 7:39 pm

6 months after its debut in Atlanta, the HA workshop happening again in Paris, this Monday (16:20, Room 241)! If you plan on attending and didn’t already see Florian’s blog post, please get downloading and installing the prerequisite files quick, because downloading them over hotel or conference wifi is likely to be painful. (N.B. Unless you have a really strong reason not to, please go with the VirtualBox option, because there are more pitfalls when using KVM+libvirt.)

However if you’re already on the way to Paris, don’t despair, because we’ll also do our best to make the files available at the SUSE booth. And failing that, you can still just turn up, enjoy the show, and then try the hands-on exercise any time later at your own leisure!

In case you have no idea what I’m talking about, here’s some brief history:

Back before the last OpenStack summit in Atlanta in May, I managed to persuade Florian Haas to join me in an endeavour which some might view as slightly insane: run a 90 minute hands-on workshop in which we’d have every attendee build a Highly Available OpenStack cloud on their laptop, from scratch.

With so many moving parts and a vast range of different hardware involved, it certainly wasn’t plain sailing, but by the power of Vagrant and VirtualBox, I think overall it was a success.

Since then, we’ve been working extremely hard to improve the workshop materials based on lessons learnt last time. So what’s new? Well, firstly the workshop environment has been upgraded from Havana Icehouse (SUSE Cloud 4 vs. version 3 in May), and quite a lot of polish has been applied, since in May the HA code was still relatively new.

Secondly, we’ve added support for building the cloud using KVM+libvirt (although VirtualBox is still recommended for a smoother ride).

Thirdly, the documentation is way more comprehensive, and should help you avoid many common pitfalls.

Hope to see you at the workshop, and please come and say hello to us at the SUSE booth!

Share

managing your github notifications inbox with mutt

By , October 5, 2014 1:59 pm

Like many F/OSS developers, I’m a heavy user of GitHub. This means I interact with other developers via GitHub multiple times a day. GitHub has a very nice notifications system which lets me know when there has been some activity on a project I’m collaborating on.

I’m a fan of David Allen’s GTD (“Getting Things Done”) system, and in my experience I get the best results by minimising the number of inboxes I have to look at every day. So I use another great feature of GitHub, which is the ability to have notification emails delivered directly to your email inbox. This means I don’t have to keep checking https://github.com/notifications in addition to my email inbox.

However, this means that I receive GitHub notifications in two places. Wouldn’t it be nice if when I read them in my email inbox, GitHub could somehow realise and mark them read at https://github.com/notifications too, so that when I look there, I don’t end up getting reminded about notifications I’ve already seen in my inbox? Happily the folks at GitHub already thought of this too, and come up with a solution:

If you read a notification email, it’ll automatically be marked as read in the Notifications section. An invisible image is embedded in each mail message to enable this, which means that you must allow viewing images from notifications@github.com in order for this feature to work.

https://help.github.com/articles/configuring-notification-emails/#shared-read-state

But there’s a catch! Like many Linux geeks, I use mutt for reading and writing email. In fact, I’ve been using it since 1997 and I’m still waiting for another MUA to appear which is more powerful and lets me crunch through email faster. However mutt is primarily text-based, which means by default it doesn’t download images when displaying HTML-based email. Of course, it can. But do I want it to automatically open a new tab in my browser every time I encounter an HTML attachment? No! That would slow me down horribly. Even launching a terminal-based HTML viewer such as w3m or links or lynx would be too slow.

So I figured out a better solution. mutt has a nice message-hook feature where you can configure it to automatically execute mutt functions for any message matching specific criteria just before it displays the message. So we can use that to pipe the whole email to a script whenever a message is being read for the first time:

message-hook "(~N|~O) ~f notifications@github.com" "push '<pipe-message>read-github-notification\n'"

(~N|~O) matches mails which have the N flag (meaning new unread email) or O (meaning old unread email) set.

The read-github-notifications script reads the email on STDIN, extracts the URL of the 1-pixel read notification beacon <img> embedded in the HTML attachment, and sends an HTTP request for that image, so that github knows the notification has been read.

This means an extra delay of 0.5 seconds or so when viewing a notification email, but for me it’s a worthwhile sacrifice.

If you want to try it, simply download the script and stick it somewhere on your $PATH, and then add the above line to your ~/.muttrc file.

Share

Panorama Theme by Themocracy