Creating repeating musical scales in binary

Inbetween soldering and gluing, we've been adding a bit to the firmware for our light-up MIDI keyboard. We're looking to make a generic system for adding scales and chords using simple three-byte patterns. While we're already well into the actual hardware build, it's time to add a bit more to our music-theory-to-binary idea.

Let's start with a really nasty scale on the piano. Here's a C minor blues scale. It's like the C minor penatonic but with an added "blue note". This means a mix of lots of black and white notes. Super confusing!

You can see that there are six notes in the scale, and they repeat over and over on each octave of the keyboard. We're currently describing one octave as twelve intervals in binary. This is basically a byte and a half. So we can store two octaves over three bytes. The third repeating octave is simply a repeat of the first and half of the second byte, and so on.

So our twelve-interval representation of the blues scale is

100101110010

And a two octave span for the C minor blues scale is

100101110010100101110010

And splitting this up into bytes, we get

10010111 00101001 01110010

Where our scale is split over the middle byte:

[10010111  0010][1001  01110010]

If we wanted to play this same scale in D, we simply bit-shift the entire pattern two places to the right:

00100101  11001010 01011100 10

and we're now spanning four bytes.
However, it's worth noting that the final byte is simply the first two notes of the scale as it repeats.
If we continued the sequence, we'd get

00100101  11001010 01011100 10100101  11001010 10100101  11001010

So other than the very first byte, our fourth, seventh, tenth (and so on) bytes are all the same. If truth be told, our first byte should be the same too. We pushed everything up two places, to start on the D instead of the C and simply padded the gaps with "blank" notes. But if we played down the scale instead of upwards, some of these blanks would be over notes in the scale. So there's no reason why we can't "merge" the first and fourth bytes together, to complete the scale in both directions.

Simply put, as we push our scale "out of" the third byte and into the fourth, we can then bitwise OR the first and fourth bytes together, to "fill in the blanks".

In musical notation, you can "push" a scale six places up (this is often referred to as making the notes "sharp") or push a scale down up to six places (referred to as "flattening" the notes). Once you push the notes more than six places in any direction, because of the repeating nature of the notes in a scale (or on a keyboard) you'll find it's the same as pushing them from the other direction. So, for example, you can sharpen all the notes 8 places, but this is the same as flattening all the notes 4 places.

To keep things simple, we're just going to "push upwards" from a basic C scale for everything. So all our scales and chords will be based around C, and if we want to transpose them into another key, simply push them up the appropriate number of spaces, then use the repeating nature to fill in the blanks immediately before the root note.

Here are the binary patterns we'll start with (padded to 16 bits by repeating):

C Major chord (C-E-G)
1000100100001000 = 0x89 0x08

C Minor chord (C-Eb- G)
1001000100001001 = 0x91 0x09

C Major 7th chord (C-E-G-B)
1000100100011000 = 0x89 0x18

C Minor 7th chord (C-Eb-G-B)
1001000100011001 = 0x91 0x19

C Major scale (C-D-E-F-G-A-B)
1010110101011010 = 0xAD 0x5A

C Minor scale (C-D-Eb-F-G-G#-Bb)
1011010110101011 = 0xB5 0xAB

C Minor pentatonic (C-Eb-F-G-Bb)
1001010100101001 = 0x95 0x29

C Minor blues scale (C-Eb-F-F#-G-Bb)
1001011100101001 = 0x97 0x29

There are probably a million and one other scales we could include, but for most pop, rock and blues type songs, these will probably get us through (maybe in future we might include 6th, 9th and 11th versions of some chords, but we've plenty to be getting started with here!). Once we've got these working, adding more chords/scales is as simple as converting into a two byte value and adding them to a look-up table.

So how do we make use of these? At the minute all we can do is play a load of stuff in C!
Well, we simply bit-shift (we're going to always bitshift to the right) a certain number of places to start the pattern on the correct (root) note, then fill in the blanks we've created immediately before the root note.

Let's say we want to play an E Major chord.
To get to E from C, we need to raise all the notes 4 places (from C to C#, from C# to D, from D to Eb, from Eb to E). So let's just take our C Major chord and bit-shift the pattern four places to the right

10001001 00001000 00000000 - CMaj
00001000 10010000 10000000 - EMaj

We created a third byte, to "catch" the last four bits of the last byte in the (repeating) chord
If we translate these bytes back into notes, we can see:

So far, our crazy bit-shifting seems to be hold up.
Let's go crazy and really push those bits around. Let's see if we can't make a B Major chord, using exactly the same technique:

To get from C to B, we need to raise all of the notes in our major chord by 11 intervals/steps. Doing this in binary gets us:

10001001 00001000 00000000 - CMaj
00000000 00010001 00100001 - BMaj

And mapping these back to our keyboard diagram:

So now let's try applying the same technique to our "blues scale".
We're looking to repeat the scale over the entire keyboard, so we'll take the 3-byte repeating pattern of a C minor blues scale, from the top of this article.

100101110010100101110010

Let's turn this into a G minor pentatonic by shifting the entire pattern 7 steps to the right.

0000000100101110010100101110010

If we split this pattern up into bytes, we get

00000001 00101110 01010010 11100100

But we've already discussed how the fourth byte is a repetition of the first.
So we should bit-wise OR the first and fourth bytes together:

00000001
OR
11100100
========
11100101

So our final pattern looks like this:

10100101 00101010 01010010 

And mapping this pattern back to the piano keyboard, we get this:

The paler notes in the diagram above show the "additional" notes added, when we merged the fourth and first bytes together. Despite performing a simple bitwise operation, the "missing" notes do fit in with the rest of the scale.

Having demonstrated that the theory holds up, it's time to get coding......

Building a light-up MIDI keyboard

After last night's BuildBrighton meeting, we managed to get our Oregon keyboard gutted and all the keys drilled with 3.3mm holes (ideally we'd have liked 3mm, as we're using 3mm LEDs, but the smallest available drill bits at the space were 3.3mm!)

This evening we spent a good few hours hot-gluing LEDs in place and soldering them together. In fact, we soldered them together before gluing them inside each of the keys

As we are going to be using a MAX7219 LED driver IC to turn our lights on and off, we thought it best to common the cathodes of eight LEDs at a time.

While this seems like the "right" way to do it, the time taken to get just eight keys done meant we'd still be wiring this thing in a fortnight's time! Partly because we're using CAT5 cable (which, although stranded, each "strand" is a piece of solid core wire and quite resistant to flexing easily) though mostly because cutting each length of wire to "just the right length" meant that manouvering one key to glue/solder the LED in place dragged all the others along with it!

Since we're using CAT5 cable and separating the strands, to create a looping, common cathode connection, it suddenly seemed obvious that we could use the pairs of strands from the CAT5 cable to wire each LED individually.

Suddenly things were moving along at quite a pace. As each pair consists of a coloured cable and a white-and-colour cable, we stuck with using the "white" cables for all the LED cathodes (at least then we know which way around to wire each light!).

Things slowed down a bit in-between mounting groups of  eight LEDs, as we tested each set of eight both before and after connecting all the cathodes together.

Here's how the keyboard might look, displaying a single C major chord. There's no fancy firmware at work here - we just plugged three wires into a breadboard and connect a 3v battery!

After three or four hours of soldering, gluing, testing, slurping coffee, soldering, gluing (you get the idea) we managed to complete the entire top keyboard.

Frustratingly, as we were working in groups of eight keys at a time, we thought we'd finished and started to pack away before realising that the keyboard covers four octaves from C to C.
Including the last C on the board meant we had 49, not 48 keys. Bugger!

It took a while, but eventually we ended up with a full keyboard, wired with 49 LEDs, all waiting to be connected to a controller board. Not only do we still have a PCB to make and some firmware to finish off, but we've a lot of wiring to do too!

49 LEDs, each with a wiring running to both anode and cathode legs - that's nearly a hundred wires to sort out and connect up. So it looks like this weekend has been taken care of!

Converting music theory into bits and bytes

Without getting too bogged down in musical theory (between us, a handful of people probably know enough to fill a half of an A4 sheet of paper!) we're looking for ways of getting particular scales and chords to appear on the keyboard by lighting up the appropriate LEDs.

The easiest way to do this is to create a byte value, where each bit indicates whether an LED is on or off. We're going to do a straight mapping from the LEDs to the piano keyboard (we'll worry about guitar fretboards later!)

Now the more astute readers will have already spotted that, despite what we were all taught in high school music lessons, an octave doesn't have just eight notes in it! While it may have eight intervals (let's not got bogged down with tones and semi-tones at this stage) between one note on the keyboard and the same note an octave higher, there are twelve individual "notes". The distance between each note (ignoring the colours, whether black or white at this stage) is one "semi-tone".

On a guitar, the "distance" between each note on the fretboard is also one semi-tone.

We're not going to the trouble of naming all the notes on our keyboard/fretboard. At this stage, all we're concerned about is identifying the intervals between each note in a scale (i.e. how many semi-tones apart they are) rather than whether the note is a C or B-flat or whatever.

By focussing on intervals rather than note names, we should be able to change each chord/scale into a different key really easily, by simply shifting the entire pattern up or down the keyboard/guitar. This is easier to visualise on a guitar, as there are no pesky black notes to get in the way:

Here's the famous "first position" A minor pentatonic scale on a guitar fretboard.

On the guitar diagram above, the lower (bass) notes are on the bottom, with the higher notes at the top of the diagram. The pitch of the notes goes higher towards the right of the diagram.
Here's the same scale on a piano keyboard

Notice that if both scales are starting on the same note (A) on the guitar (lowest string) there is a gap of two frets before the next note (drawn on the eighth fret on the low E string) and, similarly, on the piano keyboard above, there are two notes (the black, B-flat and the white note B) between the first and second notes of the scale.

So whether playing a guitar, or a keyboard, we can work with intervals rather than note names and still get the same result. Now let's move the scale into another key. For us guitar players, it's really easy. For some crazy reason, we're going to play this same scale, but in F#. On the guitar, simply slide the entire shape down the guitar neck, so that the scale starts on the note F#.

But on a piano keyboard, things aren't quite so straight forward. We still need to move all the keys down three semi-tones, but in doing so, we've made the scale look much more complicated:

And moving scales around on a keyboard which uses both black and white notes can result in some pretty crazy combinations of black and white notes. Normally keyboard players simply commit these to memory and "just know" which notes to hit when playing in a particular key.

But when you're starting out, knowing which note to hit is a bit of a nightmare. Which is why we're building this MIDI keyboard in the first place! If we imagined using binary to represent the keyboard diagram above, starting with the first note (C) and mapping each bit in the binary value to each key of the keyboard (so bit zero is C, bit one is C#, bit two is D, bit three is E-flat, bit four is F - if you look, there is no black note between the E and the F on the keyboard - and so on) we can illuminate the keys for the F# minor pentatonic scale (as shown above) by the value

00000010010101001010000000

We simply read the binary value as a sequence of on/off signals, starting from the left, and apply the signal to each key on the keyboard, also starting from the left.

Interestingly (see, I told you this was fascinating!) we can see in our binary value, the first two notes are represented by 1001. This is the interval of two semi-tones we were banging on about earlier.

In fact, any pentatonic scale can be represented by the binary value 0100101010010
We simply change the number of leading zeros, to place the pentatonic scale in a different key. The intervals remain the same. Adding more zeros at the start makes it start on a different note, so each note in the scale gets a different name, but the "gaps" between the notes of the scale are always the same.

(Another really interesting thing to note - for those of you still awake at this point - is that there are five values of one in the binary string above. Five "on" notes; five notes in the scale are what make it pentatonic)

Using this technique, we can come up with binary values for a whole range of different scales:

The "major scale" - the one everyone knows as doh-ray-me-fah-so-la-te-doh has seven notes (we repeated "doh" at the start and at the end, which is why it's written with eight). The intervals between the notes in a major scale are

play-a-note, skip one, play-a-note, skip one, play-a-note, play-the-next, skip one, play-a-note, skip one, play-a-note, skip one, play-a-note.

This is often written as tone, tone, semi-tone, tone, tone, tone, semi-tone (but that's a lot like music theory, so we'll stick with our garbled interpretation of things).

Look at the diagram of a piano keyboard. If you played only the white notes, starting at C, you'd be playing the "C Major" scale. So you hit C, then miss the black note, then hit the next (white) note D, then miss the next black note, then hit the next note, E. Now there's no black note between E and F, but in our major scale, we need to play the next note anyway, so we play the F note. Then we skip the next note (which is the black F# in this case) and play the next, G. And so on, right through the scale.

The intervals for a major scale can be written in binary as:

101011010101

And if we wanted to continue the scale, we would simply repeat from the start:

101011010101101011010101

Note also that the first binary representation of our C Major scale had twelve characters in it, and a total of seven values of one. We already identified that our major scale has seven notes in it, and one complete octave has twelve intervals. So things are looking good for our binary representations of scales (and chords - scales and chords are very closely linked and for simplicity we're going to use the terms interchangeably here - things might change as we get deeper into the project, but for now we can think of scales and chords as the same thing).

Other commonly used scales and chords, as written in binary:

 100101110010
a blues scale is a pentatonic with a few added "blue notes"

 100010010000
a C major chord (triad) includes the notes C, E and G

 100100010000
a C minor chord is the same as the major chord, with a "flatted third" - this basically means that the "middle note" in this case should be moved down one interval.

 100100010001
a C major 7th chord is the same as the major chord, with an extra note

To play a D major 7th chord, we simply take the C version and move it up two intervals (increasing one interval would make it C#maj7) and in binary we do this by adding two leading zeros:
 00100100010001

Now the binary string is more than twelve digits long. We could wrap the 13th and 14th bits around, and place them in positions zero and one in our binary string, to create 

 011001000100

but now we're entering the world of chord inversions, and some pretty heavy-going music theory. So we'll keep things simple for now (though we will be using this technique later, in our firmware programming).

Now we've a way of converting musical ideas into binary, we can simply create a lookup table of values for each of the major, minor, pentatonic, 7th and other chords/scales, and simply bit-shift them left or right, to convert them into their respective key(s).

Phew time for a break!

Gutting an electronic keyboard to make a MIDI instrument

Before tonight's BuildBrighton Open Night, we managed to get hold of an old Oregon double-decker keyboard. It was sold-as-seen with  no indication of how/if it worked. For the price, it seemed worth it just to get hold of some decent-sized piano keys!

Unfortunately, when we powered it up, at the hackspace, nothing came on.
We checked for continuity across the power in and power out distribution board, and everything seemed to be in order. We even went so far as to put the multimeter on the exposed wires while it was hooked up to power and switched on (not something we're ever happy doing - messing about with low voltage, 5v logic signals is all well and good, but playing around with exposed wires with 240V live voltage from the mains floating around, and suddenly you're not just messing about.)

Opening up the keyboard from it's inbuilt flight-case enclosure didn't really offer much enlightenment.

Suddenly, the keyboard came to life. All the buttons flashed, the BMP indicator reported a steady 60bpm, and pressing the keys on the lower deck produced some pleasing (actually, not-so-pleasing-rather-crappy-sounding) 80's style synth drum sounds - and, of course, the inevitable handclap.

Then it all went dead again.
Then the lights all came on but the keyboard didn't respond.

This went on for about an hour and a half. There was obviously a loose connection or two, somewhere within the unit. But where?! Another hour or so of poking about, and we decided on some drastic action.

We got the keyboard just because of the nice double-decked keys - everything else was a bonus. So if everything else around it didn't work reliably, there was only one thing to do: get rid of it!
The first thing to do was remove the keys and keep these somewhere safe.

Next we had to gut the inside of the keyboard. Although the tech inside was fascinating from a history point of view, most of it was pretty worthless now. Who needs a separate wave-table for each sound type on a piano any more? It was pretty archaic.

And not just old-fashioned. A lot of the joints were corroded and rusty inside. There could be any number of faults with this old thing. Originally the idea was to keep the keyboard working in it's original state and simply add LEDs onto each of the keys on the upper deck. It soon became apparent that what we needed to do was build an entirely new MIDI device.

To turn a busted keyboard into a MIDI device that could display which notes to play would not only mean accepting and understanding incoming data from the MIDI port, but also being able to detect key presses and generate outgoing MIDI data to send to a sequencer or PC or similar.

Luckily, the method of detecting key presses on this particular keyboard was pretty simple.

Dating from some time before the "date last checked" sticker inside, which said June 1989, this keyboard didn't have such niceties as velocity detect on the keys - a keypress is either on or off, there's no detecting how hard each key is struck; this is a purely digital device. And that's just fine with us!

Each keyboard has 4 full octaves. From previous posts, we know that this is 4 lots of 12 intervals - or 48 keys per board. To read these keypresses, underneath each key is a circuit which groups the keys into bunches of eight. Each bunch of eight keys has a common connection on one side, with six lots of 8 input signals running off to a pin-header connector.

For all the world (and thanks to the presence of a diode on every single input key) like the system used multi-plexing to read the keyboard in groups of eight notes at a time. Even if that's not how it did work, we can reuse the existing circuitry to make our device work like this.

The general idea is that of the six common connections, only one group of eight are pulled to ground at any one time. The other side of the eight input pads run to input pins on a microcontroller, each of which is pulled high though a weak internal pull-up resistor.

Where a key is pressed, the input signal would appear low. Where a key is released, the input signal would be high. Once a bank of eight notes has been read, the common connector for those eight pads goes high, and the common connector on the next set of eight pads goes low. Now the same input pins can be used to interrogate the next bunch of eight notes along. Any input pin that is now low indicates a different key that has been pressed.

Although one input pin is potentially connected to up to six different pads, by knowing which bank of eight keys has been pulled low before querying the pads, we can work out which of the 48 keys are pressed and which are released, despite only using 6+8 = 14 i/o pins.

As time was tight, we'd already wasted a good few hours, and Steve was getting hungry, we set about preparing for the original part of the project - adding LEDs to the keys.

A 3mm hole was drilled into the surface of each white and each black note on the keyboard. Where possible we tried to keep them as close to the centre as possible. The keys were unusually brittle and we had to take care, drilling very slowly through each piece of moulded plastic.

We tested the hole for fitting by placing a 3mm LED on the underside. When it comes to it, we're going to have to dismantle each section and hot-glue each LED in place under each key, and common up the appropriate LED leads, to connect them to our MAX7219 controller.

At the end of the night, our double-layered electronic keyboard didn't look much like the beautiful looking thing we brought in just a few short hours earlier.

Hopefully it won't be too long before we can start re-assembling the keyboard and get on our way towards making it somewhere near playable again!

MIDI controlled electronic keyboard

MIDI keyboards? Yeah, they were cool.... in the 80s!

MIDI has been around for ages. It is still a pretty cool thing to get into if you're a musician and fancy playing with the "nuts and bolts" of music (Jason makes some awesome MIDI arpeggiators for example). Most electronic keyboards these days have some kind of MIDI support - but, more often than not, it's MIDI out. We're looking at building a keyboard with a MIDI IN port.

It's all in the pursuit of learning. Some people find music theory just plain confusing. Personally, I find it fascinating. All those "algorithms" to make scales and chords and stuff is pretty interesting. The problem comes when you have to apply the music theory and actually play something slightly melodic on your musical instrument. That's when things get tricky!

For a while we've been considering a light-up fretboard for a guitar, to practice and visual scales and chord shapes across the neck. Originally it was just going to be a bunch of LEDs and some custom-written software to drive them. Then it was suggested that a far more useful learning tool would be something that could accept MIDI data, and light up the corresponding key/note/fret, in time to the music.

That's what we're aiming for. But rather than jump into a guitar neck from the off, we're going to start with something a bit "simpler" - a piano keyboard.

First things first, we had to get hold of a piano-style keyboard.
This monster was for sale, locally, for £20. Given it has two layers of keys, there's loads of opportunity for expansion in the future, should it be deemed necessary. For now, we'll just focus on the top keys.

Now, before we go crazy with the Dremel and start making holes throughout the keyboard, a bit of planning is called for. We're essentially creating an array of LEDs which can be turned on and off by a microcontroller. Already it's crying out for a MAX7219 driver chip! These little devices use multiplexing to ensure a constant brightness across all LEDs, no matter how many are lit at the same tiem.

Thinking ahead, we might want to use the lower keyboard at some time in the future - perhaps to select a chord and have the scale displayed on the upper keys, or something like that. So we're going to want at least 12 input/buttons.

It'd be nice to be able to use the keyboard in a "standalone" mode too (for practicing scales, sorting out MIDI cables and getting a PC hooked up can be a bit of a faff). So some kind of input device and screen would be handy.

So we're going to need a load of inputs, quite a few outputs, preferably hardware UART (for the MIDI signals, which are just serial data, running at 31250 bps) - we're going to need a big microcontroller for this!

Not knowing how far we're going to go with the firmware, we plumped for a PIC 18F4550, just because we know that it has all the hardware peripherals we need, pull-up resistors on at least two input ports, can run at 20Mhz easily (up to 48Mhz if absolutely necessary) - and we've quite a few knocking about in the bits box!

A screen, a rotary encoder for selecting from some simple menus, a 16x2 character LCD display, some buttons and a MAX7219 LED driver. What more could you need?

Laser cut 15mm terrain update

Strangely, our laser-cut terrain wasn't quite sitting perfectly over a printed playing surface of 1" squares. Over an 8 inch board section, the actual laser-cut walls were about 2mm over-sized.

It was no big deal - simply placing the walls just 1mm off their printed map, all the way around, gave the illusion of them fitting properly.

But knowing that they were ever-so-slightly oversized was grating.

A quick look on the intertubes revealed that some other LS3020 owners had experienced similar issues. The DPI of the laser is set to 1016 as it leaves the HPC factory, but after multiple cut-and-measure processes, we discovered that 1003 (horizontal) and 1004 (vertical) give exact sizes for both large and small shapes

(it's easy to miss that small shapes are over-/under-sized because 1% of a 5mm shape is tiny. But on larger shapes, even a 1% difference in expected and actual sizes can become noticeable).

With the laser cutter configured properly, we tried cutting out our amended wall shapes. This time the walls are  a bit lower (but the door frames remain their original size).

The new wall sections fitted together reassuringly closely. Where we've been cutting a 3mm slot ever-so-slightly oversized, we're now cutting it dead on - which means that, thanks to the kerf (the slightly angled cut edge of the material) where two pieces slot into each other, the fit is very snug indeed.

At times - and particularly when slotting pieces into thin sections where doorframes are placed - this can cause the mdf to twist a little; especially since we tried to use superglue on the joints to save time. This means there's no time for adjustments once the joint has been made - which in turn means that on occasion we ended up gluing a section with a slight twist in it. This can be ironed out on the next version; it's hardly noticeable (but, like being slightly oversized, we know it's there!)

The finished map looked similar to the earlier one, only this time the smaller rooms look much more accessible, even for tiny 15mm models.

The walls still look "inkeeping" with the 15mm/20mm scale; it's clear to see which sections are separated from which, even through the wall is lower.

Even with the lower walls, long, thin corridors keep their slightly "claustrophobic" feeling, while still allowing the player to pick up the miniatures from even the smallest and tightest of rooms.

In short, we much prefer this design to the earlier one.
Now we just need to get some stickers made up to disguise the nasty burnt-edge appearance of the mdf, to make it look like the interior of a spaceship, or some sci-fi themed moon base or something!

Laser cut sci-fi terrain for 15mm/20mm gaming

While waiting for CNCPaul to demonstrate his CNC cutting spindle - in order to make some masters for silicone moulding - we thought we'd have a go at putting together some laser-cut scenery; it can always be painted or maybe even covered in pre-printed stickers (as we did with our Wild West buildings a while back).

At first it seemed quite straight-forward, but the further we got into it, the more complicated, and the more steps we needed to follow:

Firstly, we created a map for our terrain/walls to follow. Of course, as our electronic board game Starship Raiders is going to be a 20mm sci-fi skirmish game based on the old ZX Spectrum strategy classic, Laser Squad, it only made sense that we "paid homage" to (i.e. absolutely did not totally rip off) the map from the first mission, Assassin Squad.

See - completely different to the moonbase  map from the original Laser Squad.

Next, we drew 1" wide rectangles along each and every one of the walls on the map.

This was important, as it identified which wall sections were actually longer than a single multiple of one inch (where an exterior wall meets with another wall at 90 degrees, for example, we need to add another 3mm to allow for the thickness of the material we're working with).

Then we drew rectangular sections, one inch high and to the correct length for each wall section. Door shapes were cut from the rectangles, and where two walls joined, added a tongue on one section, and a groove on the other.

Every wall was carefully numbered, and the wall sections laid out ready for cutting.

When we were next at the Nerd Studio, it didn't take long to get the laser cutter fired up and running. Amazingly, just two sheets of A4 took about 25 minutes to cut completely. Maybe it was because of all those interlocking holes?

As the entire design was built for 3mm material, we used 3mm mdf for the walls. For the doors, we went for 2mm mdf (so that the doors might sit ever-so-slightly inside the door frames).

Carefully following the numbering on each piece, comparing to the layout in the original design, we glued the walls together in short sections. We're using PVA to ensure a good, strong bond, once the glue has dried. Unfortunately, PVA is not very good at holding the shape until it has dried fully, so we made up load of small sections and, only once they were fully dry, could we assemble lots of little sections into one, much larger piece.

(Lego bricks are ideal for ensuring perfect 90 degree corners on the wall sections)

The final terrain actually looks quite impressive, even without a coat of paint (or those aforementioned stickers). Amazingly, the whole thing fitted together correctly, the first time. We were expecting to be amended and re-cutting shapes for quite a while (it's very rare that anything goes from screen to perfectly-proportioned construction in our studio!) but this time, everything just slotted together, exactly as designed.

The miniatures in the photo above are 20mm scale, and the scale fits with the size of the terrain just right.

However - and it's quite a big however - while everything looks to be in proportion, there's something we're not quite happy about with the final results. At the end of all the designing, cutting and painting, we're creating terrain for a tabletop board game not a miniature replicate diorama for a tabletop display. This thing is meant to be functional, as well as look good.

And that's where the problem lies - it's actually not very easy to move the playing pieces around inside the walls - especially in some of the smaller rooms. The terrain may look nice on the tabletop, but it actually hinders gameplay. So it needs a revision.

Already we're working on a new design, with lower walls (but keeping the raised door arches - they're one thing we can't shrink down, as they still need to be tall enough for 20mm characters to pass through).

Hopefully we'll have some new laser-cut sci-fi 20mm terrain (also suitable for 15mm) by the end of the weekend!