Following on from the previous post, we now move on to Data Formats and Data Generation.

The system can play music in up to 8-part harmony, equivalent to 8 separate parts or voices in a choir, and keeps track of the current status of each part. The numerical data for each piece of  music are arranged in groups to represent events at successive points in time. Each event usually involves changing the note being played by any one or more of the parts, including muting any of the parts. Following are some examples of three typical events:

• Starting at address 193 is the Data Group for a chord, duration 21 time units.
• The Control Byte at 194 has value 180 = &B4, which has 4 bits set (7, 5, 4, 2).
• The voices corresponding to bits (6, 3, 1, 0) will remain unchanged, whatever their previous states.
• Address 199 holds value 131 = &83, which represents a mute of all voices, duration 3 time units.
• Address 200, 201 hold the sequence 00, 08 which represents the bar line at the start of bar 8.

The data group for each event begins with a Duration Parameter, D, a 6-bit number in the range 1 to 63 which defines the length of time that the note or chord in question is to be sustained.

The default value of D is 24 units for a crotchet, 12 for a quaver, etc., although these values are arbitrary – but the inclusion of a factor of 3 facilitates the rendering of triplet rhythms when required.

Next comes an 8-bit Control Byte which acts as a mask defining which part or parts are to be changed. This is followed by a list of N numbers, each in the range 0 to 54, representing the notes to be played. N is the number of set bits in the mask and the sequence of note-numbers defines to which parts they are allocated.

The note value zero indicates that the relevant voice is to be silenced. A Duration Parameter in the range (1 to 63) + &40 indicates that the previous chord is to be maintained unchanged for a further period of time (a tie). A parameter in the range (1 to 63) + &80 heralds a mute, a period in which all parts are to be silenced.

A Duration Parameter of zero represents an Escape Code which is followed by at least one further byte. If this next byte is a number in the range 0 to 240 (&F0) it indicates a bar number in the music – this is ignored by the playing program but is an invaluable aid to editing the data. Values from &F1 to &FF invoke various special functions and may be followed by additional bytes. These functions include setting the Tempo Parameters, marking the beginning and end of repeated passages, implementing octave- and pedal-coupling facilities and marking the end of the piece.

Generating The Data

In the early days, the data lists were compiled and entered into memory manually, which was extremely tedious even for short and simple melodies. Around the same time, Dad was writing a PC-based program originally designed merely to print music in a legible form, and it occurred that it might be possible to combine these two problems. Now, generation of the data begins with a Project in Visual Basic running on a PC under Windows 98. Please stop laughing, there are good reasons for using this ancient machine!

[Left - the PC-based Visual Basic screen for inputting music - very much "me-ware"! - click image for bigger version if you dare]

The programme initially displays a pair of blank staves, plus, in the case of organ music, an additional stave to show the pedal part. Notes are inserted by a series of mouse-clicks to build up a single line of music.

The information displayed is stored in memory merely as the note-values and their co-ordinates on the staves, and each line of music can be saved as a .DAT file. No bit-image files are involved.

The N lines of music  required for a given work can be printed out for future reference. The filename for each line of music is constructed from the file-stem, Plus the bar number at the start of that line, thus Bday1.DAT and Bday5.DAT.

About The Voices

The treble clef (normally played by the right hand) contains the Soprano part (tails up). Alto (tails down) and an extra intermediate part (X, with no tails).

Similarly the next stave down (bass clef, normally played by the left hand) supports Tenor (tails up). Bass (tails down) and an additional part (Y, no tails).

When the music has been compiled the order of parts as shown in the Control Byte is from most to significant bit to least: S, X, A, T, Y, B, P, Q. The lower bass clef, where used, is played by the pedals and can contain two parts, tails up (P) and down (Q).

Compiling & Editing The Data

Visual Basic and Windows can now be closed and a compilation program loaded in GWBASIC under MS-DOS. Details of the file-stem (Bday), bar numbers (1, 5) and Folder (Happy) are entered, together with an estimate of the required metronome value in crotchet beats per minute. The compiler then reads each if the .DAT files in turn and processes them into the format required by the BBC program. The complete data list is saved as a .BIN file, e.g. 8HBDAY1.BIN , indicating 8 parts (and 7+ext file name).

[Left - raw data Editor on the PC - click image for bigger version]

Control is now passed to a second program in GWBASIC. This enables the data to be edited and any errors and omissions corrected. In this 8-part PC editor two lines of data, comprising 32 columns or events, can be displayed. Note that a line of displayed data does not as a rule correspond to a line of the printed music.

Various features of the data are indicated by their colours: green (decimal) numerals indicate memory addresses at which the data for each event begins. Red (decimal) numerals are the Duration Parameters. Pale blue (hexadecimal) numbers are the Control Bytes, and the white characters define the note letters and the octaves in which they are situated. The usual range of organ music is from two octaves below middle C (C1-B1, and C2-B2) to two and a half or three octaves above (C3-B3, C4-B4a and C5-F5 in this case).

Pressing any key at this stage of the display causes the lower line of 16 columns to be erased and replaced by cues and space for input statements to make any changes [right - click image for bigger version].

Phrasing in organ music is achieved solely by small adjustments to the duration of selected chords and by short gaps inserted between them. The data as initially compiled will often sound rather bland and boring but can be made to sound more realistic by careful editing at this stage. In particular it is the custom to increase the length  of the first note in each bar by one unit, a process carried out automatically by the compiler.

Transferring The Data

[Left: the equivalent Editor on BBC Micro - click image for bigger version]

After the data has been edited it is wise to save it to a different filename, e.g. 8HBDAY2.BIN

A further GWBASIC program is then invoked to transfer the file over a parallel cable to a BBC where it is received and saved by another program. There is also a BBC data editing program but due to memory space constraints it is very limited in scope compared to the PC version & can display only 10 cols or events at a time. The data, now on a lovely old BBC floppy disc, can be taken to the church to be tested on the organ. If necessary, final adjustments can be made there using the BBC editor.

So Why Bother?

In typical geek fashion, the project was originally undertaken to test an idea and see if it could be done. After a few teething troubles were ironed out it has proved extremely versatile and reliable and appears to be capable of playing almost any organ music that can be rendered on a single-manual instrument. It just requires sufficient time and patience in setting up and editing the data.

It now plays most of the voluntaries in the weekly service and has even been used for an evening’s organ recital, raising money for charity. With the aid of a computer-literate assistant, it has occasionally been used to accompany the hymn singing when no organist (Dad) has been available. However, setting up the files for 5 hymns is no trivial task since each verse may need to be differently edited for correct phrasing due to different words.

Ernie Performs!

And now for a short recital… (use http://cazm.eu/ernie3u as a shortcut):

Afterthought

I have often wondered if, instead of spending so much time designing hardware, software and inputting data to the system, Dad had spent the time practicing the organ tunes in the first place, he would be able to play them himself! But that would not have been half the fun!

Further Reading

For more details, see Part 1 (Intro) and Part 2 (Machine Control).

The Switching Circuit in Parallel

[Right: Transistor Switching for each Note - click image for bigger version]

The analogue switching circuit for each note looks like this:

A 1-bit data latch stores the value of each note, ON or OFF.

The LEDs were originally provided to facilitate trouble-shooting at the development stage, but now provide entertainment for interested spectators! It will be noted that the components are grouped to correspond to the layout of keys on the keyboard:

A Quick Demontration!

Here is a short video showing the switching boards whilst the organ plays a familiar tune… (use http://cazm.eu/ernie2u as a shortcut):

Addressing The Latches

[Left: Buffers Latches for 1 Note - click image for bigger version]

The diagram of a sample latching circuit is shown below – there are 4 latches per chip, but there are only two clock lines, each one clocking two latches.

So each latching operation requires two bits distributed via a network of 74LS04 inverting buffers to provide the necessary fan-out.

[Right: Part of CLK Routing Circuit - click image for bigger version]

A single 1-0-1 clock pulse is then routed to one latch pair only, using a 2-to-4 74LS139 decoder and a series of 1-to-16 74L154 demux chips, as shown. This arrangement requires 5 address bits as well as the two data bits and one clock bit.

Each of the 32 5-bit addresses points to a pair of latches, so giving access to a maximum of 64 individual latches. There are only 54 notes on the manual organ, but some of the spare latches are used for  auxiliary functions, including the operation of the master switching transistors in th 14V supply to upper and lower halves of the analogue switching board.

Opto-Isolators, Decoders and Buffers

[Far Left: Opto isolators Decoders and Buffers of the  address routing circuit board]

[Left: Latches and Buffers of the latch circuit]

Much of the above hardware is duplicated to provide independent operation of the 30-note pedal organ, but this needs only one additional address line to distinguish between the two sections.

Thus:
Note address bits – PB0-4
Manual/Pedal select – PB5
Data output bits – PB6-7

Machine Control

Operation of the above hardware is controlled by a machine code program running on the BBC Micro. A user interface in BBC BASIC, normally running in MODE 6, controls the display, selection and loading of items from the music menu. Prior to the transfer of control to the machine code there is provision for setting a number of playing parameters, whose values are passed via the Resident Integer Variables.

Further Reading

For more details, see Part 1 (Intro) and Part 3 (Generating The Data).

I thought a bunch of BarCamping geeks would appreciate knowing about this madcap scheme, so I put together this presentation and ran sessions at BarCamp Blackpool and BarCamp London 7. I hope you enjoy.

About The Project Engineer

I am presenting a hardware hack project which has been undertaken by my dad, Geoff King [left]. He is a closet geek/engineer/tinkerer with many years’ experience under his belt.

He spent most of his career before retirement in the Physics Department of the University of Essex where he taught the students how to interface lab experiments with KIMs, then BBCs, and later PCs.

When the BBC Model B arrived, he had an idea to use one to play the organ in his local church, where he has been organist since the mid-1960’s.

But in the early 1980’s they were expensive state-of-the-art machines – as you may have seen recently on the excellent BBC4 series Electric Dreams!

So the idea was put on hold for a while. But you know a geek. An idea never really goes away… Some 20 years later, with his retirement looming, he was able to “acquire” several Beebs, by then regarded as redundant and heading for the scrap heap. The idea was dusted down, and Ernie the Electronic Organist was born.

The Organ

The church organ is a modest affair of 6 speaking stops on a single 54-note manual keyboard, with a single stop on an independent 30-note pedal organ.

[Right - the organ sits in a corner of the church]

As small organs go, the instrument is unusual in having electro-pneumatic action.

This is in contrast to the traditional system of rods and levers, known as trackers, linking the keyboard to the pallet valves which supply air to the pipes.

Switches beneath the keys supply current to a series of solenoids which operate small valves controlling the air supply to the pneumatic motors attached to the pallet valves.

[Left - the organ console with pedals below, and the BBC Micro mounted on the wall next to the seat]

Hardware In Action

This video shows a part of the wind chest and the solenoids in action whilst the organ is played (use http://cazm.eu/ernie1u as a shortcut):

Electro-Pneumatic Action

[Left, Electric action for each note - click image for bigger version]

An unregulated PSU provides up to 10 amps of current at a nominal 14 volts DC to power the action.

One side of each magnet is connected to the 0 volt rail, with the keyboard switches on the +14 volt side.

The aim of the project is to simulate a series of computer-controlled switches in parallel with the keyboard switches.

Further Reading

For more details, see Part 2 (Machine Control) and Part 3 (Generating The Data).

On arrival, we took a walk along the prom to see the sites and stretch legs after a long journey. Yes, Blackpool is a little tacky, but it’s great fun if you take it at face value and appreciate its quirky English seaside charms! We were also there at the right time of year  for the illuminations [right], which were certainly a site to see.

The BarCamp itself was held in the conference suite at the Pleasure Beach Casino – a great venue right in the heart of the town. We had three big rooms to use and the views from the 1st floor balcony at lunchtime were fantastic!

Alistair brought BarCamp Wifi-In-A-Box™ along, aka some wifi routers, cable and power in a wheelie suitcase. Once set up, it worked impeccably all day. I had Mr Duck [left]  helping me on the registration table – and showing off one of the inspired bits of schwag we all got – BarCamp Blackpool branded rock!

Evening dinner was taken at a fish and chippy a good hike away (a few folks complained how far it was to walk), but we all re-convened for a few beers and a magic show back at the Pleasure Beach afterwards. The site of @ruby_gem getting her head chopped off made quite a few of us giggle! But she didn’t deserve it – full marks for organising a friendly, fun BarCamp, we had a blast!

The plan for Sunday was originally that we would meet up at the Pleasure Beach for a go on the rollercoasters, but after “a few beers” the night before, and looking at the weather forecast for the day, we decided cowardice was the better part of valour and gave it a miss.

Instead, Alistair & I hired some chunky yellow bikes and did a spot of geocaching (in the rain) along the seafront. I think we covered about 10 miles in all. Great fun, even though we did get pretty soggy in the process. According to Alistair, that’s an occupational hazard of caching with me. Hmph.

A visit to Blackpool would not be complete without a ride on the famous Trams, (and besides, my Dad would have killed me if I’d missed out). So on Monday we took a trip all the way to Fleetwood on the rickety old ladies. We might have been looking for more geocaches along the way, I’m not telling!

All in all a great weekend, and I would recommend attending the next BarCamp Blackpool when it comes along! See all my photos from the weekend.

We had a great time, the weather was kind to us (even if it was pretty cold in the tend overnight!) and the talks, as usual, were excellent. Memorable ones included @frankieroberto (about building OpenPlaques.org) and @alistair – who gave a presentation on Mr Duck’s life over the last 12 months. The first BathCamp was where Mr Duck originated, and Alistair has been putting up with looking after him ever since!

As a bit of silliness, and as it was Mr Duck’s official Birthday, I baked a cake which we enjoyed with others during our afternoon tea on the Saturday.

Rather than talk about tech subjects, I lead a discussion on self-published photo books with Blurb and other sites, which seemed to go down well.

It was also great to meet some new friends and catch up with a few of the northern folks from Sheffield who had come down for the weekend!

There was also a gig in the main tent from a local band, and impromptu gatherings around the campfire on Saturday evening.

The catering could have been a problem, but the do-it-yourself sandwiches and Saturday evening BBQ were perfect for this type of camping venue.

Yes, we had to use the chemical loos in the night (but I was prepared for that in advance). At least the pub was open during the day for a more civilised toilet experience. I like my creature-comforts!

All in all, an enjoyable BarCamp – and I particularly liked the camping chair and enamel mugs we each got as schwag! Besides, who wouldn’t love a BarCamp with chickens pottering around and clucking at your feet during sessions?

I have just been to BarCampBrighton4, and I have to say I found some aspects of it quite disappointing. I know I’m not the only one, and so that is why I’m sticking my head above the parapet with this post.

Having been on the organising committee for BarCampLondon6 and now 7, I know how much hard work is involved in running a BarCamp. And I can appreciate how dispiriting it can be to have people complaining about things when you have put so much effort into getting the thing off the ground. I do not wish to detract in any way from the achievements of the Brighton organisers, not least because of the necessity for a last-minute change of venue – a BarCamp organiser’s worst nightmare!

But I’m afraid it’s the venue which really did take the shine off things for me this time around. As a daytime session space, I thought it worked pretty well with areas spread across three floors. Some adjacent pitches were a little noisy and hard to hear the speakers, but there’s not a lot you can do about that. Where it really fell down was as an overnight venue. With no permanent lights or toilets, I personally didn’t feel it was a suitable overnight space. And I’m not just being picky, there are plenty of practicalities to take into account.

At one point in the afternoon, I was seriously considering going home early. And that’s never happened to me at a BarCamp before. I really really did not feel comfortable about staying in that building for the night. Fortunately, @vickyjo came to the rescue and very kindly agreed to our late-afternoon appeal to let myself, @tnash and @carolynlyn have some floor space at her flat, even though she was already accommodating @NeilCrosby and @alistair. So huge thanks to her for putting up with us at the last minute!

As a veteran of numerous overnight BarCamps, I’m not averse to sleeping on the floor. But it was very noticeable how many BarCamp regulars did not stay at the venue but made alternative arrangements. I wonder how many of those who I heard saying the venue was “awesome” actually had to stay there overnight themselves? Quite a few did not, but went home to the comfort of their own beds and flushing loos. And some other regulars who did stay over told me the next day that I was very wise to have gone elsewhere!

I think the main point I’m making about the venue is that the lack of basic facilities weren’t made obvious to campers before they arrived. The 3rd Sept blog post certainly made no mention of the situation with lights and portaloos. If it had (or even earlier would have been preferable), it would have been much easier for us to make up our own minds and then make alternative arrangements in good time if we felt so inclined.

Having said all that, there were plenty of good things happening during the event, and I particularly enjoyed sessions by @tobestobs (CSS3 Browser Support), @edent (Star Wars Wedding on a Budget) and the one on High Altitude Balloons – which seemed to give rather a lot of those listening some worrying ideas!!

I liked the idea of using recycled bags as schwagbags – which lead to some rather amusing images of geeks wandering around with the most inappropriate hand luggage! [see Cristiano right] And the technology swaps table also attracted some interest throughout the event. I hope there wasn’t too much old tat left at the end which the organisers had to dispose of!
[Alistair checks out a "Crap Soldering Iron" below].

After last-minute sponsors came forward, the event was also fully catered and the food was plentiful and pretty tasty. I confess I wasn’t around for the pizza on Saturday evening, so I can’t comment on that. There was an urn to make tea and coffee and self-service cold drinks. Even a couple of days before the event it was looking like we might have to buy our own lunches – which actually would not have worried me too much. But it was nice not to have to do that.

There was a good mix of old and new faces in attendance. I hope the newbies enjoyed their first BarCamp experience. And I heard lots of the regulars did enjoy themselves and had a great time. Would I go to another one at this venue? Probably, but I would make sure I had alternative accommodation arranged well in advance!

This was one of @alistair’s mad-cap ideas, and we had immense fun driving the trains around, noshing burgers (and other burnt offerings) and generally geeking out.

Here are some pics from the day:

The Hodge driving – be afraid! Tim does look rather worried.

Neil takes charge.

The lovely Sweet Pea, steaming up.

Me driving Sweet Pea, solo - thanks to the very trusting owner, Jim MacDonald – Alistair’s dad!

I hope we can do it again next year. Until then, here are the rest of my pictures from the day.

It turns out that @bletchleypark had been listening in on the Twitter chatter, and had arranged a marvellous welcome for us all, with our own registration tent and an extra guided tour laid on especially for us! Wow, what great customer service! A few more visitor attractions could learn from this, I’m sure.

[The geeks got their own guided tour!]

Anway, on to the day itself. The site near Milton Keynes was probably Britain’s best kept secret during and after World War II. But recently it’s come to the public’s attention and Heritage Lottery funding has been granted to try and help save some of the historic buildings which are falling into disrepair.

As well as the famous Enigma Machine, Turing Bombe and other code-breaking exhibits, the site also houses the National Museum of Computing – a must for all early computer geeks, where you can go and poke about with old BBC Micros, ZX Spectra and other ancient relics!

[It's an Enigma!]

There are loads of fantastic exhibits to see, the guides are hugely knowledgable and entertaining, and the only limit to your wanderings is how tired your feet get walking around the site!

It’s impossible to see it all in one day, but for the £10 cost of an annual ticket, it’s also great value for money. I fully intend to go back again soon, to see some of the other stuff I missed this time around. I’m sure I could visit 2-3 times and not see the same stuff twice!

The folks who work there don’t even mind strange requests to get Mr Duck’s picture taken with the Colossus Squirrel – they took it all in their stride!

Big thanks to @neilcrosby for un-organising, and to @bletchleypark for looking after us all so well!

See all of my pictures from the day out.

I’m really looking forward to attending the upcoming Unsheffield event which kicks off next Friday evening. It is brought to you by the same team that organised BarCampSheffieldII last year, but they felt that they wanted to deviate a little from the standard BarCamp format, hence the rebranding of this new event.

I will endeavour to write more about the event during or shortly afterwards.

Arranged by @vero, the event was very well attended with standing room only by the end.

I enjoyed @garethr’s talk on Asynchronous Messaging for Web Apps, it was a great intro taster to the subject. You can view his slides here.

Then we had a lightning talk from @martinkl about his new browser testing software Go Test It, and a lady called Helen from @HoldsworthPR on a startups conference being held soon.

There was also plenty of opportunity to socialise and have a few beers (shame I was driving). Good to see so many locals in attendance as well as a few of us from further afield.

I shall keep my eye out for the next one. Stay informed by reading the Cambridge Geek Nights blog, and come along next time if you are in the area! You can also follow the tweets here.