Development has been slow on the Home Audio system lately.  Which isn’t to say that it’s not getting used; rather, I’ve been busy doing other things – some technology related, some not – and the system is quite mature at this stage after many years of development.

Nonetheless, ideas pop up every now and then and they’re compelling enough that it’s worth it to dust off the code and Make It Happen(tm).

Such is the case with “universal search”.  Regular followers of this blog will know that the search function is already quite powerful, so much so in fact that you can get lost in the features – and possibly become turned off from search completely if you’re trying to do something simple.

It dawned on me the other day that it would be really nice if I could simply search for a string without having to specify the field to search on.  So for example, I want to search for “lounge”, but I don’t necessarily want to give the system any more information than that.  With “universal search”, the system will search:

• artist
• title
• category
• genres
• year

… for your particular search text.  You enter your text once and the system searches all of these fields.

In hindsight – and from your perspective – this is one of those “well duh!” sort of things.  But again, it’s easy to get caught up in gee-whiz features and completely neglect the stuff that seems obvious.  So pardon moi, but at least the feature is there now <g>

I’ve had a small, but noticeable problem with my home audio interface.

Yes, I’m well aware that I often seem to have small problems just begging for a resolution, but neglected nonetheless for some period of time until… a blog post is finally written.

Anyhow, this particular problem stems from the dynamic tables that are oh-so-cool in giving us super-long tables that are filled dynamically by the backend.  It’s somewhat of a good problem to have, in fact.

Here’s the deal.  You execute a search and you’re staring at your results.  Were you to press F5 now, you’d see the exact same page starting back at you (provided you hadn’t scrolled down at all).  This is the case because a search always refreshes the whole page, or more specifically, requests a new URL in the browser’s address bar.

That’s great and all, but then you decide that you want to sort on a different field.  So you do.  And because the table is dynamic, the sort occurs without refreshing the entire page.  Now, if you were to press F5, you’d be looking at the same search results but the original sort order would be restored.

The truth is that this situation still occurs today, and pretty much occurs in many DHTML apps unless you do some cool work to alleviate it (like I did at work, for a different but similar situation).  However, there’s more to the story.

Now, some links are smart enough to (essentially) ask the table about its condition and then make a request to the server based on the table’s answer.  So for example, if you click a link to add the results to a playlist, then the results will get added with the correct sort order.  And this could be done for every link on the page.

Except… they would have to become javascript links, vs. the straight HREF’s they are now.

Why does this matter?  Well let’s take allmusic.com as an example.  It used to be that some links – particularly those that were presented in list format – were javascript links.  If you attempted to open them in a new tab, well, any number of things could happen.  Recently allmusic made some changes and now many of their links are straight HREF’s, meaning you can open in a new window or new tab or whatever and it works as expected.

In our home audio interface we have the similar, occasional requirement of wanting to open a link in a new tab.  But if the link is a JS link, then you’ve got a problem.

It’s because of this that I decided that I didn’t want to present all of links as JS links.  But I still wanted to be able have the links reflect the state of the main table.

The solution I came up with is creative, though not the prettiest.

Basically, we leave the links as they are.  But, if the table changes for whatever reason, then we go out and explicitely rewrite links to reflect the changes.  This isn’t an ideal solution since it involves some overhead on the client.  But I can’t think of any other way to have regular HREF links which reflect changing properties elsewhere in the page.

So the act of initiating this update is fired by the table’s scroll handler.  I decided that this was the best place to start the update, as the scroll handler has the singular task of determing which rows/tiles are in the viewport and hence need to be brought in from the backend.  Recall that every time you scroll, it’s necessary to make sure that you’re actually looking at something.  This is the job of the scroll handler; he does some calculations, determines what should be there, then starts to calls to put those things “there”.  Since the scroll handler is so integral to the operation of our dynamic tables, I thought he should be the guy who starts the HREF updates.

Now, it’s entirely possible that there are hundreds, even thousands of links on a page at any point in time.  Fortunately, the majority of those links are contained in the scrolling table itself.  It’s on oversimplification, but I can say that those links are already aware of the state the table is in.

That leaves a handful of other links scattered around the interface.  Meaning, the actual process of updating those links is not particularly CPU intensive.  And I even have some nifty “process control” code that makes sure that only one update process can run at a time, and only the most recent one will run.

(fine, I’ll explain how it’s done.  The scroll handler starts the update process as an async process (using a JS timer).  It’s entirely possible that the scroll handler will fire again while the update process is still running – unlikely, but still possible.  So before an update process is started, a random process ID is generated and stored with the table’s other properties.  The update process is then “launched” and is told its process ID.  Once the update process starts to run (and while it’s running) it checks that the table’s record of the update process ID matches the processes own ID.  If there’s a mismatch – which will occur if a newer process is spawned – then the process halts and exits).

Anyhow, the end result is that a few things happen:

• you can move to another page (zones, lists) and return to your browse results and the table will be positioned where you left it
• you can resort your results, move to another page, then return to your browse results and the table will be positioned where you left it

Probably the only things that’s left, then, is to store the selections.  Sometimes you make some selections, but then you want to drill into a record and get more info.  This requires you to abandon your selections, or perhaps open the drill details in a new tab.  It would be nice, perhaps, if you could move around and not worry about your selections, knowing they will be there when you return to the browse results.  This is much harder to do though… I mean, there are ways around it using cookies, but I’m trying to avoid those methods.

(this title brought to courtesy of Beres Hammond, who’s “What One Dance Can Do” bubbled to the front when coming up with names for this post)

I’ve had a recurring problem ladies and gentlemen, in that artist names have been driving me crazy.

Here’s the situation.  An artist is named “artist”, and she publishes albums in this name.  Then the artist decides to change her name to “artois”, and publishes further names under this new name.  And so on and so forth.

The problem, then, is trying to determine which albums belong to a particular artist, regardless of pseudonym.  The problem can even crop up when, say, a gospel artist works with a choir and publishes an album with the choir’s name.  You want to give credit where credit is due, so the album artist field dutifully contains both the primary artist and the contributing choir.  But what happens when the artist publishes a solo album?

I’ve turned this one around in my mind for some time.  It becomes a problem when listing artists, in which case a single artist can be listed 2, 3, even 4 times.  Or when trying to browse an artist’s discography.

Part 1 of the solution was to introduce an “artist alias” field into the backend database, which is intended to contain the most recent pseudonym for that artist.  This isn’t the same as “TLC” vs. “Left Eye”; rather, it’s intended for people like “Puff Daddy”, aka “P. Diddy” aka “Puff Daddy” aka “P. Diddy and the Bad Boy Family”, etc.

OK, so we then had the ability to search on alias.  And the alias field is a calculated field, in that it will return the value of the artist field if the alias is empty.  Groovy.

However there was still the problem of listing and browsing.  You’d think that the artist alias would be enough, but you’d be wrong.  Take Bobby Valentino, aka Bobby V., aka Bobby Wilson.  I don’t believe he’s published any names under Bobby Wilson, yet that’s his current psuedonym (in this case, his real name).

Now, it would be fine – I think – to browse Bobby’s discography using nothing other than the Bobby Wilson alias.  However, we get into major problems when we want to see all songs where Bobby Wilson is the primary artist.  Those songs may exist on albums that are not Bobby Wilson albums at all – ie, soundtracks – or he may have still been going by Bobby Valentino at the time.

Basically, you’d need to search by all known aliases in those cases.

So after much consternation, I finally put together the code to make this happen.  Works a treat.  You have to take some care when putting together a manual search, as you have to understand exactly what it is you’re searching.  This is a fairly standard condition though, I think.  Otherwise, use the plethora of buttons and links which will do the heavy lifting for you.

While I was at it, I decided to tackle another dilemma: handling artist names that contain quotes.

Quotes are Bad News(tm) in the programming world.  You have to escape them, which isn’t bad.  But still, they can cause major problems.  Take the following example:

Give me all albums by Damian "Junion Gong" Marley, or by Lisa "Left Eye" Lopes.

Those are both valid artist pseudonyms.  And, if you construct the search with two artist fields OR’d together, you’re fine.

But in some cases – and this is true for our discography browsing code – you use a search specified like this:

artist is "Lisa "Left Eye" Lopes" or "Damian "Junior Gong" Marley"

There may be any number of reasons why you have to use this format versus the one above.  In my case it’s due to restrictions in the code and how parms are passed around.

Regardless, what you’ve got there are nested quotes.  And previously, my code would spit it out and give some unknown result.

No longer.  There are some basic assumptions that you can make:

• a quote followed by a non-whitespace character is an opening quote
• a quote followed by a whitespace character (or end-of-line) is a closing quote

There may be more, and more complexity, but you get the picture.  And indeed, these may be rules that you enforce rather than simply assume to be true.  With those rules in place, the code can now track nesting levels.  Escaping is another simple step away.

So here’s the scenario.

We’ve got this handy system called the Whole Home Audio system, and it allows us to play networked music to a number of physical and virtual zones.  We can use it to play music in the basement, or in the family room, or even in a car doing 100+ km/h on the highway.

Without question the physical zones are cool.  The family room zone is the coolest, since I can use my (dying) Harmony universal remote to issue transport controls and the system will respond accordingly.  That’s a pretty nice example of bridging hardware and software; in the family room, the nature of the audio system is completely* hidden.

* (the caveat is that, currently, you can’t select anything to play if nothing is loaded on that zone.  Minor issue, but I’m mentioning it in the interest of full disclosure).

The basement is somewhat unique in that the volume controls exist in the home audio interface, so you mash buttons on the interface page to increase/decrease volume.

In both cases, being physical zones, the requirement exists that we have sound hardware in the server to pump analog audio to the zones, and obviously, that there’s a physical connection between this sound hardware and the amplifying sound hardware at the destination.  This has worked for the basement and the family room, due to their proximity to the server.

The master bedroom, on the other hand, has never gotten to enjoy this sort of seamless/impressive hardware/software bridge.  It has always relied on a streaming client – functionally equivalent to my phone, or WinAMP on my work computer – to stream music through the floors and walls.  The streaming client in this case is GSPlayer running on a no-longer-used-but-still-loved PocketPC PDA, which itself is connected to a 2.1 speaker setup.

So playing anything to the master bedroom has meant:

1. Play something to a particular zone – usually streaming zone 3
2. Turn on the PDA and mash the play button repeatedly until WiFi connects and GSPlayer connects to the streaming zone
3. When your musical enjoyment has ended, power off the PDA

This works, but it’s less than convenient.  And as you can imagine, I wouldn’t be posting about it here if I didn’t come up with a solution.

And so, fresh off of my success with GSPlayer modifications, I once again delved into GSPlayer’s inner workings and gave it the ability to accept incoming TCP/IP connections.  That was part 1.  Part 2, was to give the home audio system the ability to connect to said GSPlayer and tell it to Do The Damned Thing(tm).

Okay, I’ll explain.  The idea here is that the user should only ever have to interact with the home audio interface/system when it comes to selecting joints and loading a zone.  You can use controls at the zone to control playback, once started, but starting playback should itself be a homogeneous process.  So obviously, pressing play on a home audio interface page, then powering on a PDA and pressing play repeatedly… well, that didn’t cut it.

The fact is that it’s the home audio system which receives your request to load a zone, so armed with that knowledge, it should be able to do Whatever Is Necessary(tm) to complete that request.  For the family room and the basement, this culminates in WinAMP being loaded with relevant song data and audio suddenly starts to stream out of the respective speakers.  Streaming zones will always* require a two-step process, and that’s to be expected given their nature.

* (there may be exceptions to this in the future; see this post for one example)

So yes, it’s true that the master bedroom needs to rely on a streaming zone since its physical proximity to the server can’t be (easily) overcome.  However, as a user of the system, your perception is that you’re at home, you’re in a static environment (ie, a room) and therefore you consider it a physical zone and hence you want it to behave as such.

Back to the technical stuff.  The GSPlayer modification allows the home audio system to tell the PDA to connect to the streaming zone and start playing.  And in a nutshell, that’s the crux of it.  You load the master bedroom zone using the home audio interface, and the system loads WinAMP and tells the master bedroom to connect.  The PDA must stay powered on all the time in order for this to work, but that’s trivial – much as the basement amp must be powered on to play music in the basement (it’s always left turned on).

Now, in practice, there were many considerations that had to be dealt with in order for this to work as expected.  A third component had to be modified – specifically, the WinAMP general purpose plugin that’s currently used to give certain feedback to the home audio system.  That plugin, being intimately tied to the guy that actually plays music, is the ultimate source for information on what’s happening.  And for the master bedroom, I decided that we wanted the “start playing darnit!” notification to be event driven and fired by the guy who knows when playback has actually started – ie, WinAMP, ie – the WinAMP plugin.

There are timing issues that help to lead one to this logical conclusion as well – as I said, there were many considerations.  But conceptually, the event-driven (ie, WinAMP-plugin-driven) approach it makes the most sense.  And the things that make the most sense are usually the things that are easily capable of resolving related, niggling issues.

So here’s what happens.  You select some Brian McKnight and send it to the Master Bedroom zone.  The home audio system goes through the motions of sending a playlist down to WinAMP.  WinAMP may churn and burn for a while, but we don’t care – nothing happens until WinAMP starts playing.  Once WinAMP does start playing, the plugin fires an event back in to the home audio system.  The system parses this, determines that the Master Bedroom has an “RPC-capable” client, and sends a suitable command to said client.  The client – GSPlayer in the master bedroom – gets the command to start playing and connects to the appropriate streaming zone.

And Bob is your uncle.

Once playback stops on the zone, GSPlayer will disconnect since the stream has stopped.  Or, if you’re no longer jonesing for Mr. McKnight, you press stop in a home audio interface page, and the system sends a command to GSPlayer to stop playback immediately – vs. waiting for the streaming buffer to empty.

So most of this has been tested successfully.  Today I cleaned it up and “properized”  it, so I’ve still got to make sure it works exactly as expected.  I may – or may not – post back here with my results 🙂