ntoll.org

My last post resulted in the following question from John Erickson.

“I’ve only just discovered FluidDB and the reoccurring question is, ‘how is FluidDB different/better than CouchDB??’”

I’ll try to answer as best I can.

The usual caveat applies when using a loaded word like “better” – it depends on what you want/need. As I can’t speak for anyone else I’ll only do a compare and contrast.

Lets concentrate on the similarities first… both databases are flat collections of items (“documents” in CouchDB, “objects” in FluidDB) with a structure based upon the classic subject/predicate/value triple:

CouchDB: Documents have fields with values.
FluidDB: Objects are tagged (often with values)

Documents <=> Objects (both are identified by a UUID),
Fields <=> Tags (both are dynamically typed),
Values <=> Values

A simple difference in terminology.

(Actually, in FluidDB an object/tag pair does not need to have an associated value. Simply associating a tag with an object can provide enough information. For example, the object that represents the book Dune might have the “ntoll/has_read” tag associated with it and as I am the only person within FluidDB to have permission to associate this tag with objects you can infer from the name of the tag that I once read the referenced book. I’m getting ahead of myself here, but it’s important to point out that a tag-value is optional in FluidDB.)

The other obvious similarity is that both DBs have a RESTful API (hence the potential for CouchApps and Flow – web-applications as data hosted within their own database).

Now for the differences in no particular order:

1. There is only one FluidDB floating “up there” in the cloud and it holds everyone’s data. With CouchDB companies and individuals are responsible for hosting their own instance(s) and such instances are usually created for a specific purpose/application.
2. The predicate part of the triple is very different. Fields in CouchDB are simply names of values. In FluidDB tags can be organised with namespaces. You start with an empty root namespace named after your username and create tags and namespaces underneath this. Just to be clear here, you can’t associate an object with a tag that isn’t yet defined – and yes, tags and namespaces are also objects in FluidDB so you can meta-tag. ;-)
3. Querying data is very different. CouchDB’s “Views” are pre-defined map/reduce based algorithms. FluidDB provides an uber-minimalist (yet still evolving) SQL-like declarative language.
4. Security and permissions in CouchDB are document centric and define who can read data and what validation steps a user needs to pass before they can write data to a document (CouchDB also has the concept of an admin account). The “model of control” (as Terry Jones [creator of FluidDB] calls it) is FluidDB’s killer feature: permissions apply only to tags, namespaces and tag-values. All objects are public and can be tagged by anyone.

The implications of point four are not at first obvious but it is definitely this feature that sets FluidDB apart from CouchDB and every other database that I know of. Because of this I’ll spend the rest of this post illustrating why the model of control is so important.

Because all objects can be tagged by anyone lots of interesting information/behaviour begins to emerge and become possible.

Remember the “Dune” example? Because only I have permission to associate the “ntoll/has_read” tag with an object you can be pretty certain only those objects with this tag have been read by me. I can also control who sees my tags, their values and even allow other trusted users the ability to add, edit, and delete namespaces, tags and tag-values (in a similar way to being able to set permissions on a filesystem). This is important because it allows people to collaborate: users who are food enthusiasts could all agree to use the “foodies/rating” and “foodies/review” tags on objects representing restaurants. Only those users enthusiastic/trusted enough would be allowed into the group with permission to associate such tags. Furthermore, as “insiders” they might also have created a tag called “foodies/discount” that is only visible to them and, when attached to an object representing a restaurant, explains how to get a discount.

Even though some objects have an optional “fluiddb/about” tag (holding a unique value and set by the object’s creator to provide some guidance as to what the object is supposed to represent) the only way to find out what an object really represents is to look at what tags and values are associated with it. The tags and associated values cast an outline of a sort of “data-shadow” identifying the object’s referent.

For example, the object with the fluiddb/about tag-value “book:DUNE” might have the following subset of tags/values associated with it:

{
fluiddb/about: "book:DUNE",
ntoll/has_read, 
tim_oreilly/has_read, 
amazon.com/type: "Paperback Book",
amazon.com/title: "Dune", 
amazon.com/author: "Frank Herbert", 
amazon.com/isbn: "ISBN123456789", 
amazon.com/price: "$9.99", 
amazon.com/genre: "Sci-Fi", 
amazon.com/cover: (BINARY DATA FOR A PNG FILE),
tom/comment: "I really like the Sandworms", 
dick/opinion: "Far fetched and obtuse", 
sally/rating: 5,
books/other_editions: ['UUID for object x', 'UUID for object y', 'UUID for object z'],
books/isbn: "ISBN 123456789",
books/title: "Dune",
books/author: ['UUID of object representing Frank Herbert']
books/publisher: "Chilton Books",
books/first_published: "1965"
...
} 

Now, consider the following:

• In the same way that #hashtags and @username conventions have emerged on Twitter so conventions such as “username/has_read” will emerge within FluidDB (for example). I use it because a well known publisher of tech books might use it, along with many other people. Put simply, the schema of FluidDB evolves.
• Organisations that can verify they own a domain name can claim it as a root namespace within FluidDB. As a result Amazon has tagged the book with useful information.
• Tag values do not have to be strings… they can be anything and the mime-type used when HTTP PUTting them into FluidDB is what is used when retrieving them. As a result, the amazon.com/cover value is an image/png file (presumably of the book’s cover). Actually there are two types of tag value: primitive and opaque – the difference is explained here (put simply, you can search against primitive values).
• The tags from the “books” namespace provide lots of useful information, much of it the same as that provided by amazon.com.
• The books/other_editions tag-value is a list of UUIDs identifying other objects related to this one in a similar way to how foreign keys are used to reference related tables/rows in relational databases.
• Lots of different people, organisations and applications have added tags to the object.
• I’ll never see some of the tags associated with this object because I don’t have permission to.
• If Amazon.com decide to delete their tags from this object it is still useful and all the other data is unaffected.

Another side-effect of the FluidDB model of control is that completely unrelated applications will be able to share data. This is already happening: Terry has written an application called Tickery that has imported lots of information from Twitter under the “twitter.com” namespace in FluidDB. Because this data is open for everyone to read I can make use of it from within Flow and carry out exactly the same searches as Tickery does (e.g. “has twitter.com/friends/jack and has twitter.com/friends/ev”).

Suddenly the potential for mashing up data becomes huge and very interesting – especially as anyone can add further data to the objects Tickery and Flow have tagged.

In conclusion, we’re all familiar with social networks – FluidDB is simply a social database ‘in the cloud’ with its model of control as the secret magic sauce.

Since the end of last year I’ve been spending quite a lot of my spare time experimenting with FluidDB as a platform for web-development. The result is a still incomplete application that I call Flow (the source-code is hosted on GitHub).

Flow is a simple “show and tell” project to demonstrate how to write small javascript based applications for interacting with FluidDB. The aim is for Flow to become an application for writing javascript based applications with FluidDB.

I’ll let you pause a minute while you work out the circularity of that last sentence. ;-)

To make things clearer I’ve cobbled together a short screen-cast that attempts to demonstrate what I’ve been up to. (It’s very rough and ready, but you’ll definitely get the idea.)

As I mention in the screen-cast, Flow makes use of the Sammy javascript framework, a modified jsFluidDB script, jQuery and FluidDB
itself (for hosting and data storage).

It’s VERY incomplete, hardly tested properly, extemporised (rather than designed) and needs a lot of TLC – just a proof of concept really. Nevertheless, as the video demonstrated, you can:

• Sign in/out
• View, create, edit and delete namespaces/tags
• Edit tag values for mime-types text/* in all browsers and the ability to do the same for image/* and application/pdf and application/vnd.ms-powerpoint values in Firefox version 3.0 and above (more on this later).
• Search for objects using the simple query language that comes with FluidDB.

To use it properly you’ll need to register for a username and password here:

http://fluidinfo.com/accounts/new

Here are some of the development highlights…

FluidDB as a Server

Lets just remind ourselves of how FluidDB is organised from the point of view of data / schema:

1. Objects represent things in FluidDB.
2. Users define attributes to attach to objects – these are tags that can be organised with namespaces.
3. When a tag/attribute is associated with an object it can (optionally) hold a value.
4. The value of a tag/object association can be anything but you can (optionally) specify a mime-type for each value.

This is all we need to understand for now. (FluidDB’s “killer feature” is actually its permissions system and the implications thereof. It is so important that I’ll save that topic for its own blog post later. But one step at a time…)

So how does FluidDB act as a web-server..?

Simple really (and apologies if this is too simple an explanation – I don’t like to assume too much technical expertise)...

Remember that FluidDB is RESTful in that its API is exposed through the HTTP protocol (y’know, that thing the World Wide Web is built out of). So, if I want to retrieve the value of a tag/object association I simply HTTP GET a URL – just like a web browser does for web-pages.

So how about I create an object to represent my web-application, add a bunch of namespaces and tags that map to the names of the files and directories needed for the application to work and then associate these tags with my application’s object? Of course, I make sure the tag/object values are the contents of the files and that the mime-types are set properly (e.g. values for tags mapping to .html files have the mime-type “text/html”).

This means that if a browser does an HTTP GET request to the path for a tag/object value within FluidDB and the mime-type for the value is set to “text/html” it’ll display it as a web-page. The same goes for javascript (application/x-javascript), CSS (text/css), images (image/*) and anything else (application/pdf for example).

Hey presto… FluidDB is a universal web-server.

Sammy.js

So we have a server for our application, but FluidDB doesn’t allow any server-side scripting. This means we need to put our application’s logic somewhere else – the only other place being on the client’s browser.

Happily, we can use a browser’s Javascript capabilities for this and doing so is not so much a leap as other well-known web-applications already do this (GMail, Google Docs, Zoho and so on).

What is more, the guys in the CouchDB project have been thinking along similar lines for a while and Aaron Quint has developed a javascript framework for browser-side web applications called Sammy.

Sammy is a tiny javascript framework built on top of jQuery. Because of a clever “hack” it is able to “trap” GET and POST requests from a page and handle them with javascript functions associated with “routes”. It’s certainly packed full of features for such a small application and I’ve been hacking away with a maniacal grin on my face as I’ve been exploring Aaron’s work.

If you’ve still not figured out why this is important, take a look at these two images Aaron has created (extracted from this presentation and used with permission) to show the difference between “regular” web-application development and that promoted by CouchDB and (now) FluidDB:

Sammy allows us to live in a Lisp like “code is data” world with no web-server / web-framework playing piggy-in-the-middle. The database is the server and the framework is Sammy-as-data running on the client.

HTTP PUT, Forms, Mozilla & Binary Data

In order to create or update a tag on an object the API requires a PUT request containing the appropriate value. Unfortunately, if the data we want to send is not text based we have a problem.

The usual way to upload binary data is to use an HTML input element with the “type” set to “file”. Unfortunately, forms can only use the POST and GET HTTP verbs (this seems an amazingly bad decision – surely they should only support POST and PUT..?).

Rather than change the whole Internet I investigated how to get at the raw data from the request with Javascript and re-frame it as a PUT request to FluidDB. It turns out this is impossible except for users of Firefox.

Since version 3.0 (or 1.9 of the Gecko engine that Firefox uses) it has been possible to do this with the getAsBinary() function. In fact Mozilla have also provided the rather useful getAsDataURL() and getAsText() functions too. These are definitely non-standard and more information about them can be found on Mozilla’s website.

You can see how I did it by looking at the “upload_to_mozilla” function in the tag_value_app.js file in the javascript directory/namespace.

Unfortunately, this means I’m stymied for the other browsers and I’m not sure of the best solution. Of course, extracting textual data from a form is easy on all browsers so this only affects binary data. Nevertheless, it’s a problem that probably should be solved if such database-hosted applications become popular.

That’s all (for now)...

I’ll keep plugging away at Flow and will post updates on Twitter.

I also have to give a presentation in March at ThoughtWorks in London about FluidDB. I was thinking… it might be fun to create a “presentation” application with FluidDB and Sammy. Something along the line of DOM slides, AJAX-S or S5.

Who knows… it might actually be useful…

Oh, hang on… some guy called Aaron Quint has already done it with CouchDB.

;-)

Last night was the fifth London Python Code Dojo. At the end of the December dojo we agreed to try a different format: a well defined problem to be tackled concurrently by small teams who have a pre-defined amount of time to complete it in (about an hour). This would be followed by a show and tell / compare and contrast session.

We hadn’t decided on a problem before the dojo so we chose to follow a suggestion made at an earlier dojo. A white-board was provided for attendees to write up suggestions during the pizza / beer part at the start of the evening.

This seemed to have worked well and a consensus was reached to write an “old skool” style text-adventure game over the course of the next few dojos.

Why..?

Well, a classic text-based adventure game contains lots of opportunity to practice and experience different aspects of computer-science / programming. I can think of the following problems off the top of my head:

• Build and navigate a game world (a directed graph?)
• Represent and facilitate in-game objects / puzzles (e.g. “kill Grue with sword”)
• Build a parser for interpreting player’s commands
• Represent, control and validate game state
• NPC Artificial Intelligence / NLP (NPC = Non-player characters, NLP = natural language processing)
• Client / Server / Multi-user support (a la MUD / MOO – perhaps using Twisted?)
• Make a UI to display images and other multi-media

Last night we attempted to build and navigate a game world. The fruits of our efforts can be found here on GitHub.

Happily, the team based format worked exceptionally well affording more people the opportunity to write code and solve the problem. Furthermore, Dave Kirby kicked off the evening with a lightning talk about using CRC cards in small-group development teams – rather appropriate given the context. Thanks Dave!

The most entertaining part of the evening (for me) was the “show and tell” conclusion. Each team was given the use of the projector and five minutes to demonstrate the game, show their code (and tests!) and talk through their design and methodology. It was fascinating (and funny) to see how differently the teams had tackled the problem (four out of five had working examples) – yet there were also many similarities. Highlights included a solution created entirely through TDD, fancy-pants autocomplete courtesy of the CMD class, a solution that separated game data from the game engine and had its own (proprietary) file format and a game with some very imaginative writing, pirate voice overs and a very large octopus.

Great fun!

People have posted comments and photos on Twitter and Bruce Durling and Andy Kilner have also blogged about the event.

The next dojo is on the 4th February. Details can be found here: http://ldnpydojo.eventwax.com/6th-london-python-code-dojo

On Tuesday and Wednesday of this week I attended droidcon, the Android developer’s conference organised by the friendly folks at Skills Matter and Kevin and Carl from Novoda – the most enthusiastic mobile software development company on the planet.

Tuesday was a barcamp and a great opportunity to meet people and learn from others. I especially enjoyed Carl’s talk on his work using RESTful APIs from Android (something I’ve been experiment with in conjunction with FluidDB). Other highlights of the day included learning about the Zii Egg and recently announced Trinity device, seeing the worlds longest nested if/else statement (don’t ask – very diagonal) and some really great chats both technical and “blue sky” about the potential for mobile (and specifically Android) devices.

The second day was a more traditional presentation-based conference and we had some great talks. Highlights for me were a couple of presentations that delved into and demonstrated the NDK (native development kit), both of which were musical in nature (spot on for me) and had me dusting off my C/C++ books when I got home. I was also amazed by what Gabor Paller had managed to achieve with his Dedexer tool for Dalvic byte-code disassembly. The “park-bench” and Yan Minagawa’s talk about the future of mobile were particularly entertaining for the group discussion that ensued, and I’d never heard of the c-base space station that had crashed into the heart of Berlin – it sounds an awesome place. Finally, Diego Torres Milano’s talk on test driven development on Android was something I was especially pleased to see on the programme. I advocate and use TDD in my day job (and at the code dojo) – so it was great to learn how to do it on Android.

As always, some of the best stuff was in the chatting over pizza / drinks and in the intervals. Lots of cool pointers and advice as well as a sneak preview of Motorola’s “Droid”.

Great job guys and I’m looking forward to the next one…

(If you can’t wait there is always the Londroid group whose next meeting is on 21st January – I’ll be there).

This is an introduction to musical theory that I wrote as an appendix to my MSc dissertation (a summary of which can be found in my post about computational creativity with evolutionary algorithms). The language is quite formal but I’m still quite pleased with what I wrote and how much information I managed to compress into just short of 2500 words.

It assumes no prior musical training or knowledge and aims to provide enough information so that the reader is able to appreciate the aims, machinations and processes involved the article referenced above. So without further ado…

Music consists of many different dimensions. The two of primary concern for this article are pitch and duration:

Pitch

Pitch refers to the frequency of the sound of a note. The higher the frequency the higher the note sounds. In the western tradition specific pitches are given letter names in repeating groups called octaves. Thus, the note ‘A’ in the middle octave of a piano keyboard has a pitch of 440 hertz (oscillations per second). The note ‘A’ in the octave directly above has a pitch of 880 hertz whereas the ‘A’ in the octave directly below is pitched at 220 hertz. As one might guess from the example above, the different pitches used in western music are based upon mathematical relationships first discovered over 2,500 years ago by the Greek philosopher Pythagoras.

Pitches are represented on what one might analogise as a musical ladder. There were originally eleven ‘rungs’ on this ladder with pitches being represented on or between the rungs as shown in the image below. As one draws notes higher up the musical ladder so the pitch being represented sounds higher.

Eleven lines (rungs) were used to represent pitches

It was found that such an abundance of lines made the musical representation difficult to follow so the eleven lines were split into two groups of five lines with the middle line being replaced with a gap. Today, when the pitch that was represented by the absent middle line is required the note has a ‘ledger’ line, specific to itself, drawn through its middle. This ‘middle’ note, to this day, is called ‘middle C’ because it was the note ‘C’ that was represented by the middle of the eleven lines.

The resulting five ‘rung’ musical ladder is called a stave. To differentiate between a stave representing the higher or lower halves of the original eleven-line ladder, two clefs – the treble and the bass – are used (clef can literally be translated as “key”; try to think of it as a key to a code rather than a key to a door). A stave starting with a treble clef represents the top five lines of the original eleven (and thus the higher pitches), whereas the stave starting with the bass clef represents the bottom five (the lower pitches). The image below shows the same musical information as the previous illustration but using the two stave representation and with the letter names of the notes added.

Two staves with the treble and bass clefs, notes and note names

Often, the gap between the staves is made wider to further enhance readability. A curly bracket (brace) often joins these staves, indicating some form of relationship. (For example, the above illustration implies a single instrument represented over two staves).

Pitches that lay outside the top and bottom of the musical ladder are, like middle C, represented with ledger lines that allow one to imagine how the musical ladder might be extended higher or lower. The image below demonstrates all the features discussed so far.

An example of all the pitch related features discussed so far

The only pitches represented so far have been those that are playable on the white notes on a piano keyboard. In order to be able to understand how one represents the black notes the concepts of tone and semi-tone need to be explained:

A semi-tone is the smallest unit of distance between adjacent notes on a piano keyboard, irrespective of them being white or black notes. Thus, if one were to play all the white and black notes on a piano keyboard in ascending order one would be playing in jumps of a semi-tone.

A tone is simply the same as two semitones. Hence, the distance between two white notes, with each of them adjacent to a common black note, is a tone. However, some of the white notes do not share an adjacent black note so the distance between them is only a semi-tone. These points are demonstrated below.

Tones and semi-tones shown on a piano keyboard

Notice that the black notes are denoted by two different names: the name of the note pitched a semi-tone below with a sharp (♯) sign next to it, or the name of the note pitched a semi-tone higher with a flat (♭) sign next to it. One raises the pitch value of a note by a semi-tone by ‘sharpening’ it and lowers it by a semi-tone by ‘flattening’ it. Thus, the black note between ‘C’ and ‘D’ can be described as both ‘C-sharp’ and ‘D-flat’. In addition, one could legitimately rename the note ‘C’ as ‘B-sharp’ and denote the note ‘E’ as ‘F-flat’. In musical parlance the sharp and flat signs are known as accidentals. Furthermore, the convention of nominating an identical pitch in two different ways (such as ‘B-flat’ and ‘A-sharp’) is described as being enharmonic; i.e. the pitch remains the same but the note name is different.

When showing accidentals on the stave one merely precedes the note whose pitch value one wants to modify with either the sharp sign (for raising the note by a semi-tone) or the flat sign (when lowering it by the same amount). Furthermore, if certain notes are always modified by accidentals due to the key (see explanation below) the accidentals are placed at the start of every stave, before any notes, to act as a reminder. These groups of ‘reminder’ accidentals are called the key signature. In addition, if one wanted to return one of the notes that was modified in the key signature back to its ‘natural’ status (i.e. white note) one merely places a ‘natural’ accidental sign in front of it: ♮. This is all demonstrated in the illustration below:

An example of a key signature and accidentals in use

A note about keys: The key is merely the name given to a collection of notes defined in a scale. Music is written in ‘keys’ (i.e. the music will only use notes taken from the scale that defines the key). A scale is a collection of notes that are derived from their relationship to the ‘tonic’ (the first note of the scale) and are commonly described through the tone or semi-tone steps between the various notes. For example, if T=tone and S=semi-tone then the steps between the notes in the common ‘major’ scale can be described thus: TTSTTTS. So, if one were to start on the note ‘C’ (the tonic) one could work out the scale of ‘C-major’ by following the TTSTTTS formula. If you were to try it you would find that the resulting scale consisted of only the “white” notes on a piano keyboard though scales usually contain a mixture of “white” and “black” notes. Scales can start on any note but by following the same formula; recognisably “right” scales will result. Most scales consist of eight notes though numerous tone/semi-tone step permutations exist that describe many different eight note scales that are called ‘modes’. (It is interesting to note that Pentatonic scales have only five notes and the Blues scale can have more than eight)

We are now in a position where the pitch of a note can be represented with enough accuracy for the purposes of understanding basic musical theory. However, notes do not merely consist of a pitch. The other essential dimension that describes a note is that of duration.

Duration

Duration describes how long the note lasts through time. A collection of durations make up a rhythm.

The duration of a note is described by what can be thought of as fractions of a whole note. In western music theory a whole note is represented by a single hollow round note worth the value ‘1’ that is given the name ‘semibreve’.

Further notes of shorter duration values are obtained by cutting the preceding largest note duration in half. So, by splitting the duration of a semibreve in half one obtains two ‘minims’. A minim is worth the value of a half (½) and is represented by a hollow round note with a stick attached.

Furthermore, halving a minim produces two ‘crotchets’. A crotchet lasts exactly half the duration of a minim and, consequently, a quarter of a semibreve’s duration. Crotchets are also called quarter-notes and are represented by a filled in round note with a stick attached.

Other subdivisions produce ‘quavers’ (or eighth notes) and ‘semi-quavers’ (sixteenth notes) that are represented by filled in round notes with a stick and either one tail (for the quaver) or two tails (for the semi-quaver).

Both quavers and semiquavers can be grouped together to aid readability. This is achieved by ‘beaming’ together the tails of the notes.

In addition, to further aid the readability of the music the stick attached to the body of a note can point either up or down. If the note is below the middle of the five lines of the stave then the stick usually points up, if the note is above the middle line the stick points down and if the note is on the middle line the person writing the score uses their discretion as to what looks best in the context.

Often, silences are required in a piece of music. These conform to the same values as the note durations described above but are represented by special symbols that denote a ‘rest’. The table below demonstrates all the features related to duration covered so far:

The representation of note duration, silence and grouping

However, how does one represent a duration that is three quarters (as opposed to half) of next largest note? This is achieved through the use of the ‘dot’ which, when added after a note, increases its length by half. Thus, a dotted minim is worth three crotchets or three quarters of a semibreve. This is how it is done:

Dotted notes and relative values

Furthermore, to make navigating the piece of music easier, durations are grouped into fixed-length groups called ‘bars’. One might think of bars as ‘bite-size-chunks’ that enable one to easily digest the music. The length of a bar is defined in terms of the number of beats of a particular duration. This definition is written at the start of the piece of music and is called the ‘time signature’.

The time signature consists of two numbers arranged vertically so they look similar to the expression of a vulgar fraction (although they express different information and the time signature has no line separating the numbers). The top number gives the number of beats in a bar. The bottom number denotes the duration of the beats. The bottom number is directly related to the value of the durations encountered before. Thus, if the bottom number is a ‘1’ then the beats are the length of a semibreve whereas if the number is a ‘2’ then the beats are the length of a half note (minim). A ‘4’ denotes quarter notes (crotchets), an ‘8’ eighth notes (quavers) and so on. The most common time signature is four crotchet beats in a bar, also shown as 4/4 and spoken out loud as “four four”. The picture below provides some examples and explanation:

Examples of different time signatures

The contents of a bar are shown between bar lines that are simply a single vertical line. A double bar line denotes the end of a section or piece of music.

It is vital to realise that the sum total of the duration values of the notes in any given bar will be exactly equal to the duration value expressed in the time signature. For example, the bars defined with a ‘4/4’ time signature must contain durations whose sum equals the duration of exactly four crotchets. Furthermore, if the time signature is ‘3/4’ (three crotchet beats) then a semibreve (that is worth four crotchet beats) cannot be used as it exceeds the length of the duration of the bar.

Finally, if one wants to have a note whose duration spans a bar line then one joins notes of the appropriate value together with a ‘tie’, a curved line reaching from one to the other. The following example demonstrates all of the above points:

Ties, bar lines and the sum of durations

Now that both pitch and duration have been explained it is possible to combine them in the following extract from J.S.Bach’s The Two-Part Invention No. 9 in F minor.

Counterpoint by J.S.Bach

An important point, that can only be made when both pitch and duration elements have been combined, is that accidentals last for the duration of a bar. Thus, in bar four, the third note in the treble stave is denoted a ‘D-natural’. Three notes later there is another ‘D’ that is still a natural because the end of the bar has not been crossed. Were there to be a ‘D’ of that pitch in the next bar it would return to the value of ‘D-flat’ as defined in the key signature unless it had itself been modified by an accidental. Furthermore, notice how both the durations and pitch line up properly so, for example, four semiquavers take up the same ‘width’ as a single crotchet (a crotchet is the same duration as four semiquavers) and pitches represented with ledger lines are consistently spaced apart.

Counterpoint

The above extract from Bach is a good example of what is meant by ‘counterpoint’. The term comes from the Latin punctus contra punctum (note against note) and describes a piece of music where two or more contrasting melodies are combined; it is to be hoped, with pleasing results. The piece by Bach consists of two parts (one each in the treble and bass staves) in ‘free’ counterpoint. If played on their own each part would be an individual melody in its own right. However, it is because of the way that the melodies have been cleverly composed that they can fit together and complement each other. Bach is famous for writing counterpoint of great beauty and complexity with up to six separate parts (‘part’ is used synonymously with melodic line) playing together.

Nevertheless, such complexity is dwarfed by the works of earlier composers such as Palestrina, Gabrielli and Monteverdi who were regularly writing music with sometimes eight, sixteen (or even more) parts working in counterpoint. The most famous example of this contrapuntal ‘overkill’ is ‘Spem in Allium’ by the English composer Thomas Tallis. He wrote this piece for eight five part choirs resulting in, at times, forty separate parts working in counterpoint. Nevertheless, it must be pointed out that the melodic writing of these composers was simpler than that of Bach. As a rule of thumb, the more complex a melody becomes the harder it is to make it work contrapuntally.

Thus, we arrive at the crux of the matter. The composing of counterpoint is not based on fortuitous chance melodic combinations, nor is its practise restricted to only those possessing musical genius. Rather, it is the result of applying specific rules and guidelines. In other words, it is a skill that can be learned. The most famous means of teaching counterpoint is that developed by Johann Joseph Fux and explained in his dialogue ‘Gradus ad Parnassum’.

Conclusion

It is at this point that I went on to explain how the rules of species counterpoint work. Happily, a version of this next appendix is also available on my blog: Species Counterpoint

Once armed with the knowledge the board for my MSc dissertation in Computing were in a position to understand why I wanted to use genetic algorithms to compose counterpoint, as described in the blog post referenced earlier concerning computational creativity.

As always, comments, suggestions and feedback is most welcome. I hope you’ve found this useful!