Data Artist

Tag Archives: AIR

I was contacted by Justin Ouellette, the creator of Muxtape, who asked that I remove the download functionality from MuxMaster. I’m torn about this issue, on one hand Muxtape is a service based on technology that makes distributing MP3s extremely easy. Justin has chosen to hide this capability because he’s appropriately scared of the consequences of having Muxtape turn into a file-swapping website. But essentially Muxtape is a massive dropbox for MP3s. On the other hand, I really do like Muxtape, and I don’t really want to be the one partly responsible for getting the site shut down.

Note that this isn’t a decision about legality (not for the legality of MuxMaster anyway) and I wasn’t coerced or threatened or anything like that. Justin just sent me an email saying he liked the app (and is cool with people making apps like this) but that the download feature endangers Muxtape. I agree, although I still don’t know whether I should feel obligated to remove the download feature.

MuxMaster iconOn a lighter note, Juan Sanchez whipped up a little icon for MuxMaster, which is now included in the latest version of the application. Pretty sweet huh? Thanks Juan!

You can still download MuxMaster (Lite) without the download functionality:

MuxMaster is an open-source desktop player to browse, play, and download Muxtape mixes. It is an AIR application that lets you stream music from Muxtape, explore different mixes to find new music, and even download tracks and entire playlists to your computer with a single click.

UPDATE: After being contacted by the creator of Muxtape I have decided that it is in the best interest of the Muxtape service to remove the download functionality from MuxMaster. I was torn about this, but for now the downloading features are removed.

Why did I make this?
I like Muxtape. Like a lot of software/web guys, I saw the clean interface and the barren source code and was immediately impressed. I mean, the dude did a fantastic job. It was just so damn clean.

Then a few days ago people went ga-ga over this video of some dude showing muxtape mixes using the Coverflow visualization to browse through them. OK, so that’s cool, except it uses a Mac-only application called Fluid to basically add normal Mac desktop functionality to web apps. That shit got dugg like 750 times. Now I’m not saying it’s not cool, cause it is. But I figured I could probably whip up a Flex application pretty quickly using the Coverflow component I released before and get a real desktop application that anyone could download and use. Oh, and I thought it would be neat to add downloading functionality too.

So I threw MuxMaster together over the past 3 nights. I like to think of it as a testament to the badassness of Flex and the open-source Flex/Flash community. The fact that I can grab some open source stuff and throw this together in almost no time is pretty cool.

What kind of an application is this?
MuxMaster is an Adobe AIR application, built with Flex. That means it’s a desktop application that can run on Windows, Mac, Linux, whatever. Click the “Install Now” link above to install the app. You might need to go and download the AIR runtime first. Hopefully it’ll tell you that and do everything automagically.

The Muxtape API
Muxtape has no API. But the HTML code is so sleek and beautifully clean. Go look at the source code for the HTML pages on muxtape.com. It’s ridiculous how sparse it is. And of course it validates as valid XML. So what? Well, nice XHTML like that is just as good as the best XML API you can ask for. You want to get a listing of some random Muxtapes? Just load up the XHTML on the Muxtape home page and parse out the list of users. Using E4X you can get a list of users with this single expression: body.div.div.ul.li.a. It’s almost too easy. So then when you get a username you just load that user’s HTML page and you can easily parse the list of songs (body.div.ul.li) or related users (body.div.div.div.ul.li.a). There’s a little trickery involved to figure out exactly how to construct the URLs for the MP3s, but it’s pretty easy to figure out. After a little parsing you can get a list of MP3 URLs and the data about each song, like artist, track title, duration, etc.

Downloading songs

UPDATE: After being contacted by the creator of Muxtape I have decided that it is in the best interest of the Muxtape service to remove the download functionality from MuxMaster. I was torn about this, but for now the downloading features are removed.

The thing about Muxtape is that all the songs are just MP3s stored on Amazon S3. If you know the URL you can download the file. The main Muxtape player doesn’t expose this functionality, but if you take a look at the files that the web-based player is loading you can just copy/paste the URL and load it into a web browser to save the file. So I just made that a bit easier. MuxMaster has a Download link for each song underneath the song name. One click and the song will download in the background (you can specify where you want songs to download to). Additionally, each playlist also has a Download All link, so with a single click you can download all the songs in the playlist.

Is this bad?
There’s a whole ethical dilemma that we can spend forever discussing. Is this application against everything that Muxtape stands for (clean, simple, bare-bones UI)? Is adding download functionality quickening the shutdown of the service? Is this effectively taking a step toward destroying the service that I actually really enjoy using? Yeah, the answer to all those might be yes.

Yes, the excessive use of 3D and especially the over-used Coverflow visualization are exactly opposite to the perfectly clean design concept of Muxtape. The truth is, I hate Coverflow. But people gravitate toward it and seem to love it, so I figured it’d be fun to whip something up and see the response. And it was just so damn easy.

And yes, being able to download an entire mix with a single click may very well be a horrible thing for Muxtape as a whole. I assume the service is already on the radar of the lawyer-crazy music execs, and if it’s not now I assume it will be if it gets big enough. But the technology underneath the service was just so simple (I mean, really? just let people throw a bunch of MP3s up on Amazon S3?) that someone would have shown how to download all those songs soon enough. So I’ll definitely feel bad if this app has a negative effect on Muxtape, but come on, it’s something I whipped up in a few days, someone was bound to do it.

Source code
I’m releasing all the source code for the application. When you install the AIR application you can right click and select “View source” to see all the code. Or you can view the source here. It’s small (16 files, 898 total lines of code). And the code was influenced by the minimalist design of the Muxtap app itself, so I tried to keep things extremely tidy and clean.

I used a few open-source flex libraries. The most obvious one is the Coverflow Flex component that I created and released on my blog. That’s licensed under the MIT license, so you can take that component and add this type of Coverflow visualization to your Flex apps. The Coverflow visualization uses the Papervision 3D library, which is a 3D engine for Flash. It’s badass and free (MIT license). The other Flex library I used is FlexLib, which was used for the FlowBox container. That component can be seen when you download songs. It’s the container that lays out the little download rectangles. FlexLib is also licensed under the MIT license (is there a pattern forming?).

The source code for MuxMaster, like all code released on my blog, is also licensed under the MIT license, which you can read here. Basically you can do whatever you want with the code.

What’s next?
I don’t know if I’m going to do anything more with this application. The app does rely on the format of the HTML pages on Muxtape, so if the creator of Muxtape decides to try to break MuxMaster he probably can, and I’d have to update it to get it to work again. I might do updates like that to keep it working. If people have feature request I’d love to hear them, but I’d encourage other developers to take my source code and add the stuff that they want. If you have feedback shoot me a message using my contact form or leave comments here. I don’t have any big plans, this was fun to make.

Legal nonsense
This application doesn’t contain any music files whatsoever. I am not storing any music files on my server or any server that I am associated with. I am not providing a list of any music files stored anywhere on the Internet. I don’t have any information about how to find music files stored in any database or anywhere in the entire galaxy. If you’re a lawyer looking to scratch that soul-destroying litigious itch that you have, I’m the wrong guy to talk to.

One of the recent projects I have been working on with a team at Universal Mind is the MapMyPix AIR application that allows you to take data from a handheld GPS device and mash that together with pictures from a digital camera and automatically geocode your photos.

What it does
You drop a GPX file (which is what you get from your GPS device) onto the application and it shows your route. Then you drop a bunch of pictures onto the route and it automatically analyzes your pictures and figures out where along the route they were taken. Now you’ve got a geocoded photo set that you can view on the map and upload to Flickr to share. When the photoset is uploaded to Flickr the geocoded data is uploaded as well, so you can view your photos on a map. You can share the uploaded photoset with other people by sending out a link, or you can embed your mapped photos in a blog post or web page.

Who this is for
Primarily this application is for someone who has a handheld GPS device and likes taking pictures on hikes, or ski trips, or other outdoor activities. The application also has broader implications in the business realm where large sets of photos need to be combined with GPS data (scenarios like real estate brokers, insurance investigators, etc come to mind). If you’re a backpacker and you take pictures along a hike and you carry a GPS device, then this app is right up your alley.

If you don’t have a GPS device you can still use the application to geocode and upload your photos. You can manually drag individual photos to set their geo locations. Further enhancements to the application are in the works to make the application more friendly to people without GPS devices, since for this initial release we were really focusing on users who have GPS data.

Why this is cool
There are other ways to geocode your pictures. Flickr allows you to geocode pictures that you’ve already uploaded. But the process involves dragging each individual picture onto a location on the map. When you’ve got a hundred pictures from a hike you took this is painful. Not to mention that you’ve got to upload your photos first from your computer, then do all this manual gecoding one by one after the photos are online. Lame.

With MapMyPix we’ve combined the geocoding and uploading process into a smooth interface. Since this is an AIR app you get all the slick mapping capabilities that you can get with a Flex app. And since it’s a desktop application we allow you to simply drag a whole folder full of hundreds of images straight from your computer onto the map and boom, they get geocoded. Sweet.

Some technical details
The app is a Flex application using the MapQuest AS3 API. Universal Mind made the MapQuest AS3 API (you can read the businessy sounding case study here). I’ve worked with both the ESRI AS3 API and the MapQuest API. Without making any comparisons I will say that the MapQuest API is great to work with. It’s fast, simple, and does everything I’d expect a map API to do (I’m not trying to kiss ass here, it actually is a very solid API).

The core application is a desktop AIR app. However, we also used almost entirely the same code base to create an online viewer application that is used to display photosets once they’ve been uploaded. After a photoset is uploaded we provide a unique URL and embeddable code that uses a Flex application to display the images on a map for sharing. Since the whole thing is a Flex app it took almost no work to spin off the online viewer after we had made the AIR desktop version.

Where we had issues

Time
We had 3 developers. We thought we had 3 weeks. We had a blank canvas (ie we were able to brainstorm and come up with the ideas behind the app from the ground up). Awesome. We brainstormed like mad and came up with far more ideas than we could implement in 3 weeks. So we identified core functionality and then stuff that we hoped to have time for (got a bunch of that in there) and stuff that we would like to see (got some, but most of that is still waiting for the next version). Then after a week of work it turned out that there had been a mistaken assumption about the deadline and we lost 2 days. That’s like 10% of the total time. So that meant that the last week and a half were kind of a mad rush to accomplish as much as possible. I actually enjoyed this a lot, but it was definitely a bit stressful.

AIR suckiness
This was Flex 3 Beta 1 and that meant we had a completely asynchronous SQLLite implementation. That sucked. Lots of time was spent coming up with ways of doing complex database transactions in an asynchronous environment. That wasn’t my job on this project so my life wasn’t too bad, but if you ever meet John Yanarella ask him how much he likes asynchronous SQLLite work. In addition to the DB stuff, I ran into lots of AIR memory issues. Our app dealt with very large images (multi-megabyte photos) and lots of them. We wanted the user to be able to quickly browse between hi-res images. But it turns out that if you load a few hi-res images in an AIR app one after the other the garbage collector decides to go on strike and you hit memory errors and the app crashes. Great. Adding in the localConnection GC hack fixed this.

Timezones! Argh!
So GPS units save their time in UTC time, which is awesome because that means we don’t have to worry about time zones. If we have a date from a GPS we always know what universal time that means. The problem comes when you add in a camera. Cameras typically store images in JPEG format with EXIF data to store metadata. One field in the EXIF data is the data and time the photo was taken. Cool. But what ISN’T stored in the EXIF data is a friggin timezone to let you know the real time. So we have to make some assumptions about the camera timezone. We allow the user to adjust the UTC offset for their camera (which means which timezone the camera is set for) and then the syncing with the GPS can work as it should. If only the stupid EXIF data told us timezone…

I’ve posted a video that shows the progress that I made during the first 12 days of working on TileUI. For about the first 2 weeks I saved a snapshot of the progress I had made (I tried to save a snapshot each day, but I missed a few). The video below is a combined video of each of these, it starts at day 1 and goes through day 12.

I stopped taking daily snapshots (and I stopped making much progress) after the first two weeks because I started working on a contracting gig. I’ve gotten much further with the software now (as the previous AIR demo video shows). But I’m not making the day to day advances like I did the first few days (man, if only I could be unemployed forever).

Here’s a quick breakdown of how things went:

Day 1: Learn Actionscript Physics Engine. By the end of the day I had a decent physics simulation running that allowed me to throw around particles. Prior to this project I had never worked with APE, it’s a solid physics engine (my only complaint is how CPU intensive it is).

Day 2: Learn PaperVision 3D. Combine PaperVision with APE. Prior to this I hadn’t played with PV3D and I figured it was about time I learn. By the end of the day I had figured out the basics of PV3D and managed to map APE particles to 3D tiles in PV3D. Damn, these libraries are good.

Day 3: I got the tiles to display images. And I got the basic selection system working where you can lasso a set of tiles and they get grouped. The group was just a messy group of tiles, but it was a start.

Day 4: Added Flickr support to load tiles straight from Flickr. Added dynamic sizing of tiles.

Day 6: Made grouping tiles put them into 3D stacks. Added double clicking tiles to do something based on the tile content, ie open larger Flickr image. (I don’t remember why I don’t have a day 5 or 8 snapshot)

So what?
I thought this was cool because it shows a) how awesome and fast developing in Flex/AS3 is and b) how badass open source community libraries for Flex are. I was able to grab these open source libraries and within a few days have something pretty sweet to show for it. A big thanks to everyone behind the PaperVision project, and to Alec Cove for the APE engine. You guys make this stuff easy.

At last count I am using 10 different open source libraries in the TileUI project in one way or another.

Here’s a demo video of tileUI Desktop running as an AIR app. The video shows drag and drop of local files into tileUI, drag and drop photos from iPhoto, using motion detection on a webcam to take pictures, extracting contents of a zip archive and removing a subset of tiles from a stack.