Music Explorer FX v1.1: Now with “Fame” Control

Wednesday, November 11th, 2009

Version 1.1 of the JavaFX-based music discovery application, Music Explorer FX has been released. You can try it here:

This version is mostly about performance and stability improvements and it’s also the first version to be released under JavaFX 1.2. Additionally, it sports a new feature: the “Fame” knob:

For those not familiar with how the application works, MEFX will present you with artist recommendations based on an initial artist. Pictured below, for example, is a web of six artist recommendations that sound similar to the  popular alternative metal band, “Breaking Benjamin”.

One potential issue with this kind of search though is that if you are a fan of BB, then you are likely to have already heard of many of these bands. This is where the Fame knob comes in. If you dial down the Fame knob, indicating that you want less famous recommendations, and rerun the search, you’ll now get these results:

These bands are still very similar to “Breaking Benjamin”, they just happen to be less popular. Note that the green “popularity” gauges are considerably lower than the artists on the first search. This can be a great way to explore the long tail of music.

The Fame knob works in the other direction as well. Turn it to the right (positive) and you’re guaranteed to get some mainstream results that even the RIAA would be proud of.

This release also boasts notable performance improvements and some crazy caching techniques.  In particular, I encourage you to check out the much improved image gallery (bring up your favorite artist, and click on the “photos” icon). For a more detailed rundown of MEFX, check out this post.

So whether you’re an old friend of MEFX, or a you stumbled across this post in search of what happened to that popular 80s musical, go ahead and give it a try.

Search is not Discovery

Friday, October 30th, 2009

Paul Lamere over at Music Machinery has a great write-up about Google’s new music search feature. To give you a sense of where he stands, he ends the post with a memorable mantra: “Search is not discovery”.

Search is great if I know that I’m looking specifically for Pearl Jam’s live cover of “Sittin’ on the dock of the bay“. Search becomes less useful if I’m sick of listening to Pearl Jam and want something new — something not Pearl Jam specifically, but something similar…you know, something that I’ll like.

This is where music discovery comes in. Companies like the Echo Nest are trying to make it possible to one day type “find music that I will like” into that ubiquitous search box and get back something meaningful.

On that subject, I’ve been experimenting with a feature for the next version of Music Explorer FX which will lend itself to music discovery “in the large”.

Currently MEFX allows you to explore the artist similarity space very linearly. Generally, once you’ve selected an artist you can go forward, or back, but you can’t easily branch off and return later, or see comparisons between more than a few artists at once.

But what if you could browse a much larger segment of the similarity space, and see connections between 100 artists, instead of just two? What if you could “plot a course” between Pearl Jam and Otis Redding, viewing all the artists along the way?

Below is a concept screen shot (written in JavaFX) illustrating this idea. I hope you like abstract dots!

More details to follow…

The Awkward Relationship Between Swing and JavaFX

Tuesday, October 27th, 2009

Here’s a recent awkward interaction between a Starbucks Barista and me:

Me: I’ll take a Grande Coffee (note, I don’t actually order “just a coffee”, but I’m too embarrassed to write out the actual drink. Being forced to write “Grande” instead of “medium” is embarrassment enough — I already conceded “barista” over “employee”).
Barista: Will that be all for you today?
Me: Yep — and my name’s not “Todd”.
Barista: I’m sorry?
Me: Did you just call me Todd?  My name’s not Todd.
Barista: No…I didn’t. I asked if you wanted anything else.
Me: …Ok, my mistake. (Note: a normal person would let the misunderstanding go at this point — but not me! More awkwardness to follow!)
Barista: That will be $3.50
Me: Today! You said “today”!
Barista: I don’t–
Me: You said “will that be all ‘today’”, and I heard it as “will that be all, Todd“!
Barista: Ok, well–
Me (visibly relieved): Oh man. I sure diffused that awkward situation. What a relief.

Swing and JavaFX currently find themselves locked in a perpetual cycle of awkward exchanges and misunderstandings.

We’ve been told from the beginning that JavaFX is targeted toward media-rich social internet applications and not meant to be a replacement for Swing. We then, however, have to then reconcile that viewpoint with news like SwingX’s funding drying up and the Swing Application Framework missing the JDK 7 train (or “boat” depending on how you feel these things travel).

Feelings of anger, disbelief, and dismissiveness seem to abound in the Swing community. “Why is Sun abandoning Swing? Why are they shoving another language at us?” I admit, as a Swing developer myself, the facts on the ground look bleak for Swing.

It does seem too bad that Swing and JavaFX are in a zero-sum relationship w/r/t allocated resources and active development. It’s hard to deny that many of the high-profile Swing developers are now actively pushing hard on JavaFX.

If we look beyond that, however, I think that there is plenty of room for both technologies in the client-side Java ecosphere.

The Java Platform has always been about choice — and lots of it. Today’s Java developer has a staggering amount of choice in the realm of web frameworks, persistence frameworks, logging, collections, aspects, and dependency injection frameworks. In fact, a Java developer has so much choice, they don’t even have to program in Java if they prefer a different JVM-friendly language.

But in the realm of client-side Java, the choice has been much more limited, mostly due, I imagine, to the fact that client-side Java has never exactly been an exploding marketplace of opportunity.

Web development has always eclipsed client-side work. It’s my hope that JavaFX can seek to change some of that; that it will be able to widen the reach of client-side Java and push development back onto the desktop and remind users that not every application needs to run inside of a web browser.

Sure, it’s possible that some day JavaFX will be the “Swing Killer”, but that would be a sad and unfortunate outcome. It’s my hope that JavaFX and Swing are playing a nonzero-sum game and that the world of client-side Java is big enough for both.

Music Explorer FX Mobile Edition

Tuesday, October 20th, 2009

Earlier in the year, I wrote a music discovery desktop application in JavaFX called Music Explorer FX.  Since JavaFX also has a Mobile SDK, it made sense to write a version of MEFX for JavaFX enabled mobile devices.

Although the idea and basic usage remain the same, MEFX Mobile is not just a port of the larger desktop version, but a completely separate application.

Here’s the initial screen. You can enter an initial artist in the search box as expected, or, since I find entering text on a mobile device extremely difficult, you can hit the “Surprise Me!” button to have the app randomly pick a top rated artist for you.

Once you get your initial artist, you’re presented with the usual “visual profile” complete with image, and the “familiarity” and “hotness” gauges similar to the desktop version.

Selecting the middle button will bring you to the core of the application, which is the “artist similarity” screen.

Here you’ll see a number of artists recommendations as provided by the Echo Nest. The left and right buttons will scroll through the list, and selecting an artist will promote it to the main “artist profile” screen pictured previously.

At any point, selecting the third button will return you to the search screen. Selecting the first button will bring you to a screen where you can browse through your history, which provides an easy way for you to return to a previous selection.

One of the neat things about JavaFX is that (generally) the code that runs on the desktop can run on a mobile device (and vice versa) with little issue. So if you don’t have a JavaFX-enabled phone, don’t despair; you can click on the launch button to run the exact same application as a Java web start desktop app.

For those interested, I wrote the application specifically for the HTC Diamond, which is pictured here running the application.

MEFX Mobile is an open source application and exists as a sample over at JFXtras.org. So feel free to download the source code and play around with it, or even install it on your own phone.

Enjoy!

The Nonzero-Sumness of RIA Platforms

Tuesday, September 8th, 2009

In an industry that seems to thrive on competition, it’s natural to think that the three major RIA platforms are incompatible, directly competing technologies, and that an application that uses one, will preclude the use of the other two. After all, an application written in Silverlight is one less application that could potentially be written in JavaFX.

Right?

This would be true if application development were a Zero-Sum Game, which it sometimes is, but not in the case of RIA development.

RIA platforms are currently the underdogs of adoption when compared to general web application development. When it comes time to choose a technology stack for a new project, it is often assembled based on (among many other things) what is familiar, and what others are using — and these days the default stack is web-based.

On the occasion that the requirements demand something that current web technology can’t easily accommodate, a RIA solution may slip into the mix and cross-pollinate with an existing web app. When this happens, the general awareness, and acceptance of RIA technology rises a bit more, and with it, expectation that future applications will follow suit.

Every project that uses Flex, JavaFX, or Silverlight increases the user’s expectation of how applications should behave and what’s possible. Soon users may come to expect the ability to run an application offline, out of the browser, or on a mobile device, and the higher the user expectation, the higher the demand for this type of development.

Put another way, RIA platforms have the task of not only trying to increase adoption, but also of generating the demand and raising awareness for the technology itself. This is much easier done collectively then as individual platforms.

In other words, RIA Platforms are playing a Nonzero-sum game between each other: that which benefits one, benefits all.

For this reason it is good, from an adoption standpoint, that the three RIA platforms keep pace with each other’s feature set. For example, while Mobile support may be perceived as a differentiator for JavaFX, it’s actually a good thing (and I’m sure not completely non-coincidental) that Flex and Silverlight have Mobile support planned in the near future. The reason is simply that if more applications have mobile components, the expectation, and therefore demand for this style of application, will rise. So if a project ends up using JavaFX Mobile (for example), it is not a net-loss for Flex or Silverlight, as two more mobile RIA projects may appear that would not have otherwise been there based on the demand created by the initial project.

Neal Ford hinted toward a similar trend in dynamic languages in his talk “JRuby vs. Groovy”. Despite the antagonistic title, Neal warned that if developers don’t realize that the ecosystem is big enough for both languages, neither may thrive. In other words, two seemingly competitive technologies are dependent on each other for survival as long as both benefit from the other’s successes.

There may come a time when the RIA space is so saturated that the game may switch to zero-sum, much like the current state of web application development. There may come a time when the phrase “desktop-like experience” actually refers to technology that runs on the desktop.

For now though, the task of mass adoption is far too great a challenge for any one platform. They are better off acknowledging their potential win-win situation of co-adoption.

Creating a Bordered Panel in JavaFX

Saturday, August 22nd, 2009

Recently I was looking for an easy, relatively general way to visually separate arbitrary groups of components with a border. Behold the BorderPanel:

BorderPanel is simply a CustomNode that wraps any number of nodes in a Panel (which is a custom layout Container), and sticks a border around it.

Here would be the code to generate the above layout (assuming that the widgets were contained within the “vbox” object:

BorderPanel {

  borderColor: Color.DARKSLATEGRAY

  borderWidth:10

  layoutPadding: 10

  content: [ vbox ]
}

The above layout is alright, but really I wanted it to put a border around some AnimatedCharts from the previous post:

Since I can put a border around anything now though, separating groups of charts is pretty straight forward:

Which is just two BorderPanels contained in an HBox:

HBox {

content: [

  BorderPanel {

    content: HBox { content: [chart,chart1] }

  },

  BorderPanel {

    content: HBox {content: [chart2] }

  }

 ]

}

BorderPanel itself is pretty small. Here’s the create function:

override public function create():Node {

  panel = Panel {

    content: bind [border, content]

    onLayout: function() {

      for (c in content) {

        c.layoutX = borderWidth + layoutPadding;

        c.layoutY = borderWidth + layoutPadding;

      }

      updateBorder();

    }

  }

}

It simply creates the wrapper panel, “prepending” the border to the user added content (so that it always appears behind the components). The “onLayout” function is defined to move the “layoutX/Y” of each component out of the way of the border, plus some user-defined padding.

Here’s the function which creates the border, which is called whenever any of the dependent variables are updated.

function updateBorder() {
  var width = panel.width + borderWidth * 2 + layoutPadding * 2;
  var height = panel.height + borderWidth * 2 + layoutPadding * 2;
  var rect = Rectangle {
    width: width
    height: height
  }
  var innerRect = Rectangle {
    width: width - borderWidth * 2
    height: height - borderWidth * 2
    x: borderWidth
    y: borderWidth
    arcWidth: 30
    arcHeight: 30
  }

  border = ShapeSubtract {
    fill: borderColor
    a: rect
    b: innerRect
    effect: DropShadow {}
  }
}

The border itself is a shape subtraction of a rounded rectangle from a larger rectangle which encompasses the size of the entire panel. There is also a drop shadow added to give a subtle sense of depth.

The idea of creating a border that looks like this was actually inspired by this year’s Extreme GUI Makeover at JavaOne, which featured an Email client written partly in JavaFX.

An Animated Chart in JavaFX

Tuesday, August 18th, 2009

For an upcoming demo I had some data in chart format, which would be changing frequently, so I wanted the charts to smoothly animate the value transitions rather than abruptly change to the new dataset.

The built-in charts in JavaFX 1.2 are great in their variety and configuration options, but they seem to be less forgiving when it comes to trying to animate their components. I attached a Timeline to modify the data values of the chart and my framerate quickly dropped followed by an OutOfMemory Exception. Clearly not meant to be. (Incidentally, if anyone knows how to make this work, please let me know).

Since I had my heart set on animated visuals, and since my configuration needs were meager (I didn’t even require labels), I decided to write my own small Animated Pie Chart. Click the “Launch” button below the image to try it out.

Clicking on either “Dataset” button will simulate different data populating the chart. Note that the chart wedges “wind up” to their target values. Pressing the “Indeterminate” button will “unwind” the current dataset and put the chart in a “waiting” state, which is visually indicated by having the chart pulsate. Click any of the “dataset” buttons to bring it out of “indeterminate” mode.

A potential use case here would be if the chart were displaying some data (say from a web service call), which at some point becomes stale and invalid. Rather than continue to display the stale data until the new data arrives, the chart can be placed in “indeterminate” mode while it waits for the web service call to return.

The chart’s wedges respond to mouse clicks just like the built-in charts. In fact, for maximal compatibility, this AnimatedChart simply takes PieChart.Data objects as values. Here’s what the code looks like to generate the above chart:

AnimatedPieChart {
 data: [
   PieChart.Data {value:10, action: function() {println("10")}}
   PieChart.Data {value:20, action: function() {println("20")}}
   PieChart.Data {value:5, action: function() {println("5")}}
   PieChart.Data {value:10, action: function() {println("10")}}
   PieChart.Data {value:30, action: function() {println("30")}}

  ]
  width: 300
  height: 300
  title: "Top Pie Wedges by Color"
}

Update: The source code for this example (as a Netbeans project) is available here. Thanks to those who had interest in it.

Music Explorer FX Source Code Available

Saturday, August 8th, 2009

Music Explorer FX has been open sourced and is available for download on the JFXtras community site (it’s about halfway down the page).  Thanks to Stephen Chin for encouraging me to release it under open source.

The netbeans project is included, so hopefully building it will be as straight-forward as opening the project. In order to run the application, you’ll need to get developer API keys from the Echo Nest, Flickr, and Last.fm (all free) and put them in src/api_keys.properties. The readme contains more detailed information.

The codebase was written in JavaFX 1.1, but I did update it to 1.2 so that it will work with the latest (at the time of this writing) release.

The code itself suffers from the proof-of-concept that turned into a prototype that grew into an application, while the author was learning a new language. Now that I’ve actually read a book on JavaFX, I can think of many things that I would have done differently.

In fact, as I write this, the current top post on dzone is a “you might be a bad programmer if…” type of post which seems to surface every few months, and reads like a check list for this application.

Rather than keep making excuses for poor code quality though, I’ll just cite the mantra that Jim Weaver aptly associated with the JFXtras community site back when it first launched: Working code trumps all theories.

Enjoy.

Book Review: Pro JavaFX Platform

Tuesday, August 4th, 2009

Early adopters of new technology platforms seem to have a masochistic side in that they must put up with the pain of unimplemented features, poor or non-existent documentation, and incomplete APIs. Their reward for all of this hard effort and needless suffering once a new version of the platform is released is often hopelessly broken code and a relearning/unlearning of all that has changed.

JavaFX certainly played the role of dominatrix in my life for the past year. What started out as an interpreted language, moved to exclusively compiled and had keywords phase in and out of favor (I still type “attribute” in my weaker moments).

Through the seas of change though, Jim Weaver and his blog have helped to keep me afloat. So it makes sense that Jim, along with other vocal JavaFX community members in Weiqi Gao, Stephen Chin, and Dean Iverson, would be the ones to write the definitive guide to JavaFX (which would have been the perfect title, but it’s actually called “Pro JavaFX Platform, etc.” instead).

“Pro JavaFX” is a very well-written, detail-oriented, yet approachable read. While learning JavaFX over the past year, mostly from blogs, hearsay, and copious amounts of trial and error, I had a functional, yet “swiss-cheese” understanding of the language. I was effectively a Java programmer writing JavaFX code — but I wasn’t writing idiomatic JavaFX. I wasn’t a JavaFX programmer.

PJP answered nearly all of my questions by not only explaining language features and corner cases, but also usually the rationale and implications behind them as well. It made it easy to get excited about the language itself all over again.

For example, take this small code fragment taken from Chapter 7 which will return the number of cells for a given player in a Reversi game (but I don’t need to tell you that, because I think the code does a better job):

public bound function getScore(owner:Owner):Integer {
  def cells = for (row in board, cell in row.cells where cell == owner) {
    cell
  }

  return cells.size();
}

There’s a lot going on here that I like (but not necessarily news): the bound function makes for easy updating of state, and constructing a sequence from a “for” loop almost feels like cheating it’s so concise (I think that “return” is optional though).

What’s really great though, is JavaFX’s “nested” for loops. I find “for (row in board, coll in row.cells where cell == owner)” not only concise, but about as clear as if it were written out in English. “Pro JavaFX” is littered with these “idiomatic pearls of wisdom” that helped me realize how Java-centric my JavaFX code was.

The book is a good survey of JavaFX as it exists today (version 1.2). In addition to the language proper, it covers many of the third party libraries (JFXTras, et al.), has a chapter on building a professional RIA book store front type app, and finishes with a solid chapter on JavaFX Mobile.

While readable cover-to-cover, I’ve found it more valuable as a reference to pick and choose from as needed. For example, today I finally read up on mixins and the different forms of triggers.

I highly recommend this book to anyone interested in JavaFX. It will likely stay on my desk for some time to come.

The Evolution of Music Explorer FX

Friday, July 31st, 2009

In the process of getting Music Explorer FX ready to be open sourced (which hopefully will happen any day now), I couldn’t help but take a trip down memory lane with some of the early iterations, which I thought I’d share here.

For reference, this is a screen shot of the current state of the Music Explorer (you can click on any of the images below for a larger view):

Here’s the initial prototype created almost eight months ago:

All of the data was canned at this point. Note how small the images are in order to accommodate eight artists (instead of six). The big, bulky, blue borders have some subtle gradients which caused performance issues even when cached. Bummer.

This was one of the initial search screens. Note the main logo looks quite different. Also, I didn’t have custom icons at this point as all of the buttons just have text labels.

This is what the search results used to look like. I was too in love with gradients. I still am, really.

In this version, the data is now live. The audio player is fixed to the bottom left corner and is there regardless of if there is audio or not. The audio player is actually built around Josh Marinacci’s sample MediaComponent at this point in the evolution. Note the artists still clearly don’t fit right on the screen. Also, I still won’t let the idea of gradients die.

Here things fit much better as I’ve finally settled on six instead of eight artists. The audio player is moved underneath the current artist and I have my first set of gigantic custom icons for switching between modes. Also, my love of gradients reached new heights (or new lows depending on your aesthetic sense) with the inclusion of the background.

My friends finally have an intervention on my behalf. Gradients gone ;(

I received a lot of great feedback during the development of MEFX.  A reoccurring criticism was that the application was too dark. The above screen shot proves that I am either passive aggressive, or have no artist sense (probably both).

MEFX is almost to the state that it’s in today. The icons have tightened up. Some great advice I received was to “let the artist images define the color”, which I attempted to do by removing the color from the borders and adopting a more muted color scheme.

Finally, again, for reference, here is what MEFX looks like today:

The buttons are smaller still, and look more like tabs that appear to just “tuck underneath” the current artist. The audio player only appears if there is music to play and appears to be part of the artist’s node.

While I was writing this, Ben Galbraith’s excellent talk on Craftsmanship came to mind. In it he talks about (among other things) the value of polishing something over and over and over.

While I’m not sure that I can claim Craftsmanship in the Music Explorer, I can certainly relate to the value of doing something again and again and again.

The process of polishing was often extremely painful. I would agonize over how to incorporate the feedback I’d received, often to the point of wanting to chuck out the whole thing. I would stare at the application, knowing that it wasn’t quite right, but at a loss for how to make it better.

Then, eventually, through sheer stubborn persistence, I’d get some sort of glimpse of an idea of something different — and a few experiments later,  I couldn’t imagine it ever looking different from the new way.

Well that’s it. Thanks for checking this out.

Welcome to the blog of:

Sten Anderson