On Friday evening while mulling over potentially interesting hacks to build at Open Hack London I remembered an idea I’d had a while ago: there are now loads of interesting ways to use iphones as music interfaces and the iphone to hacker ratio at hack days tends to be around 1, so you could probably put together an entire iPhone orchestra.

With only a few hours left before heading to London I started rummaging around on the internet to find the bits I needed. I’d looked at the various iPhone music interface apps over Christmas and ITM MidiLab had been the easiest to use, but although I could start up multiple iTouchMidi servers listening on different ports, I couldn’t send the output of the servers to different MIDI ports, making it impossible to distinguish between multiple iPhones.

Next I looked at the OSC based iPhone apps: OSCemote, TouchOSC and mrmr. Of these, mrmr was the easy choice as it is free as in beer and speech, allowing me to extend it if needed. It also allows custom interface design via scripting allowing for potentially interesting UI hacking at open hack. OSC is also an open standard, so as a last resort I’d be able to build a server that could listen to multiple devices.

With the client settled on I started looking at existing software to run on my laptop to convert OSC data in to MIDI to control Ableton. The first thing I looked at was pd, an incredibly powerful data processing environment that can understand OSC and generate MIDI. As well as being incredibly powerful, pd also has an incredibly steep learning curve and time was running out, so despite having used it in the past and wanting to use open source software for my hack, I eventually gave up on pd and tried OSCulator.

OSCulator is incredibly easy to use. Within minutes I had multiple OSC servers listening on different ports, my iPhone had connected to each of them and I’d set up mappings from dozens of OSC inputs to MIDI controllers. OSCulator also supports up to 8 Wiimotes connected via bluetooth, so I chucked a couple of wiimotes my bag, tested the iPhone could connect to an Ad Hoc WiFi network created on my MacBook Pro, threw a Dr Who MIDI file in to Ableton and then got some sleep.

After booking a slot for the non-existant iPhone orchestra during the hack demos, I set out to make it exist. With a combination of arm twisting and volunteering I convinced 8 plucky hackers to join the orchestra then spent a few hours auditioning synth patches in Ableton and assiging MIDI controllers to their parameters and tweaking iPhone accelerometer smoothing settings in OSCulator to get a couple of Wiimotes working as drums.

I managed to organise an hour’s rehearsal on Saturday afternoon where we spent the first half trying to connect all of the devices and the second huddled around the laptop trying to hear the audio from the built in speakers. After a bit more tweaking I set up a 3rd Wiimote to launch loops and start and stop the set, allowing me to get in on the fun while conducting and borrowed an amp for our second and final rehearsal.

The performance was a hoot. We’d been having trouble getting all of the devices to connect to OSCulator at the same time and Simon Willison’s iPhone refused to connect for the final performance, which freed him up to concentrate on hamming it up with a look of intense concentration. I also managed to completely lose track of where we were in the music, so Jon Markwell’s haunting theremin solo section ended up following an embarrasing silence when his part wasn’t actually playing. All in all though, I think we did pretty well and it went down a storm with the assembled geeks.

Many thanks to Ryan Alexander, Jonathan Markwell, Natalie Downe, Nigel Crawley, Matt Jarvis, Simon Willison and Matthew Smith for indulging me once again at hack day — it was loads of fun. There are more videos and photos of the performance in my delicious stream.

It was incredibly satisfying to be able to go back to Lang.NET 3 years on to be able to say that we actually managed to make all the crazy plans we had for Mono in 2006 work. My talk is now online here. Lots of people hadn’t seen the 2006 talk and were blown away with us adding support for continuations on the CLR and enough new stuff to keep those that had seen the first talk interested. In particular the anecdote about flywheel exploits for the Mono scheduler got a laugh from Anders Hejlsberg.

The other highlights on Tuesday were Mads Torgeson’s talk, which gave some nice insights in to the process that led up to the final C# 4.0 Dynamic design. Mads did a good job capturing some of the concerns that static advocates have with dynamic languages. Gilad Bracha’s talk on Newspeak and the Hopscotch IDE showed what’s possible with a really dynamic language: extending the IDE and debugging it from inside itself. The access that newspeak has to it’s call stack was particularly interesting: it would be much easier to move a newspeak stack around than build the infrastructure we needed to move a CLI stack. I spoke to Gilad about his experiences building newspeak on Sqeak afterwards. His impression is that Squeak is runtime mostly used for education and has no support for security or running untrusted code. Having spent a decade seeing the various security problems with bytecode verification in Java, Gilad isn’t convinced that a bytecode level sandbox is the right approach, but although he has some ideas for object capability based security for the post squeak Newspeak implementation it seems a long way off.

The highlight on Wednesday was definitely Lars Bak’s talk on V8, which I had missed last year at JAOO. The mechanism for discovering emergent types in dynamic languages to allow indexed lookup instead of hash table lookup is a very nice hack. Lar’s super competitive heckling of everyone at Microsoft for the rest of the day was also fun. Other highlights included Erik Meijer throwing coins around while talking about mathematical duality and Amanda Lauter and Luke Hoban talking about F#. Potentially relevant to Linden Lab if we get to the point where we can support debugging scripts in Second Life was Herman Venter’s talk on the Common Compiler Infrastructure a newly open sourced library which can allow CLI assembly rewriting while preserving debug information.

The Meta Introduction to Domain Specific Languages was a really good opening for the DevCon, but the talk most relevant to Second Life was Paul Cowan talking about DSLs in the Horn Package Manager. Paul talked about creating DSLs by extending Boo, something that should be possible when we get to the point where Second Life can accept arbitrary CLI assemblies. I got a first Boo script compiling against the Second Life assemblies at the DevCon and have some plans to experiment building a DSL for virtual ecosystems in Second Life over the next few weeks. Supporting C# as a general purpose language and Boo as a meta language for building DSLs in Second Life would be an excellent combination.

A lot of the talks at the DevCon seemed to involve doing terrifying language somersaults to create more natural DSLs that run on the JVM or CLI which then can’t be easily debugged due to the huge chained expressions or nested types that the languages boil down to. There seems to be a large opportunity for disaster here when these DSLs need to be extended or maintained in 10 years time after the original authors have moved on. Although Martin deflected a lot of these questions by saying you can get bad frameworks as easily as bad DSLs, I feel a lot more comfortable unpicking a bad framework or wrapping a library than trying to fix or extend a broken language (maybe several years reimplementing LSL’s quirks did that).

The ultimate promise of DSLs was hinted at by Magnus Christerson’s talk which demoed Intentional’s amazing Domain Workbench. Instead of building DSLs on top of mainstream runtimes, the Domain Workbench models the domain and can then project the model as code or using domain specific projections like interactive circuit diagrams that can be manipulated and debugged interactively. Magnus started his talk saying that we used to have to enter programs on punch cards that evolved in to sequential programs and that we don’t need to do that any more. If the Domain Workbench’s promise is fulfilled it could change the way we develop software forever.

I may not have blogged much recently, but I’ve been hard at work writing new songs about the financial meltdown, the surveilance state, gene therapy cures for hiv, anger and guilt for the new band I’ve put together with Max Williams and Aleks Krotoski: 100 Robots. We’ll be performing the new songs along with rock/dance/electronic versions of Thriller and Re: Your Brains among others to 200 zombies at Dance Of The Dead: a charity zombie prom in London in aid of St Mungos on April 4th. If you’d like to come along, dance, rock, shamble and groan tickets are available here. I’m always happy to dress up as a zombie, throw in playing music and supporting a band called the The Tits Of Death and it’s clear that this is going to be the best gig ever!

Since moving to Brighton 18 months ago I’ve been pretty busy finding my feet, moving house twice, sorting out schools and setting up Linden Lab Brighton, so I haven’t had as much time to make music as I’d have liked. It hasn’t helped that my brother Roo, who collaborated with me on Vanishing Trick has gone from being a medical student to an opthalmologist, so has been pretty busy too.

I’ve still been reading create digital music though, so couldn’t resist buying Luke a copy of Korg DS-10 for his birthday just before Christmas. It’s a great piece of software that reminds me a lot of ReBirth (which is now free!) — the same infectious acid sounds and a fun interface that you can’t resist tweaking. Within hours Luke was coming up with screaming synth noises that would have made the Chemical Brothers proud, so I told him that when he had a track finished we could record it on to the computer, add some more sounds and make a CD.

30 minutes later I had Luke to thank for finally convincing me to unpack my bag of midi and audio cables for the first time since we rolled up in Brighton. While adding bits to Lukes DS-10 and Electroplankton creations, I took the opportunity to finally play around with Ableton Live properly and was completely bowled over. It’s one of those pieces of software that as a software engineer you can’t help admiring. It makes you want to use it and turns the complex process of sequencing and producing music in to joyful fun. I’d been a Cubase user for 10 years, but I’m not going back.

Over Christmas I put together a Live rig that lets me use my ancient Yamaha MFC05 MIDI controller to switch between drum beats, record guitar loops and automatically switch between effects settings without touching the computer. With some tweaking I’m going to get it to do the same for my Nord Modular and switch patches on both the Nord and my POD allowing me to quickly record, compose, arrange and perform music from 5 foot pedals. I’ve also got ITM set up on my iPhone which I’m planning to mount on my guitar giving me a wireless X/Y touchpad that can control any number of Ableton parameters.

I also finally got round to playing around with circuit bending for the first time. Last Christmas Roo got me a reissue Stylophone, which is a fun toy, but whenever I read about circuit bending online I kept thinking it would be fun to try connecting the headphone output of the stylophone to the MP3 input. In the end it only took an hour or so of poking around inside the Stylophone while telling Luke about electronics to find some bend points that turn the mild mannered Stylophone in to a wailing banshee of feedback distortion that’s more Hendrix than Harris. The modded Stylophone is shown below and I’ve added annotations to a picture of the opened up Stylophone on Flickr that shows the points that I connected. If you’d like to hear the evil sounds it makes there are a selection of Creative Commons licensed samples on Freesound, but I advise turning the volume down and using headphones if you give them a listen.

It’s great to be having fun making music again. Thanks Luke and Roo!

When I heard that the theme for the Linden Lab Christmas party was going to be steam punk, I knew I had to go as Babbage Linden. Since 2005 my avatar in Second Life has sported a victorian suit from Neverland and a steam arm, originally from a Steambot avatar which I updated to a more recent design from Marcos Fonzerelli after Joe Linden started washing his face in my sink.

I had a suit that was close enough and a bit of riffling through local shops and ebay got me a waistcoat and cravat that were a pretty good match, but I knew the arm was going to need a lot of construction, even if I went for the first version from the Steambot. After some Googling trying to find out how to construct a conical frustum I remembered the export to world project that had converted Second Life objects to paper craft models. So, after checking that Marcos didn’t mind me exporting his geometry from Second Life, I decided to do that.

Installing OGLE proved to be really easy — just dragging the replacement OpenGL DLL and supplied config to the Second Life directory worked fine, but my first few captured scenes were full of unwanted clutter. In the end I found that using the advanced menu to turn off all render types apart from Basic, Volume and Bump and the UI feature allowed me to capture just the steambot arm placed in front of me in Second Life.

After opening the .obj file captured by OGLE in Blender, exporting it as a DXF and opening it in Pepakura Designer it was clear that the model was far too complicated — the cones and spheres created dozens of faces. Going back in to Second Life I broke the steambot arm in to 1 piece for each cardboard part I expected to make, stripped off all of the spheres, made the finger tips in to boxes instead of cones and then used the Second Life preferences to set the object mesh complexity to minimum, which reduced the number of faces on each cylinder to 6.

With these simplifications made the models looked much more managable when opened in Pepakura Designer, but it was still worth playing with open faces to simplify the parts in to quad strips. With these tweaks made I determined the correct scale. I placed my forearm on a couple of sheets of A4 and then adjusted the scale in Pepakura Designer until the steambot arm covered approximately the same amount of paper, then noted down the scale so I could use it when printing each part.

After printing the parts out on A4, I pinned them to some think double ply corrugated card from some old Dell boxes and then cut out the shapes and assembled them with gaffa tape, PVA and paper fasteners. I replaced the spheres with some polystyrene spheres from a craft shop and replaced the shiny with half a dozen coats of copperchrome spray paint.

I had a load of fun and the finished arm is amazingly sturdy, surviving 6 hours of Christmas party relatively unscathed. Who knows, maybe I’ll get another chance to wear it at an SLCC in the future. A full set of pictures with notes is available here.

The core of m0cxx0r is the creation of an object that records method calls and compares them to expectations. This is done by using C++ placement new to create a VTableDonor object in allocated memory the same size as the object being mocked and then returning the memory as a m0cxx0r::Mock class which inherits from T, the class of the object being mocked.

When methods are called on the mock object instead of invoking the methods in T, the virtual methods in VTableDonor are called instead and are able to record the calls made and compare them to expectations. The problem is that the signature of the original method and the VTableDonor method may not match.

In order to be able to find and compare parameters the VTableDonor methods take a single parameter which they can use as a fix point to find other parameters that may be passed to the call via pointer arithmetic. Luckily the rules for parameter layout are fairly simple, so if you know the address of the first parameter, it’s easy to find the others.

Unfortunately the same isn’t true for return values. Depending on the return type, space for the return value might be pushed on to the stack as a hidden parameter, a pointer to a heap location might be pushed or the caller may expect the return to be saved in a register. The rules for which mechanism is used depends on some combination of the compiler, platform and sometimes which C++ features the return type uses. To make matters worse the this pointer is also pushed as a hidden parameter which can become corrupted when there is a return type mismatch. All of this makes it very difficult to call a VTableDonor virtual method with a void return type in place of a virtual method on T with a non-void return type and have everything work correctly. You can see why people generally use the much simpler C ABI to nail binaries together.

After a lot of research and some trial and error I’ve managed to get m0cxx0r working with virtual methods returning primitive types and non-POD types by value in Visual Studio 2005 on Windows and using g++ 3.3 on Linux. The new code can be found here. I’m still having trouble getting it working on g++ 4.0.1 on Darwin where dyld seems to be noticing my monkeying around, causing the process to exit with a dyldmisaligned_stack_error — hopefully it will be possible to work around.

A potentially better solution is used by mockitopp, a brand new dynamic mock framework for C++ that I found on my travels around the internet today. Where m0cxx0r uses a compiler generated VTableDonor class and then attempts to work around the signature mismatch problems, mockitopp builds the mock vtable at run time which has the advantage that the entries can be made to match the signatures in the class being mocked. It looks to be a promising approach and I’m looking forward to investigating mockitopp further.

It’s that time of year again where people start asking what I’d like for Christmas and I start wondering what they’d like in return. It’s just the sort of problem that should be solved with social software. Over the last few years I’ve had an Amazon wish list which suffices for books, music and software, but doesn’t allow me to add fun things like board games, sensors and lego.

I’ve thought about building a wish list service that worked against any web store a few times and was talking to my old friend Tom about this problem at the weekend when he came to stay with his lovely new daughter Beth. We both agreed that someone must have built it already and so it goes: boxedup provides you with browser buttons that allow you to easily add any product any where on the web to a social wish list service. It also supports the other essential feature — allowing your friends to reserve items in a way that’s visible to them, but invisible to you, so everything stays a surprise until the big day.

I’ve added a boxedup widget to the side bar so you can see what interesting schwag I’ve uncovered from across the web in a wonderland style. While I was at it I added a friendfeed widget so you can see what I’m reading, bookmarking and uploading in a simon willison/boingboing style too.

Now I just need to get everyone I know to set up a boxedup list too and my Christmas shopping will do itself.

I’ve just been at a really interesting cafe scientifique in Brighton where Philip ‘Critical Mass’ Ball talked about using physics to model the behavior of people en mass. When modeling people as particles you can create surprisingly realistic simulations of real behavior in corridors, traffic jams and panics. As fascinating as this is, I only think this I’d useful on situations where there is little historical evidence to rely on and where the cost of change is high. In the case of parks it is much better to ship a park in beta without any paths and then close the park in November to pave the cow paths than it is to model the park up front and hope that your model bears some resemblance to reality. Physics has invented models of reality just as reality has invented methods of measurement that don’t require modeling. Jeremy Keith is Philip Ball’s nemesis, whatever he may say.

In order for m0cxx0r to be useful for writing tests at Linden Lab, it needs to work on all of the platforms that we target with C++ applications, so today I tried building and running m0cxx0r on Windows.

Initially it looked good: m0cxx0r built in the default Visual Studio Debug configuration, but then crashed on construction of Mock objects due to accessing unitialised memory. This was relatively easy to fix, just requiring a call to memset to zero out the memory that would become the m0cxx0r::Mock object.

The next problem was harder to fix. One of the hacks at the core of m0cxx0r is pointing the mock object’s vptr at a donor vtable populated with methods that record calls to the methods. The problem is that the signatures of the original and replacement methods may not match, so multiple parameters may be passed to a method expecting a single parameter. This shouldn’t be a problem as long as the caller manages the stack unwinding: the caller just pushes parameters on to the stack which are ignored and then popped the back off again.

Although m0cxx0r just worked when compiled with GCC on darwin, the run time checks performed in Debug by Visual Studio caught the stack pointer mismatch and stopped execution. In Release the situation was even worse: the tests just crashed out without error. Luckily after some poking around I was able to turn of the stack pointer run time check in Debug and after some trial and error I found that disabling optimisations in the Release configuration with the default __cdecl calling convention allowed the tests to run without error in Release.

With these property changes made, m0cxx0r built and ran it’s tests fine in Visual Studio 2005 on Windows. Get the Visual Studio 2005 project and solution files along with the m0cxx0r code from Google Code.

A few weeks ago at JAOO I felt insanely jealous while watching Erik Doernenburg demo Mockito: I wanted dynamic mock objects in C++. It turns out that it’s really hard. However, after a few days hacking around I found that it’s not completely impossible. The results of my hacking are now available under a BSD license here. m0cxx0r lets you write tests like this in C++:

typedef m0cxx0r::Mock<ProductionClass> MockClass;
MockClass* mock = MockClass::create();
mock->expect("foo", &ProductionClass::foo);
mock->expect("bar", &ProductionClass::bar, 42);
mock->expect("baz", &ProductionClass::baz);
mock->foo();
mock->bar(3);                                                     
mock->verify();
MockClass::destroy(&mock);

Most importantly you don’t need to hand code a test double for ProductionClass: m0cxx0r generates it for you. The code needs lots of love: it’s all in a single file and the interface will need iterating a few times, but I think it’s a good start. Please download it, have a play and let me know what you come up with. I’ve only tested it on gcc version 4.0.1 on darwin, so I’d be interested to know if it works on other platforms as it uses some code layout assumptions that might not be portable. I’ll write some blog posts over the next few days that explain how it all works.