THE DAILY STREAM

Mike's site

Stuff and things

Latest updates
Newest first

Curmudgeons, get your facts straight

These days, there are more "solutions" to the problem of music piracy than you can shake a DMCA takendown at. While I'm somewhat in the Steve Albini camp of "we are passing the brief period of history where musicians were able to make a comfortable living," what I find interesting is the side discussions.

I saw this the other day thanks to a RT from a musician friend. I don't believe a word of it.

The author of the comment is betting that their audience lacks exposure to youth the same way they do. Young people are a scary, alien species who don't believe in paying for music.

But it's not because they don't value music of their time.

Discuss

Better static sites with Jade

UPDATE: I haven't used it in a while but in theory I really still like Jade Pug.

If, like me, you've been riding the current wave of preprocessors and static site generators, you're probably overwhelmed by the choices out there. As with musical tools, I tried to take my own advice and pick one thing to stick to for a while, see how it goes. I happened to pick a less-popular, less-mature tool with less documentation and material out there than any other. But it's not based in Ruby, and that should make Alex happy.

Jade was created by a 22-year-old CS undergraduate in England, and it's a super cool little pseudo-language for templates, written in Node. Unlike Ghost, which powers this blog, you don't need to get Node running on a web server to make sites with it, which can restrict your choice of web hosts. On the contrary, you run Node on your local box and generate a static site with the Jade processor, then host that bad boy pretty much anywhere.

Here's a little bit about Jade, and if you've used templating engines before you may find it to be pretty familiar. If not, then it's a really good starter language.

Basic Syntax

If I had to pick a central principle of Jade's syntax, it'd be the indention-awareness. Yes, it's written in Javascript, but you won't see brackets and semicolons everywhere (which is something I think Sass has over LESS). Just indent the next line and you're nesting html or logic.

body
  .container
    h1.pagetitle Page Title
    p#opening-paragraph This is some text.

Pretty simple, right? div is an implied tag, and the # and . do what you might expect if you passed CSS 101. Here's the output:

<body>
  <div class="container">
    <h1 class="pagetitle">Page Title</h1>
    <p id="opening-paragraph">This is some text.</p>
  </div>
</body>

A benefit here is that keeping tags properly nested and closed — which can be a bear when you're dealing with templates — becomes a lot easier.

Attributes are written as arguments, so this

a(href="/blog/",data-custom="val") Blog Link

produces

<a href="/blog/" data-custom="val">Blog Link</a>

Aside from a few idiosyncracies and some details, that's totally it for markup. I can't speak for all editors, but the always-wonderful Sublime Text does have syntax highlighting schemes for Jade to make life a little easier.

Variables

Variables are defined pretty easily — no need to set up a special block of Javascript or anything, just define it with a dash and put spaces around the =.

  -var dogname = "Rufus"

There are a couple ways to use variables. THe most basic is to put an = immediately (no spaces) after an element:

h2= dogname

This will produce <h2>Rufus</h2>, which is a pretty great dog name you don't hear nearly often enough. But sometimes things aren't that simple, and you need to get the variable into a string. If you know you want to produce <a href="Rufus.html">Rufus</a>, you can use a pound and curly bracket syntax.

a(href="#{dogname}".html)= dogname

This combination of the two types of variable output gives us what we want.

Mixins and Includes

Being tired of typing opening and closing carats is a pretty good reason to use Jade to begin with, but there's a lot more power in it than saved keystrokes and easy tag closing. Like CSS preprocessors, it gives you mixins, and like server-side languages, it provides for includes.

Includes are so self-explanatory they're barely worth mentioning, but I'll say this: remember your indentation when you call the include. You want to make sure your HTML structure stays intact.

Mixins are reusable blocks of markup or code that can take arguments. These can be used to absolutely destroy repetitive tasks. If you're in any way familiar with programming, think of a mixin as a function. Because that's what it is.

The following

mixin gal_image(imgurl,caption)
  li
    img(src="images/#{imgurl}")
    p= caption

Looks a little tricky, but let's break it down. First you define a mixin using the unsurprising keyword "mixin." You can add arguments as well — and you will likely need to.

You can output the arguments in both of the same ways you'd use explicitly defined variables. To use the mixin, just add a + and call it, putting the arguments in parentheses much like a javascript function. Here's an example usage for the above.

+gal_image("my_image.png","This is an image")

which produces

<li>
  <img src="images/my_image.png">
  <p>This is an image</p>
</li>

Not bad, right? As in this example, mixins can make short work of repetitive elements like photo gallery or portfolio images.

Extends

As with many template languages like Smarty or Django, Jade utilizes the concept of child templates and Extends to make files more efficient and manageable. For instance, a website could have a page template and a company-info page template that's based on it. Extends can go as many levels deep as you like, but a typical case for a static site might be 3 levels: base → page type → individual page.

In order to take advantage of them, just add extends with the URL to the base template at the beginning of your file. If you want them to really work for you, you'll want to use Blocks.

Blocks

If you've never used a templating system that features them, Blocks aren't immediately intuitive. But they're hugely powerful, and they're what makes Extends really work. In any given template, think of it this way: includes are static markup, but a block is something that could be variable from page to page.

include includes/header
body
  .content
    block pagecontent
include includes/footer

Here, the header and footer are includes because they're the same throughout the site. But to get a variable piece of markup or content in the .content div, we use a Block.

Now, on each page, tell Jade that we're extending the base.jade file, and reference the same pagecontent block:

extends base

block pagecontent
  h2 My awesome title
  p Hi I'm writing content! It's king, I hear.

Not rocket surgery. You can also define a default in the base template, so that in the event a given page doesn't have that block you can always fall back.

Getting it to Run

So how does this stuff work? I mentioned that it's not a back end language, so you're not going to run it on the server. It's pre-compiled into static files. Jade, like other Node-based tools, can be compiled in a number of ways. I'm not planning on getting too into that, but here are a few:

  • Node on the command line. This is the most basic. You can just compile a directory of Jade files into HTML, or have Node "watch" the directory and compile the files as you save them.
  • Grunt, which can run lots of other Node-based things at the same time with a single command in the terminal, and then get packaged for a deployment environment that works the same as your development one. Unfortunately, Grunt requires a lot of up-front setup to make that single command work. There are resources out there.
  • CodeKit for Mac (this app is really what got me into Jade. It's a bit costly but fun and also works with plenty of other pre-compiling tools)

Next I'll outline how I put together a portfolio site using Jade and LESS. Hopefully this was helpful.

Discuss

If you can't build it all, build a strong foundation

You've researched, interviewed, put stickies on a wall, flowcharted, wireframed, and designed (mobile first, right?) to a level of total perfection and certainty, and your product or site is going to be great. You nailed it. Then you're asked to QA the beta. Where do you even begin? This thing is just wrecked. You start to wonder if anyone on the dev team even looked at your designs.

Sound familiar?

Desginers and design teams, particularly at large companies, often struggle with their own internal process. But when it comes to working with development teams, things start to break down even more.

Different worlds

Agile development is a pretty mature process, but it doesn't really account for the more holistic way that product and UX teams tend to work. To a degree, Lean UX is an effective way for design teams to mirror the agile process and create a tandem workflow, but agile dev versus whole-earth design is only part of the problem.

Communication tools have improved as well: Invision, Skitch, and other visually-oriented software takes the back-and-forth out of the realm of cumbersome text documents filled with arrows, screenshots, and vague descriptions.

But at the end of the day, who cares more about the line-height, the spacing, the animation speed, the placement of elements than you, as the designer? No one, because you know the value of what you did. Because you did it for a reason. And what's more, when those visual cues, microinteractions, and precise responsive changes don't come out right, it not only makes for a substandard experience, it reflects poorly on you.

So... it's time to own it.

No mythical creatures needed

This is not more unicorn advocacy (fun fact: in the recruiting world, unicorns are called "purple squirrels"). The answer to all web software design problems is not "turn all designers into expert coders." Not everyone wants to or is capable of doing it all. The chances of finding someone who does it all really well are not great. And when you do, over-taxing them with all the work is not going to scale very well. The solution is to empower the team for front-end development.

Whether that means taking advantage of one of the unicorns you do have, or hiring a dedicated FED for your design team, it's crucial to build a bridge and stop treating design and FED as two different worlds.

OK, not different worlds then

UX folks know that UX is tied to every discipline and role: Product, design, back end, IT, and even sales. But design teams are responsible for the UI portion, and nothing affects the UI in a web-based experience more than FED.

So what does that actually mean, in a practical sense?

A website or web based product is generally going to have a style guide, even if your shop is lost in the Stone Age. If you're rocking a more modern fashion, you may be using style tiles or a pattern library. But the key here is that your guide can't be a Photoshop file, a list of fonts, and a sprite sheet. It can't be a wiki with PNGs and descriptions. It certainly can't be a piece of paper. It has to live in its ultimate medium: the web. What is a CSS file, after all, but a style guide that actually works?

Now, I recognize that every organization is different. With some exceptions, the dedicated FED teams I've worked with tend to be focused on the fun stuff that challenges them in the day to day: data bindings, animations, Gruntfiles (or is it Gulpfiles now?), and other fun scripting. They're worried not just about bridging the gap with you; in these Ajax-heavy times, they have to bridge the gap with the back end as well. And my guess is you're not dealing with strictly HTML/CSS folks — otherwise you wouldn't be having these problems.

Still, it's not good form to run onto the field, jump on the mound, and snatch the glove from the current pitcher. Reach a hand over the wall instead of throwing your designs over it. If your team or theirs is unwilling or unable to put a FED on the design squad, it's your responsibility to make it work some other way. That way is going to mean finding the person most likely to feel some investment in the style control and working with them to build your pattern library or style guide.

"I don't have that power"

In all likelihood, you actually do. Every company struggles with inter-team relations and workflows. You're not unique. The problem is that Process can rarely fix those breakdowns, and companies are bad at doing things that aren't processes. But people are good at communicating. Only communication from the trenches that will solve these issues. It's recognizing that we're all in this together, as the people who are tasked with making the things. It's about people working together instead of blaming each other.

It's definitely not about unicorns.

Here are some tools for building interactive, live style guides and pattern libraries.

  • Style Guide Boilerplate - We're using a version of this that I modified. It's simple, maintainable, flexible, and it works. It requires PHP, but if you're not up on newfangled stuff like Node then maybe your shop is better equipped for this.
  • Pattern Lab - Currently the new hotness. This tool builds everything for you and ensures that all the "atomic" pieces are in place. Also runs on PHP, with a Node version and plenty of other unofficial ports as well.
  • An overview of Pattern Library generators - This is a pretty comprehensive list. If you can't find something here, stop being picky or roll your own.
  • Creating Style Guides on A List Apart. If you do roll your own, here's what to include.
Discuss

Harrison Mixbus first impressions

I've never worked on an analog console. Sure, I've sat with someone and suggested technical and creative engineering decisions while they operated, but the UI paradigm of a console is only useful to me because I've used desktop mixers, and because pretty much all DAWs use some form of this paradigm. I don't have any allegiance to the old ways or the "sound" factor that usually consists of a bunch of vague assertions that analog summing is better (usually coupled with assertions that tape is better as well).

But what I do have is that drive to find the better workflow, the fastest way to creativity mixed with the ability to generate results. I also can't pass by a deal. For a $20 "no brainer" deal, it was certainly worth trying out Harrison Mixbus, even though Pro Tools is the standard and is a generally satisfying experience once you learn it.

The origins of Mixbus are interesting enough on their own: the project was born from an open source Linux DAW called Ardour. The Harrison console company, known for their super high end consoles used on a huge amount of popular records, used the existing open codebase as a skeleton that they fleshed out with their own EQ, compression/leveling, saturation, and summing algorithms.

Out of the box

Installing is a minor pain due to the requirement of a JACK installation, and subsequent restart. JACK is a system-level audio router that's somewhere between Soundflower and Propellerheads' ReWire. Apparently Ardour needs it to route from an audio interface to its own tracks. This means the JACK server, really a separate piece of software, has to run at the same time as Mixbus, but a side benefit is that audio can pretty easily be routed into it from other applications.

Why's that important? Well, to me it's important because Ableton handles all of my composition work, and Ableton is not that great at mixing compared with a package like Pro Tools. Unfortunately, ReWire mode in Ableton disables all the VST/AU plugins, rendering a good chunk of my instruments unusable. So I usually end up rendering audio tracks from Ableton and mixing those in PT, which is not necessarily going to get me the best results, aside from being a crappier workflow. I haven't yet gotten Mixbus controlling the transport in Ableton, but it does seem possible.

UI

Ardour was built originally for Linux. Thankfully, the Mac OS version does not require X11 or a Java VM. It hardly appears "native," though. The reverse-color scheme, the Gnome-style file pickers and very Linux-y UI components are alien, distracting, and not very impressive. Keyboard shortcuts aren't intuitive either: some are borrowed from Pro Tools and that helps, but system-wide commands like Command-backtick for window switching, or even Command-W and Command-H, are nowhere to be found. Many of the commands use Option as their modifier key, which is awkward. Still, a lot of the editing functions are single-key, something that absolutely has to be the case before a DAW can even sit in the same room with Pro Tools. I suppose I could probably re-map them to their PT equivalents, too.

By far the thing you'll notice about the UI the most is the mixer. I've written about skeuomorphs in audio software before, and it's all the same here. Harrison love to tout that they're a console maker, not a software maker, but that works both ways, and their application of a heavy, quasi-realistic mixer design has me gazing longingly at the screenshots of Ardour's relatively clean and straightforward (almost Ableton-esque) mixer. But as they'll tell you, this is a thing meant to replace an analog mixer, and the affordances (in the Norman sense) offered by the skeuomorphs help the special features come forward. In a way, it seems like they're intentionally reaching backward, and you can feel it when you mix.

Fast Access

First off, there's the impressive list of built-in elements on every channel strip, and I admit this is something that I'd probably miss if I were coming from the console world. I'm already enjoying them. In a typical DAW, pretty much everything, with the exception of EQ in some cases, is a plugin.

But in Mixbus, we get a lot:

  • Input gain independent of the fader or the clip gain.
  • a 3-band parametric EQ plus high-pass filter.
  • A compressor with three ratio types, speed control, and makeup gain. The threshold control and gain reduction meter sit right next to the fader and level meter.
  • A number of parameters from the selected insert plugin on the channel.
  • On the 4 mix busses and one master bus, there are tape saturators and different compressors tuned for the purpose.
  • On the master bus, a phase alignment meter and "K-meter" to measure perceived loudness.

What all of this accomplishes is a mix process that involves far less instantiation of plugins, far less opening of separate windows, and a workflow that keeps you looking at the mixer and maintaining a holistic picture of the mix most of the time. This is of course Harrison's goal, and I think they've met it well.

The major downside to this mixer is that there are only 4 "mix busses." You can add any number of busses for reverbs and other effects, but only the mix busses have delay compensation. That means a lot of multiple-bus tricks that analog and PT users employ, such as parallel compression, are out of the picture due to the phasing that'll happen without delay compensation.

But how does it sound

Again, I admit to knowing little about the console world. I've never wired one, and my understanding of routing and bussing comes largely from years of Pro Tools. Mixbus mirrors the real thing even more closely than PT, which provides both benefits and limitations (as with the limited mix busses). So what does it do for the sound?

I have to say, I've been impressed so far. But I'm not quite sure if it's the much-touted Harrison summing engine or whether the availability of the tools has let me get a good mix faster. Having EQs out front is important because you're tempted to use them. And most tracks are really going to need at least a little, but that tiny thought that pops up when you add a plugin creates enough of a barrier that you might skip it. And when you do add a plugin, it's probably going to have quite a few bands, and a distracting graphical display that makes you think you're doing something right because the curve "looks good" even though you might need more or less on a given band. Mixbus's basic EQ has two shelves and a bandpass that work in limited ranges, a Q that varies based on the amount of boost/cut, and a high-pass. Simple. No controllable Q, no ability to put all 3 bands in the high frequencies and create an insanely hyper-tweaked situation. Of course you can still do all that with the same plugins you know and love now, but you can get a really good mix just by carving each channel as necessary and then applying little touches of the onboard compression.

Performance

Unfortunately, there are some problems on the performance front. I was able to do some very quick mixes efficiently that sounded great without a lot of hassle, but with tunes that had about 6 tracks and not a lot of plugins (thankfully, you don't need as many plugins with Harrison). But when a client delivered me some songs with 27+ tracks to mix, it died pretty quickly. The meters don't respond, moving knobs and faders ceases to really do anything — the latency all around just gets ridiculous.

Side by Side?

At the end of the day, Pro Tools still has a lot going for it. I find myself doing a lot of wild and (IMO) creative stuff in PT when it comes to routing and bussing, stuff you just wouldn't be able to do with an analog console — or a DAW that mirrors one too closely.

And though I don't do a lot of MIDI work inside PT, I definitely have done some, and it's good to know it's there. I can add a nice synth to a track without going crazy routing multiple programs.

Mixbus also has some good editing tools, some of which are minor UI innovations and others of which are cribbed from PT, but PT is a much faster and more powerful editing machine. It's also one that I know already whereas I've played with Mixbus for about 3 days. I've no doubt I could get pretty handy with the flexible editing functions in Mixbus as well.

At the end of the day, it's a great mixer, competent editor, and it sounds very good with no supplemental software. If you're looking to make great sounding tracks for a lot cheaper than Pro Tools and don't need MIDI functionality beyond sync, it's a really compelling tool.

And it's fun.

(Harrison's YouTube channel is an easy way to get started playing with real practical functionality within a few minutes. The videos are short and informative, and even have some helpful general mix tips.)

Discuss

Diego Stocco's Rhythmic Processing

Diego Stocco is an Italian sound designer who's worked with, among others, Hans Zimmer. He's perfected a fairly interesting technique of processing sound sources with some rhythm into multiple tracks of kick-snares, bass, and clattering beat-repeaters.

Recently he started selling his secret sauce in the form of some impulse responses for convolution reverbs as well as a $10 instructional video, Rhythmic Processing.

I thought I'd try it out.

The basic premise of this short (under 10 minutes) video is that Stocco plays a rhythm with a chopstick on an acoustic guitar, then walks you through his Ableton Live effects chains to show how he turns the whole thing into a massive beat with tons of variations and atmospheric textures.

The first thing you'll notice is that he's efficient — this thing requires a lot of pausing to look at the settings of the plugins. That's fine, I'm sick of overly long YouTube tutorials.

His method is basically to take the sound and split it, using EQs and filters, into multiple bands on multiple return channels in Ableton. This is a technique I've used in Pro Tools for complex "fixing" on already-mixed sources (I don't have any dedicated multiband processors), but as a creative exercise it's pretty neat.

Stocco doesn't prescribe any particular plugins. However, non-advanced Ableton users may balk at the fact that a couple of the plugs he relies very heavily upon cost money.

There are, however, free sequenced gates out there for VST and AU, as well as a few "trance gates" on the NI User Library if you're into Reaktor. For the ultimate no-cost sequenced gate, just place a standard Ableton gate effect in place of Stocco's plugin and feed a sequenced percussive sound into the side chain. Not tough.

Is it worth $10? Well, it's nothing that someone else might not be able to show you, but Stocco is known for this stuff and it's worth a glimpse under the hood. The video is very short, and that may put some people off, but it's very dense in information. I felt pretty inspired.

Discuss

Hey screen designers on Macs

You should do this.

Scroll

Obviously different OSes have different scrollbars, but you'll save yourself a lot of trouble and possibly spot some HTML mistakes before they get bad from just knowing they're there.

Discuss

The enemy of done

I'm sure that you've heard, at some point, some wizened sage say a thing about how limitations are helpful when it comes to creative endeavors.

Probably it was someone like Frank Zappa who didn't practice what they preached, but this isn't just "good for you" advice; it can be fun.

What simplification means in a creative sense can be up to you: it could mean limited tools, a smaller palette, a shortened time frame, or really impractical and artificial constraints meant to "get the juices flowing" (e.g., I'm only going to use MS Paint or build a song with presets from early 90s synths). But as an exercise, it's one thing; adopting simplicity as a way of working is a freeing experience.

After a some great frustration playing in a large band with intricate arrangments, I decided to simplify my musical existence by going back to a one-man show for a while. But that tends to be a rabbit hole for me. I love choices and hate limitations. I don't necessarily feel like I need to use my whole toolkit in every project, but I want to know I can start anywhere. The problem often is in starting, though. A limited palette can make that easy.

So I've created a much smaller subset of tools: two sampled analog drum kits, a Volca Keys, a '73 Roland SH-1000, a Reaktor-based Minimoog emulator, and a MeeBlip SE. It's a kind of weird hybrid of real and simulated analog, and it's all really cheap. It also feels like a pretty wide sonic palette right off the bat, but I do need some kind of variety because I tend to write synth lines based on the qualities of a particular sound. The Minimoog has enough variety to spark something unique, but picking from two drum kits means I'm laying down a beat in 5 minutes instead of auditioning sounds and building kits for 40.

Over the weekend I wrote a complete song during the baby's nap time. A couple hours and everything was done. Beat, bass, lead line, effects, tricks, vocals. Done.

A nice side effect

Something that I discovered from going limited is that simplicity isn't the only benefit — the inability to achieve perfection has opened my mind quite a bit. I've kept the SH-1000 out of my sets for anything other than some noisy filter effects because it's monophonic, hard to play, hard to keep in tune, and doesn't have MIDI or the ability to save sounds. With Ableton, I don't need MIDI or patches: as long as I can adequately play a loop one or two times through, I have a bass or lead line recorded as audio. The key here is adequate. It's not going to be perfectly synced, and even if I played it perfectly it wouldn't necessarily register with the 40-year-old raggedy-ass keys and the tuning would still be wonky. The Volca's similar: it can be synced to MIDI, but it can't save sounds either and the tuning tends toward unpredictability.

So this stuff means my music isn't perfect. But it's also got some character as a result. Aside from how you feel about tweaking sounds or cutting loops precisely, whether these things improve your music, there's one thing you can't argue with: I finished something. Quite a few somethings.

There's a saying that "good is the enemy of great." That's true, and you should always keep your standards high and your goals lofty — but remember also that perfect is the enemy of done.

Discuss

Tweakin'

I often wonder what the intersection of my two primary interests — UX and music — might be. Unfortunately, it usually seems like the main manifestation of this is in the obsessive tweaking of processes and tools.

It's probably natural for UX designers of a certain experience level to engage in service design thinking. You eventually start to think about the holistic world rather than just the point where a customer touches a software interface. But then again, it could very well be that the obsessive desire to have the perfect experience yourself is the driver of that kind of thinking. It's a chicken and egg situation, but whichever came first with me, my point is this: I'm constantly editing my tool chain.

The answer may very well be in simplicity (more on that at another time), and it definitely lies in compromise. I'm just not sure there's a really perfect process. Transparent tools that don't make you think are pretty much the ideal for creatives — for instance, in a live situation, tools that keep you from touching the laptop trackpad. That's why I bought an Akai APC40 controller for Ableton on Craigslist, but of course I still have to open new files, and that's a source of inaccuracy and anxiety onstage. So I've been trying to crack that nut. The quest continues. And in the meantime, I use the hardware equivalent of a polyfill, something that a layman might call "a trackball on stage."

Same in the studio. My best purchase of the past year was not a plugin or piece of hardware but a set of $10 keyboard shortcut stickers for Pro Tools. It eased my learning and enabled me to work much faster, especially in the editing stage of a mix. The up-front setup (about an hour peeling and sticking these little nightmare labels), analogous to say, setting up a new project management software, made every subsequent day a little easier. Until I ruined the keyboard with a beer spill. Don't drink and mix, kids.

Same with design. I've been playing with Sketch and ended up buying it because of the insane speed it offered me in a few key areas after just a short learning curve. The paradigm shift is just different enough that it mirrors Ableton: a program that is indeed a DAW and has mixer sliders but requires a completely different thought process from the old-school Pro Tools/Cubase mentality. Sketch is definitely a design tool, but it's been honed and trimmed back to incorporate only the elements you need for the particular type of design you're doing; in this case, it's screen design. But... there are holes. It doesn't do bitmaps at all, I mean at all, even compared to Illustrator. so I lose the valuable hybrid "don't think about the vector/bitmap divide" approach of the otherwise-clunky Fireworks. Which means that again, my process is incomplete and I have to fill in the gaps with workarounds and additional tools.

So what's the answer? I don't think there is one. If I rewrote this post next year, I'd be talking about different tools but it'd look remarkably similar. At some point you have to settle for "good enough it's not in my way," but it's still worths striving for the zen happy place of "perfection."

Discuss

The Equals

I've always liked to trace the origins of musical artists and their tunes. It's probably one of my nerdiest hobbies -- I can't really come down on anyone who memorizes worthless sports stats because I know which Current 93 record Steve Ignorant of Crass sings on and the years each of Neil Diamond's Hot August Night live albums were released.

This was a lot harder before the internet; most information came in the form of serendipity when a recognized name cropped up in liner notes.

Since the advent of the web and standardized sources of info, it's easy to trace origins. But sometimes because there aren't any liner notes anymore (if you're buying mp3s or streaming), little tidbits and cover songs can slip through.

That's the case with The Equals: I hadn't heard of them but when I heard a loud glam-rock stomper by them on KOOP, I looked into it. Not only was the singer Eddy Grant the guy who lodged "Electric Avenue" in our collective brains, they had a pretty solid influence on the Clash. Here's the original version of another ahead-of-its-time song the Clash did a great job with, "Police on My Back."

I guess as long as there's music out there, it's possible to be surprised every once in a while still. Thankfully.

Discuss