Floppy drive music

12 January 2015

Some time in 2013 I set up a rig to play music with a set of floppy drives. At linux.conf.au 2015 in Auckland I gave a brief lightning talk about this, and here is a set of photos and some demo music to accompany.

The hardware consists of six 3.5″ floppy drives connected to a LeoStick (Arduino) via custom vero board that connects the direction and step pins (18 and 20, respectively) as well as permanently grounding the select pin A (14).

The LeoStick is then connected via USB to a laptop, where the Moppy software (not written by me) is loaded onto the LeoStick and its companion Java software is run on the laptop.

The Moppy software expects MIDI format music as input. For me, I use Rosegarden to create and edit the MIDI files.

Music must be specially arranged for use with the floppies. Floppy drives have a useful range of only one octave, and notes must typically be shortened to be distinguished. As a general rule, halve the length of the note that would otherwise be played. In some cases if a particular part is not loud enough, I double it with a second floppy drive (usually playing an octave above/below rather than in unison, as balance issues are usually fundamental to the particular octave).

Each MIDI channel means a separate floppy drive. In Rosegarden, even though it is possible to play multiple notes simultaneously on a single MIDI channel, this is not supported by Moppy. MIDI channels must be numbered sequentially (this is a drop-down option in Rosegarden) unless my patch is used.

It is possible to arrange music by starting with a ready-made MIDI file obtained from public domain sources such as Mutopia Project or IMSLP. In this case it is vital to reorchestrate the music.

Rosegarden’s “Split by pitch” feature makes it much more efficient to transcribe piano music (or music that contains multiple parts in one MIDI channel) by allowing you to separate the top-most or bottom-most notes into separate channels. Rinse and repeat until you have filled all your floppy MIDI channels.

Read more…

One week with the Nexus 5

18 November 2014

My ageing Motorola Milestone finally received a kick to the bucket last week when my shiny new Nexus 5 phone arrived.

Though fantastic by 2009 standards, the Milestone could only officially run Android 2.2, and 2.3 with the help of an unofficial CyanogenMod port. Having been end-of-lifed for some time now, and barely being able to render a complex web page without running out of memory, it was time for me to move on.

I was adamant that I would only buy a Nexus phone. Vendors that ship OEM customisations to the Android image are the spawn of the devil, and I wasn’t interested in buying a device that would be abandoned after the next model came out. After all, I’m not a gadget person. This is a big deal for me, and I hope this phone lasts me four years, just like my Milestone did.

Can I just say how fantastic the hardware is. The case is much more aesthetically pleasing than most of the Android phones I’ve had the (dis)pleasure of trying out, the screen is beautiful, and the software keyboard is smooth, accurate, and responsive.

On the screen. I think five inches is the maximum size I can cope with. I must say, being a person with small hands, I am not a large screen person. I can only just reach the opposite X axis with my thumb, and I need to reposition my hand (or use a second hand) to reach the opposite X and Y points. So yes, that’s why I didn’t get a Nexus 6.

On the software, I am thoroughly impressed by Android 4.4. Thoroughly. Google have done just about everything right. Nearly anything bad I have ever said about Android in the past either doesn’t apply to Android 4.4, or only applies to customised OEM builds.

Everything I would have wanted to root my phone to do previously is totally unnecessary.

Out of the box, FLAC audio and IPsec Xauth VPNs (main mode only, not aggressive mode) are supported. Just by installing an app, I can get my strongSwan IKEv2 VPN working.

Interestingly enough, this phone constantly bombards me with security warnings as a result of the fact that I have installed my own certificate authorities. I think this is an interesting development, and is probably a proactive stance against the possibilities that ISPs and/or governments may encourage you to allow them to perform SSL man-in-the-middle attacks on your connection in future for tracking and advertising purposes.

Hopefully warnings appearing on users’ phones worded such as “your network may be monitored” is enough to scare off those who may have such evil intentions.

The phone is amazingly responsive. Not only that, it multitasks with ease, and the user interface is smooth.

One minor criticism is that Google Maps appears to be capped at around 15 frames per second. This is odd, as similar apps such as Google Earth run at a much more pleasing framerate.

It is probably an unfair comparison, as the Nexus 5 is so much higher specced, but overall I am finding the device much faster and more responsive (and therefore I’m more likely to grab it and use it for quick tasks) than my iPhone 4S.

Ever since the release of iOS 7, my iPhone has been frustratingly slow and unstable. Sadly, apps crashing due to low memory conditions are an almost daily occurrence.

It is unclear to me whether this is a deliberate decision by Apple in order to make their later model iPhones look better, but I find it fascinating that I find my Nexus 5 being more pleasurable to use than my iPhone 4S. Something I would not have thought possible a fortnight ago.

I’m so impressed by Android 4.4 that I’m almost dreading the impending 5.0 upgrade in the fear that Google will “do an iOS 7″ — i.e. make the device significantly less useful by making it slower and less stable.

Configuring Windows for stable IPv6 addressing

9 September 2014

By default, Windows will use randomised IPv6 addresses, rather than using stable EUI-64 addresses derived from the MAC address. This is great for privacy, but not so great for servers that need a stable address.

If you run an Exchange mail server, or need to be able to access the server remotely, you will want a stable IPv6 address assigned.

You may think this is possible simply by editing the NIC and setting a manual IPv6 address. Unfortunately this doesn’t work, as if your router has Router Advertisement enabled, you will still acquire a randomised address that will be used as your source address. It is obvious why I don’t need to explain why this is a problem for your Exchange server.

You can tell Windows to ignore Router Advertisements, but this is a bad idea. For example, many routers do not support changing their LAN IPv6 address and enforce EUI-64, making it hard to rely on a hardcoded gateway within the server settings should you ever need your router replaced.

So the criteria we want is:

  • Stable IPv6 address assigned to interface
  • No privacy or randomised addresses
  • Default gateway learned via Router Advertisement

To do this, run the following from an elevated command prompt:

netsh interface ipv6 set privacy state=disabled store=active
netsh interface ipv6 set privacy state=disabled store=persistent
netsh interface ipv6 set global randomizeidentifiers=disabled store=active
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

Why this is not the default on a server operating system is really beyond me. It’s not like anybody pointed DNS records towards a Windows server before.

iPads as in-flight entertainment

11 January 2014

I’m writing this whilst sitting on a Qantas flight from Perth to Sydney, heading home after attending the fantastic linux.conf.au 2014.

The plane is a Boeing 767, and unlike most flights I have been on in the last decade, this one has no in-flight entertainment system built into the backs of seats.

Instead, every passenger is issued with an Apple iPad (located in the back seat pocket), fitted with what appears to be a fairly robust leather jacket emblazoned with the words “SECURITY DEVICE ATTACHED” (presumably to discourage theft).

There are a few observations I have made about this setup.

At first glance, using a portable tablet device to deliver audio/visual entertainment instead of using a more traditional fixed setup seems like a good idea.

For one, the cost reduction for replacing faulty or out of date devices immediately becomes obvious.

And people by and large are reasonably capable these days when it comes to interacting with a tablet touchscreen interface, even if they don’t own one of those devices themselves.

However, I did notice quite a few passengers having issues with the iPads. The cabin crew spent roughly the first 30 minutes after takeoff dealing with support issues, which mainly involved pointing out user interface buttons, assisting with plugging in headphones, or replacing the occasional non-functional iPad with spares they had on-hand.

The iPad assigned to me initially had only 62% charge at the start of the flight, and had no Wi-Fi connection. Safari was the only app allowed, and due to the lack of Wi-Fi, the predefined home page could not load, resulting in an error. Due to the interface lockdown, I could not manually tell it to reconnect. The seat next to me was empty, so I was able to use the iPad assigned to that seat, which worked without a problem.

The fact that there were no charging ports or cables provided, suggests the iPads are charged elsewhere, perhaps off-plane and loaded on prior to boarding.

The entertainment system was delivered entirely through the web browser, which provided TV shows, movies, and some radio content. Unfortunately the system provided no flight information (e.g. location, altitude, or flight path), so I had to rely on spotting landmarks out the window to get a rough idea of where I was.

Because the iPads had an airplane mode symbol with a Wi-Fi indicator, it was obvious that the media was delivered wirelessly. That raises interesting questions about delivering streaming media to hundreds of devices at once. Presumably either they have been careful to distribute a substantial number of access points throughout the aircraft, or they are relying on not too many passengers using up all the bandwidth at once.

Running a site survey on my laptop (iwlist wlan0 scan), I was able to detect 13 access points within range of my seat (53K, just a few rows from the very back), each of them with a hidden SSID. There was a mixture of 2.4 GHz and 5 GHz frequencies in use. Because I did not have airodump-ng installed on my laptop at the time, and not being familiar with wireless sniffing with other methods, I was unable to find out the name of the hidden SSID used.

At this point I was wondering why Qantas have issued iPads, rather than any other non–Apple tablet device. Presumably the lockdown features that Apple provides works well enough for 90% of Qantas’ use case, but I can’t help but wonder whether a customised system, e.g. a custom built Android on a more generic tablet, would provide better lockdown security, and easier management.

I don’t think that a customised Android or other Linux–based system is outside Qantas’ reach, especially given that fixed setups in some of their other planes already appear to sport a similar amount of customisation.

Presumably the decision to deploy iPads was made by executive management, perhaps even being first drafted on a bar napkin, rather than being a technical decision that was made by objectively weighing up the benefits and disadvantages of various systems.

At this stage, I should probably point out that Qantas is a largely brand-oriented company, relying on a strong corporate identity to justify their markedly higher prices. For example, in my dinner serving, I was given brand-name Arnotts crackers, Bega cheese, Dairy Farmers milk, Mount Franklin water, Just Juice, and Coca-Cola. Perhaps given this, it is unsurprising that Apple iPads were chosen.

From a power perspective, given that the iPads run on battery power for the duration of the flight, and the only gear required to be powered by the aircraft are the access points and file serving infrastructure, rather than the fixed entertainment consoles as well, we are probably seeing a reduction on the aircraft’s power strain as a result of this. How significant this is, I am not sure, as I would imagine power is not a particularly scarce resource on an aircraft on the scale of a Boeing 767.

I wonder how much this idea will catch on. Assuming the Wi-Fi based approach continues to perform well, it makes a good retrofit solution for replacing older generation entertainment systems in current aircraft.

Given that what was once a cutting edge premium feature aboard aircraft has now become standard, and demonstrably delivers customer satisfaction whilst being built atop of commodity consumer hardware, I feel we will see more of this in aircraft in years to come.

SPA525G with ASA 9.1.x

28 October 2013

At work, we have a staff member who has a Cisco SPA525G phone at his home that has built-in AnyConnect VPN support.

Over the weekend, I updated our Cisco ASA firewall (which sits in front of our UC500 phone system) from version 8.4.7 to 9.1.3 and the phone broke with the odd error “Failed to obtain WebVPN cookie”.

Turns out the fix was very simple. Just update the firmware on the SPA525G to the latest version. The broken firmware was 7.4.9c, and the firmware I’m using now that works is 7.5.5.

Preferably you’ll update this before updating your ASA (unlike me). If you can’t be bothered navigating the horrible Cisco Configuration Assistant, and have obtained the spa525g-7-5-5-bt.bin file from Cisco.com, just do the following:

workstation$ scp spa525g-7-5-5-bt.bin cisco@uc500:/phones/525/spa525g-7-5-5-bt.bin

! Set up TFTP alias so it finds the firmware at the root
cisco(config)# tftp-server flash:/phones/525/spa525g-7-5-5-bt.bin alias spa525g-7-5-5-bt.bin

! Associate uploaded firmware with phone load config
cisco(config)# telephony-service
cisco(config-telephony)# load 525G spa525g-7-5-5-bt
cisco(config-telephony)# load 525G2 spa525g-7-5-5-bt

! Shouldn't be necessary, but just in cnf-files aren't updated
cisco(config-telephony)# create cnf-files

And there you have it. Oh, and if you’re wondering how to update the firmware once it’s already broken, you can simply log on to the phone’s web interface (obviously only locally, as you’ve already broken the VPN) to update the firmware manually.

Want a take-home message? Update your SPA525G firmware before you update your ASA firewall.

(By the way, I also got an error after the firmware update: “Auth Group setting is invalid”. Turns out I had misspelled the “Tunnel Group” field in the VPN settings. It also turns out that it doesn’t like tunnel group names that contain spaces.)