I was messing around one day, with the kids, and we were changing the tempo on our home Casio Electronic Piano. It had Moonlight Sonata built into it as a demo song, and we had tried playing it at 255 bpm. Suddenly a completely different song emerged, and I found it really exciting and unexpected. The kids and I listened to it over and over again amazed that the song had been structured in such a way that by increasing the tempo, a hidden song was perceived.

So, a while ago I decided to find a MIDI rendition of Moonlight Sonata and run it through Propellerhead Reason, and produce a couple of MP3s showing the original file, and the faster one. I’ve attached links to those, here. Enjoy.

Moonlight Sonata 95bpm
Moonlight Sonata 255bpm

As near as I can figure, this provides some proof that Beethoven planned his songs by producing a framework that is a song in its own right. Then an embellishment layer was applied to that song to fill in the gaps as the appropriate tempo was applied. I wonder how many other songs follow this pattern?

Please be kind, this is on my home server, and likely won’t stand up to diggs, boing boings, or slashdotting. Mirror first before advertising elsewhere, thanks.

So, I’ve upgraded my phone to Android 2.2 and noticed that my Say Time application stopped working. So I did some research into why. Apparently the old system of MEDIA_BUTTON intent priorities wasn’t good enough for Google and they decided to change it to another, very different, method. Here’s how it works:

• Any Android application can request that it become the current MediaButtonReceiver. This puts that application onto the stack and it becomes the SOLE receiver of media button presses.


• If another application comes along and requests to be the MediaButtonReceiver, the current application is never sent any MEDIA_BUTTON events.

In my application, I had simply set it to be a MEDIA_BUTTON intent receiver with a high priority. And then when I got a press, I would either abort the broadcast (become the sole receiver) or choose not to abort the broadcast (passing it on to any other applications interested in getting MEDIA_BUTTON presses). This allowed my application to cooperate nicely with other applications using that button (on the headset) as input.

Now, my application is no longer able to easily cooperate with other applications. I could start a thread that calls registerMediaButtonReciever() and makes sure my application is always the SOLE receiver, then unregister again to allow the last receiver to get their presses again. When the unregister is called, the previous application that has registered becomes the SOLE receiver once again. But, the fact that I have to have a thread running all the time whether the button is pressed or not means my application will consume battery power, and I don’t like that.

I looked at the source code for the Music application, and it calls registerMediaButtonReceiver() every time a new music track begins playing. This basically steals the MEDIA_BUTTON events from any other application that might want to get them.

I have no idea how I would be able to influence Google to change their API to allow some way of knowing when another application has registered thereby replacing the current media button receiver. I think if I had that type of API, I would be able to avoid having to write a thread to set it all the time.

I’ll be trying the thread approach, and hopefully it solves my problem without becoming a battery drain. If anyone has any other ideas, please let me know. Thanks.

Today I worked on SayTime for a little while and added a Settings menu item so that you can set which trigger(s) you want to use, how long the application will ignore triggers, and whether to pass the button broadcasts on to other applications in the phone or to cancel the broadcasts while the application is sleeping.

If you can think of any more settings you’d like, I’d be happy to try and work them into the application.

Update: Apparently a German fellow thinks my program sucks. Well, at least that’s something.

I’ve created a GitHub page with the SmsTweeter application, and so you can dig into the source code of it, if you like. I’ll be using GitHub as the place where the code for this application is maintained. I expect I won’t have a lot of time to maintain this, but it does work, and it might be useful for someone else.

I will be releasing the application on the Android Market as soon as I give it a bit of polish and make an icon for it.

Enjoy.

Recently, when my wife and I went on a trip to New York, we wanted our son to be able to SMS us without incurring the extra high costs associated with international SMS messages. I looked around for solutions to the problem and found nothing that did what I was looking for. Here’s what I wanted to do:

• I wanted my son to be able to SMS me for free.


• I wanted to be able to know my son had SMSed me, and be able to respond to him for free.

My wife and I both have Android based phones. I have a little bit of skill in trying to write Android applications. Since it is Java, which I’ve got a lot of experience with, I have been able to write small applications that seem to work. I figured I’d be able to leave my wife’s Android phone at home attached to WiFi and make it into a gateway for SMS messages.

I have found that Direct Messages do NOT currently support the new Annotation feature. This is a real problem. Because of this, I don’t believe I can use this feature for my implementation and will have to look at other ways of doing this.

So I set out to design and implement something that would allow SMS messages to be forwarded to somewhere on the internet, and then when responded to on the internet would cause the gateway to send those SMS messages back to the original sender. But what would I use for the ‘internet’ portion of the application? I could have written a small TCP/IP socket server to do this, or, use something that is already on the internet and running 24/7. I chose Twitter as the forwarding service. So the application was starting to look like the following:

• Sending phone sends an SMS to gateway phone.


• Gateway phone recieves SMS message.
• Gateway uses a preconfigured Twitter account (the SMS forwarding account) to Direct Message another Twitter account (the receiving account).


• Recieving Twitter user sends a reply to the Direct Message


• Gateway detects the reply to the direct message.


• Gateway forwards the reply text as an SMS to the original sending phone number.


• Sending phone receives the SMS from the gateway phone.

So, there are a few problems with this that don’t seem to be easy to solve with the current Twitter APIs. First, the gateway must poll for DM replies. Second, the DM messages do not carry any information related to exactly which message is being replied to. This is where Twitter’s new Annotation feature (due to be released soon) may come in handy.

Using Annotations, the original sender of the SMS message could be tagged to the Direct Message. I would hope that the annotation would also be passed on to the DM reply when the user replies to the DM, however it may be up to the twitter client to be able to handle the annotations in this fashion.

If that is the case, it may be necessary to write a specialized twitter client that knows how to handle the annotations, and makes sure the annotation is copied from the original DM and passed to the reply DM so that the gateway knows who the message is intended for (knows the original SMS phone number).

During the Twitter Annotation Hackfest

My first question at the hackfest was whether Twitter Annotations are carried on Direct Messages. The answer was a resounding No. So, I needed to rethink the initial design ideas, and take a step back, coming at it from another angle.

So, Direct Messages wouldn’t help me. How could I do a very similar thing using just Twitter Status messages. Accounts can be marked so that their timelines are private. This is of course optional. No matter, the content of a stream is like a subscription. Why not just post the SMSs coming into the gateway as status updates. Then if we annotate each status update with information about the original SMS phone number, we can direct replies back to the original phone.

The only drawbacks to this are that the replies will now be public unless both user accounts have a private timeline, and the phone number is also available if the SMS forwarding account has a public timeline. The latter can be solved with some encryption of the phone number information.

What does this look like now?

• Phone sends SMS message to the gateway Android phone.


• Gateway Android phone updates a Twitter status for a special SMS account. Applying an annotation referring to the sender phone number
• Any twitter user subscribed to that SMS account’s twitter feed will be notified of the new SMS in their friend stream.


• Any user can reply to the status updates. As long as the reply is valid, the SMS Gateway program will detect them.
• SMS Gateway program polls for replies until 10 minutes of inactivity occurs.
• When a new reply is detected, the original status message is fetched from Twitter, and the annotations are used to determine where the SMS reply needs to be sent.


• SMS Message is sent to the original sender.

In this way, we have established a way for SMS to get into Twitter and be responded to by anyone subscribed to the Gateway’s twitter account. This could allow for a ‘help desk’ like model. But of course the original idea was to provide a way so that international SMS charges could be avoided for people with internet access.

Of course, the application developed at the hackfest will only be useful if Twitter releases their annotation feature as planned, sometime later this year. I’ve had a great time at the hackfest and look forward to seeing the demonstrations.

A small update to the SayTime application to allow it to be run on Android 2.1 based phones. I have recently updated my phone to 2.1, and have been missing the ability to ask what time it is without taking my phone out of my pocket all the time. Other than the update to the new API, nothing else has changed.

I’ve been developing a small Android application for my own personal use for the last few months. The recent release of the paid market applications has recently got me interested in writing code for Android again, so I thought I’d spend the day to simplify the application, and make it available for free.

This application only runs on Android 1.5 right now. See the previous post for the reason why that’s an issue for me.

The application listens for button presses on the headset (media) button, and speaks the time. It also has a small application where you can touch the clock and it will speak the time. That’s all it does. It is currently written to work with either the Text To Speech Extended library, or if you have it installed, the Donut Backport of the Pico TTS (which you can buy on the appstore for $0.99).

When you press the media button, the LED light on the phone will turn green. When you let go of the button, the light will turn violet and you’ll have 30 seconds to press it to control other applications like the music player. SayTime will eat the first button press, and set a 30 second timer. After 30 seconds the violet LED will go off and you will be able to ask for the time again.

Sure, it’s complicated. But it’s better than interrupting your music to hear the time. I’ve been my own beta tester for many commutes. Listening to music, and periodically wondering what time it is, and pressing the button. It works for me. I hope someone else finds it useful.

Most of the people who know me have already heard this story, over and over, until their ears have been bleeding. I’m afraid I’m probably getting quite the reputation as an obsessive compulsive because of it too. That’s really just too bad, folks. Here’s another dose of crazy for you. First I’ll set the stage for those of you who might not know what’s been going on up here in Canada.

Last year, around June, 2009, I was excited to hear that Rogers Wireless, one of the two major wireless carriers in Canada, released the first Android powered phones the HTC Dream and the HTC Magic. My friend Andy, on TMobile in the US had had a G1 (HTC Dream) for nearly a year at that point, so we were already far behind the technology curve as usual. Being Canadian we’re used to this, of course: many of us are still trapping for furs and selling them to the Hudson’s Bay Company. I decided to sell my snowshoes and buy a cellphone contract.

I quickly learned what a joy this little cellphone could be. I began to develop small programs that showed my location on a map, and learned as much as I could about the technology, the operating system, and how even how to compile the operating system from source code and deploy parts of it to my phone. The platform was sufficiently malleable to allow quite a bit of experimentation. People from all over the world began brewing their own Android OS variants, and I tried many of these out on my phone, but I always came back to a distribution called CyanogenMod, produced by Steve Kondik. His Donut based (Android 1.6) distribution was consistently faster than the stock operating system my phone came with, and I learned to make it even faster by employing a 10 MB (on a phone even 10 MB of extra RAM is a noticable improvement) modification to the kernel… stealing RAM from the 3D Graphics processor and giving it back to the operating system (like Robin Hood stealing from the rich… a little). I even started writing an application that would speak the current time through the headphones when the headset button was pressed, so I didn’t have to take my phone out of my pocket while commuting in Canada’s frigid winter weather.

In September of last year, a bug was found and fixed in the Android operating system. The problem was that if you had your GPS enabled on your phone, and you made a 911 call, your phone might lock up. The danger being: you might freeze to death before they could send help. CyanogenMod had the bug fixed and out to the masses within a few days. Updates were quick due to an efficient over-the-net software distribution mechanism called CmUpdater.

Recently my world was shattered by an upgrade that Rogers Wireless decided to force upon its customers. Here’s how they did it: they first cut off all of the HTC Dream and HTC Magic users’ data plans. Never mind that they may have been trying to navigate through the Northern Tundra using Google Maps, or waiting for that email about their profits from selling their beaver pelts. Rogers said ‘No Data For You!’ until every user upgraded their phones using software not even compatible with Windows 7. They did promise one month credit on our Data plans. The upgrade, that was supposed to take 20 minutes, ended up taking me well over two hours to do my wife’s phone and mine. I guess that’s worth a free month on each of our data plans?

After the upgrade, I found that I was no longer able to use CyanogenMod! They had patched all of the holes that allowed those freedoms. They had pretended to fix a 911 bug and had instead turned my lovely phone into an antiquarian communications device. The new world of Android 1.6, and the promises of Android 2.1 are no longer available to me. Rogers had thrown me outside in the cold Canadian winter without my coat on, and left my there to die a lonely death while waiting for my three year contract to run out so that I would then be eligible for an upgrade.

Rogers has told me that they will not supply an upgrade from Android 1.5 to Android 1.6 on the HTC Dream due to a ‘memory limitation’ on this device. Strange that I was able to run Android 1.6 on this device just fine for many months. Rogers has now been telling us that they are willing to upgrade our phones to HTC Magic devices, and that they will be updating the Magic phones to Android 2.1 sometime in the future. There’s two problems with this plan. The first is that I prefer a device with a physical keyboard, which the Dream has and the Magic does not. The second problem with this plan is that while the upgrade to the Magic is free, Rogers will be ‘resetting’ our contracts another 3 years from the date of the swap. Why would I want to be stuck with a smartphone for three years when the current rate of progress on these devices is so high? In three years I’ll have a phone that manufactures beaver pelts from yogurt atoms, and sells the results on eBay without any user interaction whatsoever. Does it really make any sense to lock me into a device for three years?

I guess I shouldn’t have signed a contract with Rogers, should I? So, what should I do about this problem? I’ve decided to be as vocal as I can about it and have contacted Rogers to begin escalating the issue until I am satisfied once again. I figure I have nearly three years. So this weekend I began my small campaign. Here’s a few of my favourite quotes so far:

We are very sorry that we are unable to assist you further with this
matter; and hope you will remain loyal to Rogers to allow us to
provide you with superior customer service down the road.

I love the dismissive tone here. You can be assured that they will hear a great deal from me on this matter.

I’ll leave you with some late breaking news. If you don’t upgrade your phone to the latest firmware, Rogers will keep your data plan cut off. If you upgrade your phone’s radio software but leave CyanogenMod on your phone you will still have your data plan cut off. This reminds me, very much, of the type of warfare that the satellite providers used to do against the various satellite hacking devices out there. It’s just like Rogers is sending out Electronic Counter Measures against people who like to have a newer version of the Android operating system. That, in my opinion, is definitely not a crime.

The only way to get your data plan back is to comply with Rogers and install their Mandatory Upgrade (read downgrade). I have to be clear, I have complied with the upgrade orders, and my data plan is working fine. They have even stopped sending me several text messages and phoning my cellphone twice a day. So that’s good. They’re no longer harassing me. However now my phone is as useless as a skipping stone for killing beavers with.

I will be writing emails to the office of the president, and the office of the ombudsman starting tomorrow. Next I will be phoning them. I must have developed a form of OCD late in life. Or it has quietly been simmering for a long time. Either way, I’m not going to sit idly by and watch while Canadians everywhere are being frozen. We deserve better customer service than this!

UPDATE:

Rogers told me to contact HTC tech support. HTC has said they can’t do anything without the express permission of Rogers. I have just got off the phone with Rogers tech support and have been told that there is a waiver form that can be signed by users who do not wish to upgrade their phones to the latest Rogers Mandatory User Update. This doesn’t help me, but it may allow HTC to provide me with a fix to solve the issue I have with not being able to flash my firmware any more. I will continue to pursue that angle of it. Thanks to Ian M. at Rogers tech support for being so helpful.

ANOTHER UPDATE:

HTC has flat out told me they will not be producing any more software for the HTC Dream. I guess they’ve moved on now that their new products are coming out with Android 2.1 on them. Oh well, I guess it’s back to learning to re-love the Android 1.5 again. I doubt very much that Rogers will find a way to help me with these issues either. I guess I’ll just have to hope for another local root exploit in the Linux kernel this version of the phone is released with.

YET ANOTHER UPDATE:

Absolutely no response from HTC so far. My wife’s HTC Dream has been malfunctioning since the RUU update, so she phoned Rogers to get a replacement. I got onto the call and talked the CSR into replacing my Dream with an HTC Magic. My friend Denis has one and seemed quite happy with it. Rogers has committed to upgrading it to Android 2.1 which is really all I want in the end. So I’ll wait for it to be delivered, and hopefully Rogers will stick to their promises in the future. I wonder if the phrase ‘I dearly hope this call is being recorded because I really want your management to hear how truly terrible my customer satisfaction experience has been.’ helped with getting the Magic well after any replacement plan was over. Rogers, I’m still watching you, but you’re not in my bad books anymore. Keep it up. Please, listen to those of us who want to help with Android Open Source development and build in a way to allow us to do so without becoming criminals in the process. Thanks.

I am also not the only one out there who’s upset. Here’s a link to a blog posting collecting the works of all of us ‘complainers’. I feel much better knowing I’m not the only one in Canada with these feelings.

Yes, it has been quite a while since I wrote an entry, dear diary. It is not that you have offended me, or that you have forsaken me, or even ignored me. My life, of which you are blissfully unaware, has been quite busy of late. Yes, quite busy.

First, I left my old job working on computer-vision related software for automated security camera surveillance. I had worked on that software for the bulk of five years. It seems like quite a long time to be working on the same thing, at least for me. I suppose many other people spend 10, 15, even 25 years or more at the same job. I’m afraid that would drive me completely cuckoo. I took a job at a small Calgary firm specializing in enabling medical imaging applications to be distributed to less powerful computers, even over the web. It seems a very promising business to be in, and I look forward to helping out as much as I can.

I’ve been writing most of the software I’ve needed to write using Microsoft Silverlight 3. These medical imaging applications really work well over Silverlight. Much faster than the old Flash applications that they were written in. Though, I really wish we had a graphic designer familiar with Silverlight on the team. I find it really hard to stand in both the designer and the developer camps. I’ve been doing some evaluation of Silverlight 4, and I am really happy that it is going to mean very few changes to our existing code base.

So, sometime along the way, Bonnie and I decided it was time to look into selling our house and moving into another, larger, one. We found a house we liked, and we had to sell our old house in order to make an acceptable offer on this house. We did that in 4 days on the market. We were able to get a very good price for our old house, and so we were able to afford to move into a house that is in a more interesting neighborhood, closer to malls, restaurants, libraries, pools, and so on. I can walk to the train (or take a bus in 5 minutes if it’s cold). And my commute has gone from 3 hours per day down to a little under 2. It seems like a lot, but really it’s not so bad, I don’t have to do very much so I get a lot of music listening and reading done.

Bonnie and I were scheduled to go on a vacation after we sold our house, but Aedan and I both came down with H1N1 and we had to cancel the trip. We’ll go sometime in the spring instead. I think it’ll work out a lot better that way.

All of this happened between September 15th and the start of December. And so, now, it’s snowy, cold, and nearly Christmas again. Time for work Christmas parties, and lots of squeaky boots on ice and snow.

So, my wife didn’t like seeing a picture of me, sick in bed and all ugly, on the blog every morning when she logged in, so I’ve nuked that post. You’re welcome.