For a couple of months, I’ve had my Camara Axe Arduino shield kit in a box waiting to be put together. I imported it from the States as it seemed one of the most versatile ways to control flash sync timing in a reasonably cost-effective way. I have done some manual shots with flash and liquid droplets, but have really reached the limit of what I can do effectively with timing by hand. (For more info, see the presentation I did for BarCamp Nottingham in July.) Anyway, today, I finally pulled my finger out and constructed the kit. Those less willing to do a bit of DIY have the option of the more expensive ready-built version.

It’s based around the popular Arduino Uno open source hardware. I bought my Uno from the lovely folks at Oomlaut in the summer. The Camera Axe Shield v5 (CAS5) acts as an additional board with specialist I/O hardware and LCD screen, which piggy-backs onto a regular Uno. It comes as a custom PCB with all the discrete components and LCD screen required to make the shield:

CAS5 Kit of Parts

Maurice Ribble is the CAS5′s designer, and he is terribly helpful if you need any questions answered. The CameraAxe Wiki also has a very easy to follow step-by-step guide to building the kit. I had absolutely no problems seeing where everything should go, and once my rusty soldering skills were honed a little, I was reasonably fast in putting things together. Not quite as fast as the great little stop-motion video of the folks from TechPhotoBlog constructing the kit!

Build in progress

A few hours, a lot of soldering and a couple of minor burns later and it was done! I did manage to avoid setting my  hair on fire this time, which has been known in the past. The smell of singed hair is pretty awful, so I was glad I didn’t do any damage to my locks!

Shield front completed

Shield rear with Uno board

Did It Work?

Yes!

I’m pleased to say that once the CAS5 software was loaded onto the Arduino board, the shield booted up and showed me a nice menu first time – hurrah!

But then I depowered and repowered and it appeared to be dead! Minor panic, until I realised I was using the Uno R2 board, some of which require a very minor mod by adding a diode which prevents a big voltage spike on startup (this apparently upsets the CAS5 board until the software is re-loaded again). I also need an external PSU for the Arduino, since I don’t necessarily want to have to have it connected via USB to my netbook every time I do a shoot.

I guess now I should really learn how to use the thing! It is quite complicated with lots of menu settings – each of which will need careful experimentation with the various different sensors I have also bought (Microphone sensor, Photogate sensor and the Valve sensor) to get optimum results. But as the long winter nights are drawing in again, it’s the perfect time of year to have a play and see what I can achieve. Watch the other space!

Alistair demos his Metro Simulation

Alistair was demonstrating his Newcastle Metro Simulator, and I gave him a hand minding the stand while he had a look around. It was great fun, and I really hope they can find sufficient funding to put on another event in 2012. If so, I’ll be back!

Here are a selection of my images from the two-day event:

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-B4 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:

The value of each note, ON or OFF, is stored in a 1-bit data latch

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.

Each latching operation requires two data bits to be distributed to all latch pairs simultaneously, 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
Clock line – PA0

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 BEEBs 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 window sill 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).

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.

• Plug & Play:
  Drop in a widget, little or no JavaScript knowledge required, just customise some options and go – no flexibility
• Some assembly required:
  Write common utilities, use pre-made code to distance yourself from browser bugs – flexible, until you hit a browser bug
• Down and dirty:
  Write all code from scratch, deal directly with bugs, quirksmode can save your life – eccessively flexible – almost too flexible
• Use JavaScript library:
  Makes JavaScript bearable, gets the job done fast, simplifies cross-browser support – easily customisable

John then did a comparison between the various JavaScript libraries, including jQuery, Prototype, YUI and Dojo, which are commonly in use. A developer survey showed that jQuery and Prototype were used by around 32% of developers; YUI was 22% and others around 14%.

John’s full slides give much more detail of each library’s strengths.

John’s presentation: slides (slideshare) | audio (mp3)

Nate Koechley

Nate began by giving us a bit of historical context to the way Yahoo! has evolved over the years.

He then covered topics such as Yahoo’s server architecture, graded browser support [see below], progressive enhancement, unobtrusive JavaScript etc.

He suggests we all have an interesting set of decisions to make regarding front-end design:

1. Do what is standard
   if impossible, then
2. Do what is common
   if impossible, then
3. Do what it takes

Then we get on to:

1. Do what is simple
   +
2. Do what is flexible & progressive
   +
3. Do what is open

This is in order to satisfy the multiple audiences for any website: Users, Developers, Machines.

At Yahoo!, they focus on 8 specific areas:

1. HTML
2. CSS
3. JavaScript
4. Accessibility
5. Internationalisation
6. Performance
7. Infrastructre & Process
8. Tooling

They use tools such as JSLint to check code for quality, and adopt the idioms it promotes to improve their code. Also, unit testing with YUI Test.

There’s much more detail in his slides (see below).

Nate’s presentation: slides (blog/slideshare) | audio (mp3)

James Graham / Lachlan Hunt

What can you do with it now, what in the future?

Intro
Next iteration of HTML spec. Long overdue for overhaul. What are we trying to achieve? Do things you can’t do now without JS, for instance. Working on HTML and XHTML together. Authors can choose which is most appropriate for them.

Design Principles

• Compatability – Browsers must remain compatible with existing content, old sites MUST still work.
• Degrade gracefully – make new features work in, or at least not break, new browsers.
• Don’t reinvent the wheel - fix what we already have, don’t reinvent it from scratch.
• Pave the cowpath – consider Use Cases – look what authors already do and improve where neccessary.c.f. Microformat Date/Time pattern.
• Evolution, not revolution - make incremental improvements. Can’t discard existing content and start fresh.
• Solve real problems – ensure work is relevent to web developers. Identify the problems first, then find solutions.
• Priority of Constituencies - have to prioritise the needs of:
  Users, authors, implementers, spec writers, theoretical purity
• Secure by design – protect end users from malicious intent
• Separation of Concerns – Separate presentation, structure, semantics where doing so provides real benefits. <b> and <i> are still in the spec.
• DOM Consistency – minimize differences between HTML and XHTML, allow scripts to work now.
• Avoid needless complexity – authors won’t use something complex if they don’t understand it
• Well-defined Behaviour – 97% of web has syntax errors! Define precisely what browers must do with all possibly bad input.
• Handle Errors – authors make mistakes all the time, the spec must define how browsers handle the errors.
• Media independence – make sure pages work on different media, devices and platforms.
• Support World Languages – support pages in any language, bi-directional text etc
• Accessibility - provide for the needs of users with disabilities. Built-in preferred over add-on accessibility, where possible.

When can we start using HTML5?
As soon as the browsers start implementing the features. FF3, IE8 support some of the spec.

What can I do with it?
Common elements of a blog – header, main nav, article, sidebar, footer. So we get:

<header> element – for site-wide header, not H1. Title/subtitle etc.
<nav> element – screenreaders could jump straight to it easily
<article> element – for the main body
<aside> element – for sidebar etc, pullquotes.
<footer> element – for copyright info

These can add more consistency than using <div>s and variable class names.

<section> elements can be nested – each of which has H1 – without worrying about correct nesting of H1, H2 elements.

<time> – for posted date of blog item. Attribute has machine-readable timestamp, tag wraps human-readable content.
<figure> – represents image(or table etc)+caption, <legend> nested inside to associate it together.
<caption> not used for reasons of backwards compatibility.
<meter> – attributes shows rating of content – the bar is drawn by the browser not meant as a graphic. Eg, content of element is 3/5, the bar is drawn by the user agent. Also progress bars
<progress> for dynamic (ajax) apps.
<video> – native video support in browsers, DOM APIs for providing custom interfaces, no more dependance on Flash. Browser provides the controls etc. Casual authors can quickly cope with video files.
<canvas> – dynamically draw graphics and text, graphics-oriented DOM APIs.

Offline Web Apps – offline caching APIs, local storage, SQL database.
Developer Tools – HTML5 conformance checker – exceeds the capabilities of traditional DTD bases validators. Gives more useful info.
Parsing HTML5 – libraries for python, ruby. off-the-shelf parser reduces reliance on RegExpr hacks.
The Community – diverse group of individuals and organisations. W3C, WHATWG trying to work together. Open to everyone.
How to Contribute – general feedback, develop tools, research, community participation.

• blog.whatwg.org
• forums.whatwg.org
• wiki.whatwg.org
• Mailing list and IRC.

• My photographic blog
• My rubgymad blog
• My web design blog
• Stuff I post to Flickr
• My tweets from Twitter
• Stuff I’m reading via del.icio.us

I decided against using my Last.fm feed for the moment, as it would probably swamp all the other inputs (I listen to a lot of music while working, it’s one of the perks of working from home, no-one moans about your choice of songs!).

Having got the basic lifestream out of Pipes, I used Dreamweaver’s XSLT transform functionality to generate a list which would sit in my ASP.NET page. I wanted to use specific icons to show which feed each item was from. Cristiano was using a JSON output for his pipe, but mine is coming out as RSS, so the custom ID’s applied in the pipe weren’t getting through, since they’re not part of the RSS spec.

CSS3 attribute selectors are one option, but they don’t work in clunky browsers like IE6. So having also been at Simon Willison‘s jQuery session at BarCampLondon3, I thought I’d have a play with with the library to see if I could do some neat DOM manipulation to add the correct class to each list item.

The Llifestream list is marked up thus: <ul id=”lifestream”>. I added some jQuery to insert the class for the list element, based on the attribute of the link it contains. That requires a parent element to be changed, based on it’s child’s attributes. Slightly tricky for a jQuery novice like myself. It took me a while but eventually I found the correct syntax:

$(document).ready(function() {
$(“#lifestream > li > a[@href^=http://twitter]“).parent(“li”).addClass(“twitter”);
});

The first line calls jQuery once the full DOM is loaded; line 2 (which looks rather horrible with text wrap, but bear with me) selects an anchor with the attribute which begins with “http://twitter”, but I wanted the class added to the parent LI, so hence the chaining of jQuery functions.

Now all I needed to do was to add a case for each link type to my new lifestreamclasses.js file and add a linke to it in the header of my lifestream page, and the proper stylings can be applied. I decided to keep them in a separate JS file for ease of maintenance. Once the pipe has mashed it all together and I’ve written the relevant styles into the stylesheet, the resulting RSS aggregated feed looks like this.