Update: 04/02/2010 – Thanks to Martin Luder who pointed out that you can in fact do visibility in Eiffel without the inheritance “export” syntax. Updated the example.

I’ve used Eiffel a couple of times. I’ve even blogged about it once. There’s one really cool feature in Eiffel that lives below the whole DbC radar. Peculiarly, the feature itself deals with "features". Basically, Eiffel allows you to decide which classes can see which "features" (in Ruby features are basically methods) on an individual basis. Therefore, Eiffel has no need for a half-baked "public", "protected", "private" solution to the visibility problem because by exporting features you have extreme control over exactly how public, protected or private a feature can be. Here’s what it looks like:

I invited a friend (who doesn’t happen to be very geeky) over to play some Star Wars monopoly (okay, maybe she is) this afternoon because she had recently realized she had the box lying around her house. We opened up the box and started setting up the game. Got the pieces? Check. Got all the money? Check. Properties? Check. Everything seemed to be going smooth until everything was ready and we were ready to roll the dice… the dice!

Now, I don’t play boardgames often, so it’s not like I can just go to my trivial pursuit box and steal them for a bit. The only other games I have in my house were downstairs hidden behind years of legos and children’s toys (legos are not children’s toys). So, like any geek, the first thing I thought was, "Hmm, what are good ways to generate a random number from 1 to 6 without having to get up?". I looked at my mac…

Requirements Phase

Now first it’s important that we list some base requirements for our Dice application. It was very important that we not have to get up, and since the computer was across the room, this limited our input device. The monitor was also far away, so if the output was text-based, it would have to be displayed appropriately large to be seen across the room.

Design & Implementation

Given the requirements, it seemed that the best choice would be to have the output be spoken out loud by the machine. This would avoid any issues with displaying output from far, and Macs have this stuff built in. Now we were able to choose a language best suited for the task. I thought quickly about doing this in Ruby but remembered that this is really something that AppleScript was built for. Interfacing with the speech module is dead easy, and so is our code:

Now we need a way to trigger our dice. Voice recognition also comes built-in on a mac but I couldn’t figure out how to take advantage of it quickly enough so I abandoned that. I tried to think about other input devices that worked from far and settled on the Apple Remote. Now, the remote by default comes with about zero functionality, but I remembered that many people have hacked it up nicely to do pretty much everything under the sun, so I did a little googling and came up with an application called Remote Buddy, which pretty much does just that. Instead of figuring out how to interface specifically with the Script Editor application, I just moved my mouse over the run button (in photo above) and hooked up the play button on the remote to perform a left click:

And there we have it. A dice machine. Keep in mind, this all sounds complex but it pretty much happened in under 5 minutes. I go to great lengths to play monopoly.

Update: February 24th 2008: I did a little more googling today while I had more time and came up with the complete-speech-recognition version of my dice app. Turns out the code isn’t that much more complex. Note that we wrap our code in a try because the SpeechRecognitionServer likes to time out.

repeat while true
	try
		tell application "SpeechRecognitionServer"
			set resp to listen for {"roll", "quit"}
			if resp is "quit" then
				return
			else
				set x to ((((random number) * 5) + 1) as integer)
				set y to ((((random number) * 5) + 1) as integer)
				say "You rolled " & x & ", and " & y & ", the total is, " & (x + y)
			end if
		end tell
	on error errmsg
	end try
end repeat

Now all you need to do is tweak your speech recognition settings to not use the "Esc" key to begin speaking. I also turned off the command prefix:

He has way more on his youtube page.

Enter the keyboard: monome replacement?

It’s almost so obvious that it’s too obvious. We’ve been using these things for decades, and it turns out that they’re exactly that: a 2d grid of buttons. Of course, I can’t take all the credit; somebody already implemented this idea in Max/MSP. Problem was that it wasn’t working with the mlr app for me. Plus, what kind of nerd would I be if I didn’t try to do it myself?

So using a keyboard seems like the best way to emulate a monome. Granted, they don’t give you much LED light feedback action, but I could always just show that up on the screen. It’s not like I stare at my keyboard when I type anyway. Also, there are considerably less buttons than a 256, but I could easily get a good 32 solid buttons to play with.

As far as implementing the monomemulator went, I figured I would attempt to do it on my own, in a language I knew (I like the Max concept, but in the end, programming with a mouse is so tedious). I oddly chose to use the scripting language found in the mIRC chat client. I’ve made some crazy things in this language before, as well as some less crazy things, and in my opinion it was up for the task.

Why mIRC? Why not Max, PD, Ruby, Processing, Python, …?

mIRC scripting is sort of my comfort food when I want to prototype code. There are however two specific reasons that it’s perfect for the job:

1. The mIRC community lacks smart people doing cool things (no offense to the few people doing cool things). This meant that I wouldn’t feel like I was re-inventing the wheel if I was to write an OpenSoundControl library for the language. Chance to contribute original code = extra points.
2. mIRC may be an IRC client, but it actually has a rather extensive windowing library built-in. My entire implementation for the UI was about 12 lines of code. This probably beats out wxWidgets, Fox… Shoes? Maybe I’ll port it some other time. Considering it took 30 minutes including learning how to encode OSC messages, that’s not too bad.

The implementation actually ended up being 120 lines in total with the OSC library (a very simple/incomplete one) built in. You control the monome by simply hitting the keys shown in the above keyboard photo. Feedback for the LEDs are lit up using OSC messages as well. The UI for this emulator can actually expand to any grid size, so if you had a way to actually input 256 keys, you could just change the script up a bit to load it. You could even make it bigger; take that, monome.

alias -l monome_width { return 8 }
alias -l monome_height { return 4 }

The next few lines have options to change the prefix as well. Running the code with /monome gets you this (I’m running mlr in this screenshot as well):

Well. That’s about it. I actually played around with it for a bit and really liked the workflow. I might actually be up for making the plunge sometime soon, though I’ll try and save up for a 256.

If you’re interested in the script files involved you can grab em from here:

osc.mrc: OpenSoundControl library for mIRC

monome.mrc: The mIRC monome emulator

A Quick Comparison of QTrax & Songbird

For those interested, this is a side by side comparison of QTrax vs. Songbird in the application, which still isn’t allowing downloads but it’s easy to see how it will work in both. Let’s get right to the screenshots:

You can see that the only major difference between Songbird and QTrax is that QTrax re-skinned the play controls to give more room at the top for banner ads. Looking further into the app you also notice that they did a similar job with the library screen to make room on the right for ads as well. But with Songbird working perfectly on the same service (so far), there must be something that the QTrax app must do to deal with this, otherwise, why do I need to deal with the ads when I could just, not?

Another advantage to just using Songbird is that Songbird actually works on OS X, Linux, and other platforms. Why the hell doesn’t QTrax?

Oh, and even if they have something up their sleeves, it’s all right there exposed in the app, since they used XUL in order to write their Mozilla-like extensions…

Removing QTrax Ads

The QTrax service isn’t even functional yet and I’ve already managed to remove their ads. That doesn’t say much for this company’s ability to succeed with this ad-based business model. Frankly, if I was an advertiser or record label, I would probably back out of the deal as quick as possible if I saw this.

Like I said in the previous article, QTrax is really just a bunch of Firefox/Songbird extensions plugged into Songbird without any modification to the source (that I’m aware of). I’d love to dig deeper and confirm that the source has not been touched, but that will have to wait. For now, we can easily just dive right into the XUL that they used to right their ad-adding skin and take it right out.

Let me first point out that there are about 500 different ways to disable the ads in this thing. The simplest would be to just remove the extension. I’m only showing one more complex one just to show that even if the extension added something really cool, we could still work around it.

But here we go. Just load up the extension folder in the QTrax program files folder and go to any of the .xul, .js, or .html files and mess around. You can pretty much undo whatever you don’t like and keep what you do.

I’m waiting to see if QTrax actually thought this through somehow on the server-end… but even then, it would be very difficult unless they actually modified the binaries. I can’t tell if QTrax is really dumb in not realizing how easy they made it to subvert their ads, or really sneaky in trying to make an app that will secretly not be a pain in the ass to use, unbeknown to the labels.