Mental Hopscotch

Eigenharp Tau Whisky Dispenser

2012-01-25T05:12:00.000-08:00

So the Eigenharp Developer Conference was a complete blast. Three days of discussion, coding, playing and drinking. But the product innovation was the realization of the "Eigenharp Tau Whisky Dispenser" accessory.

Now this innovation had been discussed on the forum but it took a perfect storm of pieces, people and madness to achieve...all of which came together Saturday night. During our tour of the Eigenharp manufacturing area, John Lambert had handed be some elastic bands and Tygon tubing with a particularly impish gleam in his eye....

Parts List

1 x Whisky Miniature (I'd supplied some Eigenlabs branded Bladnoch for the attendees)
1 x Eigenharp Tau (WARNING: DON'T TRY THIS WITH ALPHAS)
2 x Elastic bands
1 x 75cm length Tygon tubing

Instructions

Slide elastic bands up Tau and attach Tygon tubing to 'spit port' on bottom of Tau.

Slide bottle (with small amount of tissue to protect Tau!) behind the elastic bands.

Insert Tygon tubing into top of bottle.

Position optimally - somewhere around the percussion keys seemed to work best.

Suck like mad (actually it's not too bad)

Share with friends
(this is Duncan Foster - whose photos these are cut from)

Of course, the discussion almost immediately turned to how to engineer it so you could play at the same time - requiring a bypass system for blowing (unless you wanted the sound of bubbling). John Lambert's enthusiasm was such that I am expecting to see an engineered design within the next few weeks - and hopefully availability as an accessory on www.eigenlabs.com accessories soon thereafter.

Adding Type Overloading Methods to Python

2011-07-18T04:15:00.000-07:00

Python does not have type-based method signatures. One consequence of this IMHO is that a lot of 'dirty code' is being written that would be much improved with the presence of type-signatures. Now I started to write this with a whinge about the liberal use of if isinstance() or if type() statements within Python methods/functions, poor implementation habits, lack of understanding of clean code design and testing, blah, blah, blah... But I think that's just a waste of time for me to write and you to read. So I'm just going to cut to the chase:

I've implemented a Metaclass that enables type-dispatch on method signatures. What's that mean? Well, here's an example:

from typed_calls import *

class Printer:
    __metaclass__ = ClassWithTypedCalls
 
    def show(self,an_object):
        print str(an_object)
  
    @when('show',list)
    def show_list(self,a_list):
        print 'A list:'+str(a_list)
  
    @when('show',int)
    def show_int(self,an_int):
        print 'An integer:'+str(an_int)
  
if __name__=='__main__' :
    p = Printer()
    p.show('Just a String')
    p.show([1,2,3])
    p.show(67)
    p.show(p)

When this runs you get the following output:

Just a String
A list: [1, 2, 3]
An integer:67
<__main__.Printer object at 0x100497d90>

This syntax/mechanism allows you to override methods based on the type of the first argument. In this case there are overrides in place for list and int but everything else uses the standard method.

Why is this useful?

The code is clean (both in the implementer and the user)
The unit testing is simple
You don't have to add code to other classes (which might be out of your control)
It makes writing Visitor patterns much cleaner

An example of Visitors using this code would be:

from typed_calls import *
from copy import copy

class A(object):pass
class B(object):pass

class NodeWithChildren(object):
    def __init__(self,*children):
        self.children=children

class CopyingVisitor():
    __metaclass__ = ClassWithTypedCalls
 
    @when('do',object)
    def make_copy(self,an_object):
        return copy(an_object)
 
    @when('do',NodeWithChildren)
    def do_children(self,a_node_with_children):
        new_node = self.make_copy(a_node_with_children)
        new_node.children = [self.do(c) for c in a_node_with_children.children]
        return new_node
 
class TreePrinter():
    __metaclass__ = ClassWithTypedCalls
  
    def __call__(self,an_object):
        self.depth=0
        self.buffer=''
        self._print(an_object)
        print self.buffer
 
    @when('_print',object)
    def default_print(self,an_object):
        self.buffer += '  '*self.depth
        self.buffer += str(an_object)
        self.buffer += '\n'
  
    @when('_print',NodeWithChildren)
    def node_print(self,a_node):
        self.default_print(a_node)
        self.depth+=1
        for c in a_node.children : self._print(c)
        self.depth-=1
  
if __name__=='__main__' :
    child3 = A()
    child4 = B()
    child1 = NodeWithChildren(child3,child4)
    child2 = A()
    top = NodeWithChildren(child1,child2)
 
    print_out = TreePrinter()
    copier = CopyingVisitor()
 
    print 'Original'
    print_out(top)
    copy_of_top = copier.do(top)
    print
    print 'Copy'
    print_out(copy_of_top)

There are two Visitors in here the CopyVisitor ad the TreePrinter. Note the TreePrinter is implemented as a Functor, too (using the standard Python __call__ as the initiator). I like Visitor Functors as they allow you to implement clean and simply testable approaches to execution-state-based behaviour (e.g. then indentation depth of the tree) without compromising the implementation of the data-structure being walked or having to pass long lists of parameters.

Now you might think, "Isn't this just multi-methods?", and in a way it is except this implementation allows for inheritance - both in the argument types and in the implementers. That is to say, if you implement an override with @when and an object is a subclass it will be recognized. Secondly, the mechanism will look back up the implementation tree to find an appropriate method. Essentially the rule goes: look for a typed method the specific typeof the argument in this class, then in its parent classes, then look for a method for the next abstract type of the argument in this class and its parent classes, [repeat up the argument abstract types....]. An example is easier (and check out the tests):

from typed_calls import *

class A(object):pass
class B(A):pass
class C(B):pass

class BaseClass:
    __metaclass__ = ClassWithTypedCalls
 
    @when('method_call',B)
    def call_in_base(self,argument):
        return 'call_in_base'
 
class TestClass1(BaseClass):
 
    @when('method_call',A)
    def call_in_test_class_1(self,argument):
        return 'call_in_test_class_1'
 
class TestClass2(TestClass1):
 
    @when('method_call',B)
    def call_in_test_class_2(self,argument):
        return 'call_in_test_class_2'
 
test_object1 = TestClass1()
assert test_object1.method_call(A()) == 'call_in_test_class_1'
assert test_object1.method_call(B()) == 'call_in_base'
assert test_object1.method_call(C()) == 'call_in_base'

test_object2 = TestClass2()
assert test_object2.method_call(A()) == 'call_in_test_class_1'
assert test_object2.method_call(B()) == 'call_in_test_class_2'
assert test_object2.method_call(C()) == 'call_in_test_class_2'

Caveats:

this only dispatches on the type of the first argument. You can pass more arguments through but they will not effect the dispatching (exercise for reader to extend...)
mechanism is relatively efficient, but will not be as fast as doing a hand-written double-dispatch/Visitor pattern
when debugging you will see and extra level of stack per call - can be off-putting to some
all instances of a class share the same typed-methods. Cannot (currently) override on a per instance basis like you can with normal Python functions

Now as much as I've written this and am sharing it, I would say that this is done as a 'patch' to provide a better/cleaner way for developers who cannot/do not want to write better code. If you think you have need of this, please consider changing your code to be better by:

implementing double-dispatch on your classes. Makes thing much easier to test and allows greater extendability to other programmers without having to change your code
not using base types (int, list, dict, etc.) as primary types in your model. Wrap basic types and use trivial sub-classing. In concert with double dispatch makes your code more testable, understandable and extendable

If you do want to use/try this download typed_calls.py and the accompanying tests _test_typed_calls.py

Objects, eXtreme Programming, Eigenharps : How Innovation Turns To Infection

2011-04-27T02:20:00.000-07:00

Its happening to me again. That feeling. I've had it a few times during my life. It's a combination of excitement, confusion, giddiness, occasional nausea and mind-expanding joy. Of course there is a downside: long hours in dark rooms alone, staring into space and the raving. If it sounds like I'm on drugs, it's not far off - and I'm addicted to it.

What am I talking about ? New technologies that undermine the current thinking and enable a whole new way of doing something but are not yet fully formed and accessible. I'm not talking about those "new technologies" that marketing people push at you as "the next best thing", nor the latest tech-fashion received via Twitter, I'm talking about those ones way over before the "innovator" section of the technology adoption curve. The ones that creep up on you and lurk about on the edge of your perception until you notice them - at which point they come to possess you and the world is never the same again.

They're relatively easy to recognize: They're quirky and weird. Often referred to as "academic" or "cool but not practical". There's usually little or no effective marketing involved. They have interesting demos or descriptions that make me go "hmmm" but I'm often left with the feeling that the demo doesn't quite get across the whole point. People using them often say, "I've learned a lot..." but have not actually achieved anything practical. The documentation and tutorials are written in some magic incantation jargon which feels like it involves the use of a pointy hat and a stick. Now many ultimately poor technologies fit these parameters - but always, always these other ones have a "something extra" that nags at the front of my brain and possesses me, and usually it starts with "But what if...".

This has only happened to me twice in the last 25 years: Objects/Smalltalk and eXtreme Programming (XP). And its happening to me again with Eigenharps. This has caused me to reflect on the process where these weird, lurking things turn into acceptable and (dare I say) mainstream ideas.

The current, broadly accepted model of technology adoption is known as the Diffusion of Innovations model - popularized in the book and zeitgeist of Crossing The Chasm (always nice to see an old idea profited upon by others 40 years later). But I have always felt this model was weak on how ideas become infectious in the first place - how do the Innovators get the "bug" and how does that get translated into a palatable form for the Early Adopters?

In practical terms, these are the practices I have seen happen that enable these ground-shaking ideas to become infectious and practical:

Small Interest Discussion Groups - personally, Objects had the BCS OOPS group (by extension the OT crowd) and XP had the eXtreme Tuesday Club (XTC). Small groups of similarly obsessed people who got together to talk and share thinking. Much talk involving, "What does it mean?", "How do I...", "What I've found...". Now to be clear these were not like-minded people - in fact the very variety of minds produced a synergy where the fundamental idea was converted to the more palatable, accessible and understandable form. This is highly interactive and face-to-face. Email and web supports it but the real grist is in the eye-to-eye, blow-by-blow, hands-on collaboration. Often this involves a lot of critical thinking (and criticism) of the original idea and how it is portrayed, this means that the originators need to have thick skins and....
Let The Idea Go And Accept What Happens - originators need to let the idea grow-up by itself. You can't control it. You can't necessarily predict what its impact or meaning will mean to the people down the line. Not so much "build it and they will come", more "build it and let it find them". Listening to what is discussed and how its described helps you re-work the way you talk about it
Find the Discipline for the Flexibility - most of these ideas contain huge amounts of flexibility which is always vaunted as a good thing, but its like a box of very sharp knives - extremely dangerous in the wrong hands. Success seems to come when people find the right discipline of practices to apply when using the flexible tools (however, in my observation, discipline is the thing most adopters struggle with)
Let Others Talk / Translators & Ambassadors - originators can often be detrimental to their own ideas. Letting a "secondary" set of people - let's call them the aunts and uncles of the idea as opposed to the parents - do the talking seems to produce the most effective route to adoption. Aunts and uncles have enthusiasm having struggled and achieved with the technology and can talk to others like them. Originators can never reach and talk directly to all the sub-interest groups effectively, the aunts and uncles can - and usually for free!
Use It As A Teaching Tool (for Adults not Kids) - new ideas often are pushed as 'great/new ways of learning X' but I think a mistake often occurs in this thinking by then targeting children. What I have seen as a more effective tool is to use it to educate adults - essentially giving them access to a domain or discipline they feel excluded from currently. These technologies often get you more quickly to the 'value' than other approaches which usually require more training than learning. I saw Objects and XP draw in a number of people outside of what would be considered programmers/technologists through accessible education approaches. These people then succeed and become aunts and uncles of the idea - in fact, they are often the greatest proponents

I experienced these five practices occuring with Objects and XP, and have talked to people in other disciplines who have observed similar early-early-adopter practices. Ultimately, the outcome of these is a more understandable, applicable version of the original idea which can then be taken up by the Diffusion process. Its sort of the 'infectious idea' petri-dish.

So, as an open letter to the Eigenlabs guys, here's my thoughts on how this applies to the Eigenharp:

Small Interest Groups - need to start these in various places. Get Eigenharpists together regularly to just talk/jam. Can't be done by the company, needs to be a grass-root movement. This is really an action for me - need to start one in London. Anyone up for a London-based Eigenharp jam once a month?
Let The Idea Go And Accept What Happens - think Eigenlabs doing this well enough - maybe need to listen more to the non-musicians who are adopting your product? Opportunity is huge in that market IMHO
Find the Discipline for the Flexibility - there's definitely a whole missing section of "how to..." documentation and "my way of playing...". Capability is there but its so flexible that its difficult to adopt quickly. Documenting "How to..." discipline helps with this.
Let Others Talk / Translators & Ambassadors - think this is happening with people like Geert - but need more and more out there
Use It As A Teaching Tool (for Adults not Kids) - think this is missing completely. I've handed the Pico to some non-musicians and within 10 minutes got them "sounding good" without any trauma. In fact, they've all said something along the line of, "Wow! I could imagine getting one of those and learning to play" - its an inversion of the usual music learning model: sound good then learn why.

Playing the #Eigenharp Tau like a Guitar with AAS Strum GS-1

2011-04-18T07:31:00.000-07:00

Geert Bevin put a video on YouTube of him playing his Alpha with the Orange Tree Samples Evolution Acoustic Guitar. Having just received my Tau and having a copy of Applied Acoustic Systems Strum Acoustic GS-1 I thought it was a good exercise to learn about the Tau and get an alternate playing style/sound which was more guitar-like. I also had an idea about using the Arranger to do strum/pick patterns....

You can see from the picture on the left (that's not me, it's Dave(?) from EigenLabs playing at NAMM 2010) that the playing stance of the Tau is generally around the big keyboard on the right in the picture. The keys on the lower-left are usually set-up as percussion keys with drum sounds, but being an Eigenharp they are entirely configurable. So why not set the percussion keys up to strum/pick the instrument like it was a guitar? (a la Geert)

Play It Like A Geertah
Strum, like some other Guitar VST/AUs, allows you to use a section of the notes (C5-C6) to control the strumming/picking action of the synthesized guitar. For example, holding down a G chord does nothing (if you turn Auto-strum off!) until you hit C5 which gives you a down-stroke. D5 gives you an up stroke. E5-C6 give you string picks of the 6 strings (well, kind of E5/F5 gives 'bass' and 'alternate bass' which is not the same as strings 1/2). Black notes give you other things like palmed strings, muffled strokes, etc. So using Strum with the Eigenharp percussion keys was a matter of configuring them to be C5-C6.

Now there is a little Eigenharp subtlety here: You can configure the Eigenharp to split the big keyboard into sections, or keysets. I wanted to have the Tau configured so I could play chords with top 5 rows, strum/pick with the percussion keys and use the remainder of the large keyboard with a different voice. So that means using keysplit2 (for the Tau players out there) and configuring the voice for the top keyset and the percussion keys to be the same. This meant I needed to use Audio Unit 3 (AU3) as it is the only one as standard shared between a keyset and the percussion keys. Handy.

Next I needed to configure the percussion keys to start at C5 and be in the major scale (so I'd get the white notes for control). This meant I needed to do some Belcanto (the configuration script for EigenHarps). Its not the most accessible language/tool I've ever come across and I'm a geek! But I persevered. Eventually, I ended up with the following script which configures the percussion keys:

description
    Set up percussion keys to work for AAS Strum GS-1 as strum/pick keys
script
    percussion kgroup hey tonic to notec set
    percussion kgroup hey octave to 5 set
    percussion kgroup hey scale to major set

This can be saved into ~/Library/EigenLabs/Scripts and accessed through User Scripts in the EigenBrowser. Or alternatively, you can type the bits below 'script' into the command line of the EigenCommander. (Or if you're really adept play it via the Eigenharp itself - not figured this out yet!)

Once run, configure AU3 to use AAS Strum via the EigenBrowser (switch Auto-strum off in the Strum UI). Select keysplit2 and assigning AU3 to the voice of keyset2. Then set the voice of the percussion keys to AU3. Then play!

This set-up provides for up/down strum on the first two keys of the percussion section and picking on the next 6. You get a much more guitar-like stance and style to your playing (plus proper picking opportunities with your right hand) and a great selection of guitar sounds. I believe this should work with the Electric Guitar version, too.

(NB: careful when changing scales not to do a "global" scale change or the Strum set-up on the percussion keys may not work as you think)

So what's it like to play? Really good! You get a very natural, expressive guitar playing experience. Because you have such control with the Tau in combination with Strum it possible to not only get nice bends, slides and hammers but also you can control the effects with lateral movements of the keys. I have one set-up where I control the WahWah this way - fascinating to play!!

One thing I wasn't sure of, but turned out just to work, was the recording of strum/picks with the built in Eigenharp scheduler. But it works beautifully. You can lay down a nice guitar strum/pick sequence to a drummer track then swap to an alternate keysplit where you can play two different parts with your now free two hands.

Making Arrangements
The other idea I had was to use on of the Tau's Arrangers to define a strumming/picking sequence. The Arrangers are step-sequencers which you configure by using the large set of keys to define a pattern - usually of drum or rhythm samples. So why not use it to fire the C5-C6 in an appropriate pattern? This way I could play chords with left hand, get a fancy custom strum/pick sound and play melody/lead with right hand in another keyset? (think arpeggiator)

Strum does have a built in arpeggiator which uses MIDI loops, so I could just use that. But that would mean having to create/load a MIDI loop any time I wanted to do an arpeggio. One of the main things I like about the Eigenharp is its 'liveness' and not having to go back to the computer keyboard to endlessly edit loops/sequences. No - I wanted to use the Arranger!

But I hit a speed bump: Arranger 1 on the Tau can only use AU4, but you can't access AU4 via any of the keysets !?? This means I can't have the Arranger firing C5-C6 and a keyset playing the notes for the chord. This is surprising to me given the flexibility of everything else on the Eigenharp. I have asked a question about how to change this (I presume some clever Belcanto script might do it) but with a standard set-up it just not possible :-(

But...

Maybe I can send MIDI from Arranger 1 and from the keyset to Strum running outside EigenD ? I'd loose some expression but I'd get my combination of arranger and keyset.

Hmm...not obvious. Nothing in the config seems to let me send MIDI from the Arranger....arrrrgh

So I ask the Twitterverse for inspiration - and hey, presto!! @MikeMilton sends me a reference to a snippet of Belcanto he got in a reply to a similar question.

Again after some twiddling with EigenCommander I got it working. Here's the script:

description
    Set up Arranger 1 to work with AAS Strum GS-1 as strum/pick control
script
    arranger 1 listen
    clear
    midi rig 1 recorder listen
    note 15 with velocity 1 when 1 play
    note 16 with velocity 1 when 2 play
    note 17 with velocity 1 when 3 play
    note 18 with velocity 1 when 4 play
    note 19 with velocity 1 when 5 play
    note 20 with velocity 1 when 6 play
    note 21 with velocity 1 when 7 play
    note 22 with velocity 1 when 8 play
    all join

This sets up Arranger 1 to send out C5-C6 to the MIDI. (as before save as a User Script or use EigenCommander). Select MIDI in your keyset. Run up Strum as an application. Set MIDI to Omni (simplest approach). Swap to Arranger 1, set-up a strum/pick pattern (course 1 is down stroke, 2 up-stroke, etc in chromatic order). Swap back to keyset. Start metronome and hold a chord pattern down. Voila!

Haven't quite got used to playing it 'live'. Still not got start/stop smooth. I've only had the Tau 2 days, though! There's definite value in the approach. I've found myself being quite funkadelic with it. Hopefully some EigenharpBelcantoMeister will help me out so I don't need to do this via MIDI.

The combination of Guitar synth and Eigenharp is incredible. The ease of playing and expressiveness is stunning. It leaves you in that zone of playing where you listen to the instrument rather than concentrate on the mechanics. You can play manually or you can get some CAP (computer aided playing) - your choice. But one way, or another, you get to play expressively, sound great and enjoy.

I love the Eigenharp (sigh)

#Eigenharp, My Ignorance and @david_harvey

2011-04-08T02:49:00.000-07:00

I freely admit I am pretty ignorant when it comes to being a real musician. In fact, I was quite happy being ignorant and playing stuff by ear/instinct for the last 30 odd years. But playing my beloved Eigenharp and writing EigenTab (a helper app for mapping chords to key/scales) it has been quite an education. Nothing like having to write an application from scratch to make you question your understanding of a model!

I enjoy discovering and understanding models through writing software. I'm not good at memorizing things but need to understand how things are constructed (bad at history, great at maths, you know the kind). Software is great for this, especially when you take a test-driven approach. So with EigenTab I got so far and realized that I couldn't move forward without getting some answers to basic axiomatic and WTF kind of questions. For all the information out on the Internet, like most subjects you get to a point where the jargon over-powers your ability to understand it. Now I'm no dullard and am capable of understanding this stuff but I am not an idiot - why would I spend ages trying to decode this mass of jargon when I can ask someone who knows it? (Nolan's Rule #4: Shared Seat-Of-Pant's Rule : if you can't do it by the seat-of-your-pants, use the seat of someone else's more experienced pants).

Enter Mr. David Harvey, stage right (well the back of The Water Poet, really)

I've known David a long time through our shared profession of software development, however, David is a real musician. I mean he was actually educated in it, has degrees in it, still performs, he was even CTO of Sibelius . So if there was a seat-of-pants to consult, it was his. (And he owns an Eigenharp Tau)

So I had, what I thought, was a simple question: In EigenTab it now shows the note names on keys for the configured scale. If the note is a 'black' note do you care if it shows sharp or flat? Aren't they the same? Isn't it just musician prissiness?

Half an hour later (that's how much time we had) I'd gotten a full low-down on scale construction, chord theory, modes and even how Jazz musicians improvise. I think about 35% stuck. But I thought it worth writing down what-I-learned-from-David:

sharps and flats are not the same! For example F# and Gb are not the same. Now I'd come across this when overhearing muso's (mainly rock like guitarists) talking, and after thinking about it I remembered the guy who taught me basic trumpet saying something similar. Apparently, F# is lower than Gb
the main reason there's a good/bad way to refer to notes in a piece of music in a given scale is because scales are constructed from a pattern of rules about what to do to generates the notes in the scale. For example, a minor scale contains a minor third - that is to say it contains a note that is three notes up the stave (literally counted from the root or tonic note) and then dropped back down a semi-tone (making it flat if it's black). Whereas you might see a similar 'black' note in a different scale containing an augmented second, which is constructed by going two notes up the stave and adding a semitone (making it sharp if its black) (see previous point that they are not actually the same note). So scales are actually defined by a set of rules not just notes.

this means I need to change the EigenTab implementation to be correct

I was always a little perturbed by all that Ionian, Dorian, etc. talk. But apparently to figure out the note intervals in semi-tone terms you can do it by thinking about the white keys on a piano. It seems that if you start at C and play the white keys to the next C its an Ionian scale, and if you start at D and play to the next D its the Dorian ! In fact there is a scale starting on each key:

C = Ionian
D =Dorian
E = Phrygian
F = Lydian
G = Mixolydian
A = Aeolian
B = Locrian

It's spelt loCRian not loRCian - for years I've thought it was loRCian. duh.

Now in the 65% of stuff I didn't retain was something very interesting about Jazz improvisation where Jazz guys improvise by playing say a minor scale above a triad chord played in a different scale (??? I think that's what he said...). The really interesting point for me, though, is that with the Eigenharp (well Tau and Alpha) because you can split the keyboard and have different scales, it might be possible to make Jazz-like improvisation easier without needing to have full chromatic scales on the keys. David did say the choice of scale is dynamic depending on the chord played, but that's a solvable problem in software (id the chord, pick a 'good' scale). Of course to do this I need a Tau or Alpha and the imminent release of the open-source version of EigenD.

There were two other outcomes of this meeting:

I now know what it must be like for normal people to ask me a question about technology (c.f. me/music/david with them/tech/me).
I need to talk to David more often about music and try to translate it into understandable, useable knowledge

Thanks, David. Next time I'll buy the wine.

Adventures in #Eigenharp Land

2011-04-03T03:30:00.000-07:00

So I was given an Eigenharp Pico for my birthday (a month early - result!). It is, quite simply, the best musical instrument I've ever played. And I have played a lot - I can play 8 different types of instrument not including drums (none of them brilliantly, though).

If you are a techy and in anyway musical YOU SHOULD BUY ONE OF THESE NOW. I'm not going to give you a list of reasons - JUST DO IT.

For all its brilliant-ness, it is challenging to learn the Eigenharp. Unlike conventional musical instruments the Eigenharp does not have all the notes available on the keyboard - you configure which key and scale you wish to play so you end up only having those notes. This is extremely useful for improvising and general noodling - but if you are an untrained, picked-it-up-as-you-went along musician like me, trying to play written music can be very frustrating. I can't look at a set of chords or sheet music and say, "oh, of course, F# dorian" - especially those chord sequences scribbled on the back of a beer mat in bad light at a dive during a folk-funk-punk-fusion session. Also, this key/scale configuration means there is no standard way to play "Am". The same chord shape is "Am" in C/major but "Dsus2" in E/blues.

So being a programmer I wrote myself an application to help me with this: EigenTab. You provide a set of chords and the app tells you what your key/scale options are. It also shows you the chord shapes. It has helped me get to grips better with the Eigenharp.

Of course, I set myself unreasonable goals in writing the app: write once, test-driven so that it will work on major platforms (including windoze, osx, linux, iOS). And no conditional code that says anything like 'if windoze...'. Also, had to work offline without a server.

After a couple of false starts I ended up back with a most basic HTML/Javascript approach. Had to strip the UI of all graphics and 'fancy' interactions (like hover or other event behaviour). But in the end developed a 20K application that does work under all main OSes/browsers and even can be cached as an 'app' on the iPad. Have to say I'm pretty pleased with it and it makes my Eigenharping much easier.

Lessons in Managing Self-Organizing Systems: My Father, Squirrels & Birds

2010-11-16T05:44:00.000-08:00

My father had a running battle with squirrels. The age old story of escalating hostilities between man and sciurine ingenuity: bird table, nut-feeder, wire, so called squirrel-proof feeders, mesh, string...you probably know the story. All to no avail. Mr.S.Nutkin was not to be deterred; birds were going hungry; my father's tactics were heading towards firearms.

This problem was a classic self-organizing system with an issue: each element was autonomous and independent (father, squirrel, bird, table), each operated within the same environment, communication was indirect via the environment, no direct control could be exerted between the elements and the emergent results were sub-optimal for all involved.

Amongst the things I have learned whilst studying and building self-organizing systems (and running S.O.teams) are

often the solution to a problem like this is counter-intuitive and based on inverting an assumption or goal
by trying to fix the problem you become and element in the environment yourself, and all the rules apply to you too - especially the no direct control rule
the only effective way to alter a self-organizing system is to alter the environment through adding/removing elements and allowing new behaviour to emerge
you cannot predict the total outcome of changing the environment and must be prepared to accept consequential behaviour

So applying Lesson 1, I decided to address the basic problem: How to stop the squirrels eating the birds' nuts? Inverting this I came up with the simple question: How to stop the birds eating the squirrels' nuts?

Lesson 2 told me I couldn't do anything to change the birds, the squirrels or my father directly. I could spend quite a bit of time on this but in the end it would just come down to an argument about philosophical positions. And my father probably wouldn't listen either.

Lesson 3 told me I had to add or remove something from the environment to affect a change. There was no way to remove all the birds or all the squirrels, nor stop my father feeding the birds. So it meant I had to add an element.

So I bought my father a squirrel feeder that the birds couldn't use.

Within 2 days the birds and squirrels were sticking to their own feeders. The birds were happier. The squirrels were happier. My father no longer had that look of murderous intent.

In fact, this simple act of management was so successful that some of the shy Red Squirrels from the forest behind us started frequenting the squirrel feeder (who knew it was the birds they were afraid of?) That's the upside of Lesson 4. The down side was that there are now twice as many birds and squirrels in the garden and my father is having to buy twice as much food. There is also some emergent behaviour in the pheasants hanging out under the squirrel feeder for the cast-offs which is causing the grass to be worn away. Oh, well. That's self-organizing systems for you: never done.

So why do I offer this parable?

The term self-organization is thrown about very freely when people talk of groups, teams, management and organization. When it comes to looking at the actions, rhetoric and advice given I feel that much of it falls into the "pop-sci" or "pop-psych" category, and often misses the point that the manager/facilitator/coach is an element of the environment and subject to the same rules. Moreover, self-organization is referred to as if it were an understood thing - which it is not by a long chalk.

I offer this parable and 4 lessons as items from my experience. I place them in the environment. And awaiting to see if there is any emergent behaviour.

Contempt, not for software developers, but for all they do

2010-11-13T11:16:00.001-08:00

I have recently spent quite a lot of time reading tweets, blogs and current publications on Software Development. I feel despondent, despairing, bitter and isolated. I feel the "agile movement" has lost it's way, got diluted, compromised it's fundamentals, become a banner of convenience. I feel contempt for this movement of which I was an early practitioner, proponent, zealot. Though, for the individuals involved, I still have respect and admiration - they are bright, articulate, rounded people.

And for all this, I felt ashamed. My arrogance, my hostility, my mourning for a passion lost to the betrayal of others.

But these feelings were familiar. They resonated with a recent empathy. Then I remembered a passage from Seven Pillars of Wisdom (T.E.Lawrence's account of his part in the Arab Revolt during WWI). Talking of how he felt some years after having left Arabia, he wrote he had

"a resultant feeling of intense loneliness in life, and a contempt, not for men, but for all they do" (ch.1,p32)

This is the feeling I have.

Other passages have congruence with how I see the current state of the 'agile movement':

"As time went by our need to fight for the ideal increased to an unquestioning possession, riding with spur and rein over our doubts. Willy-nilly it became a faith. We had sold ourselves into it's slavery, manacled ourselves together in it's chain-gang, bowed ourselves to serve it's holiness with all our good and ill content. The mentality of ordinary human slaves is terrible - they have lost the world - and we had surrendered, not body alone, but soul to the overmastering greed of victory. By our own act we were drained of morality, of volition, of responsibility, like dead leaves in the wind." (ch.1,p29)

Others speak to how I feel about my history with agile:

"The moral freshness of the world-to-be intoxicated us. We were wrought up in the ideas inexpressible and vaporous, but to be fought for. We lived many lives in those whirling campaigns, never sparing ourselves: yet when we achieved and the new world dawned, the old men came out again and took our victory to remake in the likeness of the former world they knew. Youth could win, but had not learned to keep: and was pitiably weak against age. We stammered that we had worked for a new heaven and a new earth, and they thanked us kindly and made their peace." (introduction to later editions)

In these words I find solace. Men far greater than I, more central to more important histories, have fallen prey to these feelings. In the pursuit of what you believe to be a better way of the world, maybe there is an inevitability in the course of human history for the vanguard to become dissolute with the world they help forge. Yet in these new worlds there is value and benefit for others - it is a better world for them. For the vanguard it was about the pursuit of the ideal, the journey. For the rest it is about the destination of being somewhere better. These two things can never sit well together.

So where does this leave me?

In looking for new employment I discovered that I unwittingly undertook a similar path to Lawrence. Although I am being offer Head of Development/CTO roles, I find myself drawn to being a programmer at the bottom of the pile. I even went as far as to draft an alternative version of my CV removing my management and agile experience (but have not used it). Lawrence re-enlisted in the RAF under an assumed name, but was discovered, at which point he enlisted under another name in the RTC where he was unhappy. Maybe this is something I should take heed of?

Further, I have come to recognize that I am a 'vanguard' kind of guy. I suppose I always have been. And in that there is an acceptance. I should feel no shame but know it is time to move on and let the followers settle. Those who make the war cannot make the peace.

- Posted using BlogPress from my iPad

To Make Money Selling Shovels: First, Buy All The Shovels Then Create The Demand

2010-11-02T08:35:00.000-07:00

The adage "The people who make the money in a gold-rush are those who sell the shovels" cropped up again as I was perusing the blogo's fear. It is an analogy I have used myself but I have no idea if there is any truth to it, or like many urban-truths it is merely short-hand for a presumed truth? Or, if there is truth to it, what more might we learn from the fuller, less sound-bitten story?

Thankfully, there is truth to the statement and I have not been guilty of repeating an urban-truth. Reading historical research of census data (like this difficult to read paper) there is statistically significant differences in the relative benefits to merchants (including shovel sellers), hotel proprietors, doctors, etc. (i.e. service providers) relative to the miners themselves. In fact, although the miners were better off in absolute terms (earning on average 3-4x what they would have elsewhere) they were worst off in relative terms because the merchants and other service providers were charging them at extortionate rates.

What is not clear from the analogy, but is from the census data, is that on the whole it was the service providers who were already there and held the distribution points and land that made the money. Many who came along later suffered a similar economic fate to the miners themselves, although they were still more assured of moderate, relative wealth than the miners. I could find no examples of anyone who had come along later with "a better shovel" who became extremely wealthy as a result. Being there first seems to be key.

The man who became the richest guy in California at the time was Samuel Brannan , who is the focus of the adage about shovels. In 1848, Brannan found out about the gold discovered at Sutter's Mill through people buying goods from his store using the gold they'd panned during their spare time (he also collect Mormon tithes in gold). Brannan was no 'poor store keeper' - he had established a couple of newspapers and had the store in Sutter's Mill and was the Mission President of the Californian Mormon Mission. Using his capital, he bought up as much prospecting equipment (including shovels) as he could in San Francisco and then, brandishing a bottle full of gold dust, ran through the streets shouting, "Gold! Gold! From the American River!". He created such a sensation that one of his papers couldn't publish the news as all the staff had left to look for gold. Brannan used his income to buy and sell land during the ensuing Gold Rush.

So what can we learn from this story?

Be observant and find something considered valuable being done by other people
Monopolize required, necessary resources before you....
Generate unreasonable demand through sensational promotion of the thing and then...
Charge over-the-top margins whilst you...
Re-invest the profits in further monopolisation

I feel so much better about this analogy, now.

Leadership: Listening, Understanding and Disagreeing At The Same Time

2010-11-01T05:32:00.000-07:00

Reading the contents and comments on Paul Dyson's recent blog about "the Whole Team" and eXtreme Business I was reminded of a piece of dialogue from the West Wing: Josh and Toby are walking down the street arguing, and the conversation goes something like,

Josh: You're not listening to me
Toby: I am listening
Josh: But you're not understanding me
Toby: I do understand
Josh: But you're disagreeing with me
Toby: I am doing all three: I am listening, understanding and disagreeing simultaneously

Conversations of this form often seem to crop up in the context of running a business in an eXtreme manner and dealing with the "whole team". I think there is often a misunderstanding of the practice of "whole team" , confusing participation with democracy. If you think "whole team" means 'democracy' you're ignoring the factors of responsibility and accountability.

Running any business or team requires both leadership and management skills. Leadership provides the vision of the direction and formulates the goals for the group, which they can then work on together (so becoming a team). Management defines the constraints (like budgets and resources, choice of technologies, etc.) and ensures that there is consistency and achievement of the agreed goals over time. Both of these require a lot of listening and understanding of what the group has to say. However, the decision about what the direction, goals and constraints for the group must be made by those responsible and accountable for the outcome of the group's efforts. This is often where the disagreeing comes in, usually because participants think their opinions (which have been solicited by good leadership practice) have been ignored rather than appreciating there are often a huge number of factors they have not taken into account that outweigh their position. To me, this is one of the big differences between a team and a group - in a team, members understand that the have been listened to and appreciated even when the decisions seem to be against their thinking, moreover, they continue with the same amount of effort and don't throw down their teddy-bear.

My attitude towards leadership and management is strongly influenced by John Kotter's early work. Part of his position was that it is hard to find individuals who have both the leadership and management skill-sets sufficiently developed and balanced to provide that mythical "charismatic business leader" whose presence guarantees success. From my experience I think this is true - individuals are usually more one or the other - however, I think the Kotter model overlooks the practice of having a pair, or a trio, running a team or business.

Having a true pair working together means that one can be undertaking leadership practices while the other balances with management practices - often these role swap backwards and forwards between the two on the scale of minutes, hours and days. With businesses or large groups, I think three is a better "responsible team" size - this provides the extra mediator practices sometimes required to balance the conflicts that can occur between leadership and management goals. I have worked with this model both at Connextra and e2x and found it to be a most effective model. Though I don't ever say it explicitly, I also try to influence any teams I have created or work with to form this same triumvirate structure for the responsible group. Needless to say, with three it is often the case that one is listening, one is disagreeing and the other is trying to understand how to resolve and synthesise the situation (allusions of classical thesis, anti-thesis and synthesis). However, I find it works better than other forms of organization.

Domain Specific Language Snobbery

2010-10-07T01:58:00.001-07:00

At JAOO, James Gosling gave a talk before mine on his recent experience with the Autonomous Audi TT at Stanford. Within this presentation he talked about the use of Matlab and Simulink as Domain Specific Languages (DSL) for mechanical engineers. The tone of this, and even more so talking with people afterwards, was that somehow DSLs like these are not 'real languages' and are to be sneered at for their lack of scoping or inability have closures. Even the fact that when the translated code (from Matlab to Java) was shown to the engineers and they're said it didn't make sense to them was seen as an amusing anecdote about how misguided mechanical engineers are about software, the poor dears.

What unmitigated, bourgeois snobbery and arrogance.

All programming languages are DSLs, you dummies. Its just a different domain - that of current models of software. You are no better with computers than these people you sneer at. There is more of their code controlling the world and making it a better place for the majority of humanity than there is for the systems delivered by so called software engineers. We should be listening to them and helping them, not sneering at them and congratulating ourselves on our superiority. Need to destroy the 1v0ry towers we're inhabiting and learn a little humility.

Here Be Algorithms

2010-10-07T01:33:00.001-07:00

I gave my "need for speed" presentation a JAOO in Denmark on Monday (4 Oct 2010). It's an overview of using "exotic hardware" like FPGAs, NFPs, SIMD processors and GPUs for accelerating applications. Must admit didn't feel I gave my best performance (sorry to attendees for that) (Update: got my audience feedback and I got a "great presentation", top marks! Shows what a judge I am) - it was a bit of a formal set up with banked seating and bright lights pointing at the presenter so it was difficult to see the audience and engage them.

Having said that, the questions and discussions afterwards did re-emphasize a belief (prejudice?) I have had for some time : algorithms are a weakness in current software developers. In fact, I told a story of using Linear Programming to solve an optimisation problem rather than using the brute force approach used by the original programmers. Of the 9 people listening, all software developers, only 2 were aware of the technique and neither of them knew how to even approach solving a problem with it. I found this shocking. Although I shouldn't be: in my experience I find software developers are unaware of many techniques to solve certain types of problem effectively and efficiently.

I wonder whether this is a co-evolutionary outcome of computers becoming more computationally powerful and programming tools becoming more accessible and productive. It has become possible over the last 10 years to solve bigger problems brute-force within the cycle-time programmers are comfortable operating within (you know: the code/compile/debug/coffee cycle). As a consequence, it seems to me the emphasis on good algorithms has faded. Additionally, the removal of technical requirements "solved" by things like garbage collection and the misinterpretation of techniques like "do the simplest thing" seems to have lead to a place where algorithmics are "Terra incognita".

I think their are visible signs of this when you start investigating systems with performance issues. Most commonly these days I find the problems are due to the algorithm used not taking the computational constraints into account. I see everything from creation of unnecessary amounts of garbage to disregard for the effect of network traffic. There seems to be a belief that the system should "solve" these problems for you - and more often than not when I give this "exotic hardware" talk the hope is that these solutions will magically solve performance without the need for the developer to make any changes to their simplistic approach to algorithms. Unfortunately, this is not true, and furthermore I see no chance of current development tools being able to hide the impacts of these newer hardware architectures from the developer.

Some of the people I talked with were students who told me that they have never had any kind of education about the practical implementation of algorithms. They have done classic computer science algorithms (bubble sort, etc) and have been taught programming languages, but they had never had to join these two things up! In fact, when asked, I could think of no reference apart from the greet 'numerical recipes' books - and they don't cover the use of higher level algorithms like Linear Programming or Map-Reduce or Data Parallelism (I.e. How to implement create a model to utilise these approaches for efficiency purposes).

So it seems to me there is a big hole in software development currently: algorithms, using them and implementing them. I feel that we are all the poorer for it and fear it may actually be limiting us. In fact, I think that we are going to hit a technological speed-bump when shortly we need to start using hardware that incorporates on chip SIMDs and FPGAs for performance reasons. The compilers will not be able to save us. We need to go back to a more basic algorithmic approach to get the advantage, and it seems to me current software developers have lost or have never gained this skill.

- Posted using BlogPress from my iPad

Thoughts on John von Neumann's "The Computer and the Brain"

2010-08-02T03:41:00.000-07:00

I like to read old computer texts to get a different perspective on the technological context we find ourselves in today. Given my current obsession with how the brain works (or doesn't, rather) it struck me that I had never read John von Neumann's "The Computer and The Brain".

In 1955, von Neumann was invited by Yale university to give the Sillimann Lectures in the spring of 1956. For his theme he chose, "The Computer and the Brain", a subject he'd been interested in for a number of years. Sadly, von Neumann became too sick to give the lecture series - in fact, he never finished the manuscript before his death in February 1957. Being only 82 pages long, it took me less than an hour to read. Yet for all its brevity it was extremely thought provoking...

why are we emulating neurons in software when their may be a hardware equivalent? This is not a unique thought - Carver Mead did some work in the 1990s which has lead to the Neurogrid project a Stanford. (Mead is the guy credited with coining the term "Moore's Law"). The Neurogrid chip emulates ion-flow across a neuron's membrane using electron-flow through a transistor (its the same physical forces after all!). Seemingly, they can emulate neurons with as few as 8 transistors. The chip therefore is populated with these hardware neurons instead of the usual logic gate configurations of a standard CPU. Seemingly, they get a hugely more efficient emulation of neuronal activity.
much emphasis is put on the neuron, leaving the brain as a collection of neurons rather than considering it as a whole complex system. It is a continuously running system which has a number of physical and chemical processes being applied to the neurons. Von Neumann uses the analogy of neurons being like AND/OR gates for nerve impulses from 'upstream' neurons (with a bit of non-linear sigmoid functions thrown in). This is a view I've never been comfortable with, but in my experience it is still the prevalent belief amongst technologists.What about the effects of neurotransmitters? What about the physical effects of increased blood flow when areas of the brain are active? (surely the physical movement of neurons will effect the excitation patterns?). We seem to think of the neuron as a node which has some consistent, simple behaviour but when in reality it is a complex item in its own right and is a member of a complex system where it is behaving in a stigmergic manner. (NB: stigmergy = where individual behaviour is effected by and affects the environment, producing larger scale emergent behaviour amongst independent agents)
ignoring the power issue (brain ~=20W, modern single CPU ~=80W) how close are we to emulating major neuronal activity with conventional hardware? In 1989, TJ Sejnowski wrote a paper revisiting "The Computer and the Brain" which predicted that by 2010 we should have computer that could emulate the "minimal processing capabilities of the brain", which he put at 10¹⁵ operations per second. Let's be generous and just call these petaFlops (I know they're not floating point ops, but this is only a blog...) . Currently, the Top500 list has 6 supercomputers peaking over 1 petaFlop (in fact the first petaFlop machine was around 2006) - these of course are using 10s of thousands of cores and drawing megaWatts of power!! There is work going on with these, and there was the controversial "big as a cat's brain" paper last year. But what about more realistic hardware, say something I could run on my desktop? An NVidia Tesla M2070 can produce about 1 teraFlop (and its SIMD so suitable for neuronal simulation) so surely it could be used to simulate the neuronal activity of a simpler organism such as an ant (~10,000 neurons) ? (During this same investigation I came across Steve Furber's (the ARM chip guy) involvement in the SpiNNaker Project - using arrays of ARMs to simulate neuronal activity. Looks interesting , too)

101: (Lack of) Progress Report

2010-08-01T04:01:00.000-07:00

As the engine isn't moving on the starting handle any more and working on the maxim "try everything else before stripping the engine" I began removing and checking...

As its likely the clutch is stuck and for some reason the gears were engaging (even though it seemed to be in neutral in both gearboxes) I decided to address the known problem of the hydraulics not working for the clutch. Stripped out the master cylinder, which amusingly requires the removal of the pedal housing which is bolted to the front panel of the 101. This made me think of just how close to death I am when driving this vehicle - is there a negative star rating for crashing testing? (see diagram)

Anyhow...turned out the master cylinder was gunked to high-heaven, so with some penetrating oil and some huile de coude it freed up. Reassembled the master cylinder and the pedal housing in to the vehicle then went to bleed the clutch system at which point I discovered I had no tubing in my workshop or house suitable. Now given the amount of stuff I keep hold of "just in case its useful" this is quite amazing. After a 40 mile round trip to my nearest motor factor (yes, 40 miles), I bled the system and got to the point where I now know that the clutch is stuck - hydraulics are working but the plate won't move. No surprise here, but the 'standard' way to free up a Land Rover clutch that's stuck is to start the vehicle in gear and bounce it until the clutch frees up. Small problem there...

So I then decide that the starter motor may have jammed when trying to start it on the ignition. So following the instructions in the Repair Manual, I dutifully remove the panel in the right-hand front wheel arch, "to facilitate access to the area". This gives me a nice view of the exhaust manifold but no access to the starter motor! Top tip: do not bother opening panel. Removal is best done from underneath the vehicle. So after removing the starter, I tried turning it on the handle again. No joy. Sigh - starter motor back in...

Cautionary note: if you have long hair, as I do, and are using a wheeled crawler board, ensure that your hair is fully secured in a pony tail before rolling under the vehicle and getting a bunch of stray hairs entwined in the wheel of the crawler. No amount of swearing releases you.

As a final prevarication I decide that there is a possibility the gearbox is not going into neutral and that the "stuck" feel of the engine is from the transmission being fully engaged. So I jack up one wheel of the 101 using a high-lift jack (can't find the handle to my trolley jack) and try to turn it by hand, both in and out of gear. Sadly, it moves when in neutral but not when in gear (although its clear I'm going to have to completely strip and redo the brakes).

Arse.

This means that its really likely to be something in the engine and I'm going to have to strip it.

What would it take to make my own fMRI?

2010-07-28T08:48:00.000-07:00

So my brain is not quite firing on all cylinders at the moment and being a geek one of my thoughts is how to debug the problem. The inability to insert breakpoints, no console or printf() facilities and the lack of a decent IDE stumped me to begin, but I've debugged systems with these challenges before. It's normally hardware or embedded systems that present these challenges and some of the primary tools to understand the problems are logic probes and oscilloscopes - which got me thinking: what's the equivalent tool for a brain and can I make a cheap version for my own home use?

The first thing to spring to mind was the EEG (electroencephalograph) which records the electrical activity across the scalp which is indicative of the neurons firing on the surface of the brain (gyri for the Scrabble fans out there). There are indeed plans and instructions for building your own EEG out there on the 'net including the OpenEEG project which looks quite good and is within my technical capabilities (mainly limited by my soldering capabilities). But as a debugging tool, indeed an information tool, I think there are severe limitations.

An EEG measures the potential difference between synchronous synaptic activity of thousands of neurons on the surface of the brain. This produces two issues:

only shows an average potential across groups of neurons which are physically separated. Its very coarse grain and doesn't necessarily reflect the potentials between the actual synaptic routes in the brain. It's a bit like measuring the straight-line distance between two towns to estimate the driving time without taking the roads into account. Anyone who's driven the coast of Norway or Iceland understands why this is a problem
doesn't effectively measure activity deeper in the brain, especially any activity which is tangential to the surface of the skull (or even at an oblique angle)

Now there's no denying the value of EEG for the diagnosis of a wide variety of brain related problems, however, as a debugging tool it's a bit crude. It's like trying to debug a computer system using the flashing of LEDs, disk noises and fan sounds (we've all been there!). This can provide a very gross level debug (e.g. its not powering up) but is not much good for most software bugs.

To get information about the deeper goings on in my head in a non-invasive manner, that does not require the use of controlled radioactive isotopes, leaves me two options: the MEG (magnetoencephalograph) and the fMRI (functional magnetic resonance imager).

The MEG works by measuring the magnetic effects of the electrical currents in the brain. Unfortunately, these are only on the femotesla range (10^-15 T) - given ambient magnetic flux is in microtesla (10^-6 T) this not only requires a magnetically shielded room but the use of SQUIDs (Superconducting QUantum Interference Devices). While convincing my wife to allow me to paper a room with tin-foil and chicken wire might be possible, allowing me to have large quantities of liquid helium is probably out for a number of reasons.

So all I'm left with is the fMRI.

So firstly I had a look on eBay for a second hand MRI - but no joy (so you can't "buy anything on eBay" as some party-bores insist). However, I did find the DOTmed site which does have auction listings for used MRIs!! Sadly, these things are huge, mainly in the US, expensive and also require the use of cryogens. So its back to thinking "home-made".

Conventional MRIs use field strengths of around 1-2 Tesla (that's ~20,000 earth's magnetic field) which requires superconducting magnets, and hence cryogens. Equally, they are usually designed for whole body, detailed scanning. With fMRI scanning of brains you need a smaller scanner (head sized) and you need to rapidly scan a 'slice' (within 1-2 seconds) at low resolution to pick-up the changes in blood flow within the brain.

In recent years there's been quite of bit of work on Ultra Low Field MRIs which reduce the need to have superconducting magnets for imaging. For example, these guys at Los Alamos built the fMRI in the picture, which operates without superconducting magnets. It does use a SQUID detector array which requires cryogens and a coil immersed in liquid nitrogen, but its a step in the right direction for me. Even better, one of their papers explains the construction and even lists where to get some of the parts!

Is it possible to remove the need for cryogens all together?? There are some reasonable results of images generated using "conventional room temperature receivers" with Ultra Low Field MRIs, such as these ones from Aberdeen University. Images of this quality would be a result! In fact, these guys have also shown results using permanent magnets for small samples (why do I need to pay for access to a scientific paper?? What has happened to science publishing?)

However, it looks like Ultra Low Field MRIs need SQUIDs which = cryogens. So unless I can convince my wife to let me have liquid helium, it looks like I won't be building an fMRI. Of course, I then need to convince her to let me spend £8000 on parts...

101: It was all going so well...

2010-07-28T05:52:00.000-07:00

I knew it would stop being good news at some point.

Filled the oil up and it came through clean. Took the sedimentor off and the fuel was fine. Took the distributor apart - very little corrosion and the points look fine (did the normal maintenance). Recharged the batteries and fitted them (remembering, finally, that both need to be in place) - electrical power to all the vitals.Do a hand-crank to check the spark across the points and the engine decides to stop moving.

Arse.

Also, the clutch pedal is going all the way to the floor with no resistance bar the spring. Its a hydraulic clutch system, which I have refilled but not yet bled. Hopefully it's that. But the real pain is the engine not moving.

Going to have to do some engine debugging now...starter sounds and rattles, it was turning on the starter handle but now doesn't, clutch doesn't work but its not in gear. My brother's neighbour Stan's advice was "if it won't turn on the handle, you've got a stuck valve". Hmm. Looks like I've got a rocker/tappet strip in my near future. Might try removing the starter motor first, just in case.

101: Initial Investigative Foray

2010-07-25T12:56:00.000-07:00

So had a good old poke at the 101 today to assess the state of the engine and fuel system. I have to say it is extremely impressive how well this old piece of vehicular hardware has stood up to 10 years of neglect.

101 cabin with engine cowling in place

101 cabin without engine cowling

For those of you not familiar with the 'architecture' of a 101, the engine is essentially between the front seats (the 101 is known as a Forward Control vehicle, though not sure why as I've never come across a Backward Control vehicle??). The photos show the cabin with and without the engine cover. As you can see the gear lever sits on top of the engine (that's the radiator and fan cowling under the stick). This makes for a warm cabin on a long drive but is handy for working on the engine when it's raining(which happens a lot where I live in Scotland!)

101 engine from the top (original V8)

Oil not looking too bad

An initial poke at the engine reveals its in remarkably good condition for 10 years of neglect. No hoses appear worn or decaying. The water level in the radiator is non-existent but upon refilling it a small amount there are no obvious leaks. A check of the oil level shows it low but the oil is clear and no milkiness (so no water!)

101 fuel sedimentor

My major concern is the state of the fuel. I don't currently have an appropriate container to drain the fuel into, but I have had a look at the fuel sedimentor (sic) at the back of the engine bay. The fuel is clear but I think there is a varnishy skin. Need to remove and investigate but can't release it currently (waiting for WD40 to do its magic).

101 battery tray and air filter bays (air filter top left)

Pulled the air filter and checked the battery tray. This particular 101 takes two batteries - one for the ignition system and another for the auxiliary systems (there's an air compressor and a separate heater system, I think). I have previously marked up which is which thankfully. Saves a lot of time! Air filter is nice and clean (and about the size of an oxygen cylinder)

Everything looking pretty good. Something has to go wrong?

Despite owning a complete set of Land Rover 101 manuals (user guide and the repair manual) none of them specify the grade of oils or fluids to use in the vehicle. I presume this is due to it being from the 70's and essentially you put in 'some oil', 'some coolant' , etc. Thankfully, I found this useful page where 101Sean listed the specs - thanks Sean! In case it disappears, for posterity Sean says:

Engine 20W50 (now called 'classic motor oil' !)
Axles, swivels and steering box EP90.
Clutch and brakes ordinary DOT4 fluid.
Coolant 50/50 mix of good quality anti freeze and water. Good idea to use filtered rainwater or distilled water (getting loads of tumble dryer condensate at mo given current weather!!) if you live in a hardwater area.

So I also have a small list of fluids and bits to acquire to move to the next stage.

Thumbless Guitar Playing

2010-07-24T03:11:00.000-07:00

As some of you may know I cut my thumb off with a table saw 5 years ago. It got reattached but it has made playing the guitar impossible as I can't get enough leverage on the neck to hold the strings on the frets down sufficiently. If any of you ever heard me play a guitar you might consider this a sign of there being a divine being in action within our current universe.

Regardless to the will of the universe, I went looking for a solution to my problem and discovered the Yamaha EZ-AG - a guitar synthesizer which was actually designed to teach people how to play the guitar. It's about the size of a small-body guitar. The frets have push buttons and the right-hand strings are about 6 inches long. There is a built in synthesizer which plays through a speaker situated under the string portion.

Its the illegitimate offspring from a drunken night between a Guitar Hero controller and a Midi Synthesizer.

I can hear my guitar playing friends like Paul Dyson and Dave Harvey throwing up on their keyboards as they read this.

Again, irregardless of the nausea it may induce, I purchased one at an aggressive price off ebay, and I have to say I'm delighted! I can actually play this thing and it doesn't sound half bad.

Its a little weird to play initially as the strings have a huge amount of movement and seem very loose - and of course there is no feedback between the plucking on the right hand and your fingers on the fret. Also, to 'still' the strings you have to touch the silver plate on the bridge (whilst ensuring you're in contact with the plate on the back of the neck). This stills all the strings at once, or rather the tone generator generating the string sounds, which is a little inconvenient at times. I believe there is a different version (only US?) which is the EZ-EG (electric) which allows individual string control but it's not that important to me.

There are various demos and teaching modes on-board. The frets light up to show you where to hold and there is the ability to do strumming or chord practice separately. Quite cute and I can see why it would at least get someone started but its not like a real guitar. And the frets lighting up can be a but annoying when you're playing it normally - doesn't seem to be a way to switch it off!

The acoustic guitar voice is quite effective through the built-in speaker and I quite like the grand piano voice too (but you need to adopt a different playing style to use it effectively) but all the other tones are a bit tinny and 'fake' to me. The good news is I can use it as a Midi controller so I should be able to hook it up to my Korg X5D and use its more capable synthesis. I say should because I have failed to achieve this so far. I cannot make it work. Clearly, I am masquerading as a technologist. I've even RTFM'd after I tracked down the FMs - but to no avail. Midi IN, Midi OUT, Midi SHAKEITALLABOUT. Argh.

Restarting a 101

2010-07-23T10:39:00.000-07:00

So amongst the many unfinished or neglected things lying around my house is an old Land Rover 101 ambulance that I used to off-road in about 10 years ago. I broke my ankle playing table tennis in Italy (that's a different story...) which made it impossible for me to drive it for a couple of years and I never got back to it...

It's a fantastic machine. High ground clearance, 3500cc V8, permanent four-wheel drive, blah, blah. I could wax lyrical about it for hours. So as I have the time (and my brother is coming up next week = free grease monkey) I thought I would try and restart it.

OK - so you should know I've never tried to restart an old vehicle before. I do have an engineering education and understand how it is all supposed to work - but that's not the same thing as making it work.

Being a good Internet user I of course took recourse to Google for help - typing in "restart land rover 101" I find the second link is to a video of someone crashing their 101 on Salisbury Plain. I'm not really surprised, though, given he painted flames on the side in some kind of premonition. While this is a good illustration of why you don't use your brakes when descending hills off-road, I'm not sure what it has to do with restarting a 101??

Anyhow, after several fruitless explorations (and a relayed conversation with my brother's neighbour, Stan) I have come up with a short-list of actions to restart the 101 - and in an effort to be a good netizen I thought I should record my thoughts/progress/failure(?) in case anyone else out there needs to do the same.

Short list of actions to restart a 101 (or any vehicle really):

drain the fuel tank and refill. The old fuel will probably be varnish by now.
replace fuel filter
check and refill oil in engine. (If the engine restarts I'll flush/refill later)
remove the air filter (not necessary for a restart and could hinder the air flow initially)
hand crank the engine over to check for stuck valves (will probably put some oil/paraffin/diesel in each piston to help ease it initially)
open up and clean distributor and points
replace the battery
check there's a spark for ignition (whole long rigmarole to this - may blog it later...)
drain and fill the carburetters
try starting it on the key!

In a fit of enthusiasm I bought a 101 starting handle off John Craddock's on the principle that it would be far easier to try and turn the engine with this than do it with a socket on the end of the crank shaft from under the 101. It arrived this afternoon - all 4 foot of it! - so I thought I'd see if the engine would turn, wholly anticipating solid lock. But no! The engine moved quite smoothly. This is a good omen!

In The Beginning

2010-07-23T10:14:00.000-07:00

So I find myself at home with lots of time on my hands. My tendency would be to remain incommunicado and I'm not the best at keeping in contact with people. So I thought I would blog whatever nonsense occurs to me, including whatever it is I happen to be fiddling with, in the hope that this may substitute for those ridiculous conversations you may have found yourself having with me in a pub or bar somewhere.

Its not going to be as good (unless you drink heavily whilst reading this) but at least it may stop me turning into the misanthropic hermit my nature demands. Of course, this does require commentary and feedback from you, so please give freely. I will however be moderating as I know you all too well.