Let’s get fucked up and play records

DJ2009

It’s ok to laugh at that picture. I had to go way back to spring of 2009 to dig it up. In a way, it’s the inspiration for my latest series, “State Dependent Learning.” See back when I first learned to DJ, I was always annihilated. My house has always been the go-to afterparty house because I have exactly zero qualms about paying noise complaint fees and fielding calls from angry landlords to… my voicemail. So whenever I’d come home from the bars, it was usually with the party crew and the first order of business was always to get some music going. At that time I wasn’t really too concerned with mastering my craft or even practicing for that matter. On the few occasions that I did try playing sober, I sounded like shit. This confused me because I FUCKING ROCKED IT WHENEVER I WAS WASTED! The obvious conclusion is that I was suffering from State Dependent Learning. Per Wikipedia,

State-dependent memory, or state-dependent learning is the phenomenon through which memory retrieval is most efficient when an individual is in the same state of consciousness as they were when the memory was formed. The term is often used to describe memory retrieval while in states of consciousness produced by psychoactive drugs – most commonly, alcohol, but has implications for mood or non-substance induced states of consciousness as well.

For more years than I care to admit, I would just simply refuse to play sober. I’d get a few cocktails in me and the jams would just flow. In addition to my ongoing “Bowling,” series that you’ve gotten to hear for the past 2 weeks; I’ll be periodically be making sets where basically all I’m doing is letting the liquor do the thinking and recording mixes. For this first one, I was drinking some fancy bourbon that I took from my roommate’s liquor cabinet (Sorry not sorry Dan). Towards the end of the set I got a little too drunk so I pulled my signature move of drinking Coors Light to sober up. Without any further introduction, let’s get fucked up… play records!

State Dependent Learning – Vol 1 (3/11/2015)

Tracklist

  • 1 – Ninetoes – Finder
  • 2 – Monkey Safari – Watching the Stars
  • 3 – Joyce Muniz – Sleepless
  • 4 – Rey & Klajek – Animal vs Beast
  • 5 – Doctor Dru – 2 Know U
  • 6 – Adana Twins (feat. Digitaria) – Reaction
  • 7 – Go Freek – The Way You Dance
  • 8 – Alexis Raphael – Assault Weapon (German Brigante Remix)
  • 9 – Wonkers – Firecity
  • 10 – Antonio Giacca – Alright
  • 11 – Turntablerocker – Grow up
  • 12 – Ardalan – Catchup
  • 13 – The Holy Mash – Gifted
  • 14 – Dustin Nantais – Arm Bar

One more thing…

Before I move onto talking about the music hosting awesomeness that I can hardly contain my excitement over, I want to give a shoutout to French producer The Holy Mash for giving me permission to include their track Gifted in this set. It’s definitely one of my new favorites and I’m looking forward to see what else comes from them!

Now for that techie goodness that you all really came here for…

Well I’ve got to say, this music service has really taken on a life of its own. I did get a few feature requests so I went ahead and added the most common one, download links. The headers of the sets should now be just that! There really isn’t anything too technically special about what I did. Just updated setplayer.js to insert an A tag into the header element with the set’s file location. Now whenever you visit http://imjustinbraun.com/djsets/index.php?Request=DisplaySets, you can download whatever there. As always, you can see the final working product on my jsfiddle. I did run into one little pitfall on line 92 of setplayer.js – basically I’m loading in the first track by searching for the first A element in the output. Since the download link is now the first A tag, I modified the line to mean the first A element immediately preceded by an LI element. Simple enough.

Last week I promised that I was going to make a RESTFul back end for this whole thing, improve the player, and create an uploading service. That turned out to be a bit of a tall order considering that I have a fulltime job and I had a killer hangover the other day from recording the set that you’re currently enjoying. Also, this whole project has required a ton of architecting, planning, and well, thinking ahead. So instead of posting any code, I’m going to talk about the architecture I ultimately arrived at and why. Next week I’ll start sharing more code with you. In terms of initial requirements, I wanted whatever I designed to have the following properties:

  • Loose Coupling – I don’t want one API change to fuck up all of the clients and I have to spend a week listening to pissed off users that refuse to upgrade
  • Scalable - If by some miracle I’ve got 100K users banging down my door tomorrow wanting to listen to my drunken recordings, fuck yeah!
  • Platform Independent – Because nothing short of my superbowl commercial would serve my vanity better than having an imjustinbraun iphone, iwatch, ipad, and android apps
  • Orthogonal - At some point I’m going to want to open this thing up to other DJ’s, Producers, and Record Labels (their lawyers, however, can fuck off). I’ll need to be able to easily accommodate feature requests without breaking everything.
  • Easy - Ok so maybe I’m a genius and could write the thing in machine language or lolcode (yes that’s an actual thing), but if I ever bring on other developers to help me with this little project, I don’t want to use some obscure tech that only I can figure out.
  • The Architecture

    With those requirements in mind, I set out to fulfill them using the tools that I readily have available in my shed. I decided to use Amazon AWS as my hosting provider. I’m using what initially passes for a traditional LAMP stack (A few years ago I wrote a step-by-step guide for how to set one of these up here), though I have a few tricks up my sleeve this time. One thing that makes Amazon so powerful as a webhost is that they really have thought of everything. Between Elastic Load Balancing, Autoscaling groups, and Cloudfront – I can offer SERIOUS amounts of scalability with minute-by-minute sizing so that I’m never paying for what I’m not using.

    Regarding the API, I want to make sure that whatever clients interact with the back end aren’t coupled to any particular technology stack. The world seems to be in love with RESTFul API’s these days and I can see why. They’re simple, scalable, platform agnostic, and is incredibly easy to secure using HTTPS. Further, because it’s centered around resources rather than procedures, changes to the API seem like they’ll break a bit more gracefully (I’ve yet to test this theory, though I have little doubt that it will be tested at some point in this little adventure). I did give websockets a serious look, but I ultimately concluded that unless I decided to write my own streaming format, they’d be overcomplicated overkill.

    Writing a REST API from scratch in php is a serious undertaking and an entirely unnecessary one. There are TONS of frameworks out there that will do the heavy lifting for you. I ultimately selected RDev for a number of reasons. For starters, it’s a framework that I’m very comfortable with. I’ve deployed RDEV in major financial institutions, so I’m fairly familiar with how to make it work securely and how to make it scale. It doesn’t hurt that I’m personal friends with the guy who wrote it, so I can always bug him with questions and feature requests. But I think the main reason I continually choose RDEV is because it’s fucking awesome. I won’t go into the laundry list of features; Dave’s website can do that for you, but I will say that he is constantly adding little bits and pieces that make RDEV easy to use. It’s rock solid – He’s got some ridiculous amount of unit tests that he writes before he even builds features (a habit I need to start getting into myself).

    Looking Forward

    I hope you’ve enjoyed this musically charged rant! Next week the gameplan is to teach you guys how to get RDEV up and running and if there’s time, maybe I’ll even have a better player for you to listen to my mixes with. In the meantime, if you would like your music in my sets, feel free to email your tracks to imjustinbraun@gmail.com. You can also feel free to contact me with feature requests, comments, ideas, or questions. Till next week!!