I am a software engineering student. The exact definition of that varies among my classmates and professors. Some say that it implies an ability to write software. Others argue that it requires a strong grasp of algorithms and mathematical optimization. Still others say that software engineers need only be able to design large, complex pieces of software, or manage teams of coders, or communicate project specifications, etc.

Few people correlate software engineering with art.

There are those that will argue that "software itself is a form of art," or that "this code is beautiful." There are certainly pieces of software, written in different languages, that could be considered their own distinct forms of "poetry." (And no, I'm not just talking about Lisp poetry.) Elegance, cleverness, and the functionality of the code all contribute to this sense of inherent artistry.

I prefer to write code that is outwardly visible as art. Code that you need to run, not read, to appreciate.

Although there is a fair amount of complexity behind this site, the part that was most enjoyable to implement was this schedule view. It helps that it's beautiful and eye-catching, but writing code to make this design functional was extremely satisfying. Even more satisfying was the ability to see someone use the site, enjoy it, and being able to say "Yes, I helped make that."

This site, via its design and partially through its functionality, is a form of art. I've spent my first three work terms (one year in total) working at web development shops on client projects, implementing (and sometimes designing) beautiful software that can be appreciated by almost anybody. I had a great time doing that, and enjoyed nearly every minute.

This is the Wub Machine, my online music remixer. If you know me, or if you read this blog, I'm sure you've heard enough about it so far. One thing I haven't talked about yet is the art behind it.

I initially created the Wub Machine as an experiment in computer-generated music. If I were an arts student (or even a grad student in some software programs), it would have made a great thesis project to explore computer-generated art. While the technology used to power it is stunningly awesome, and the site itself is somewhat complex, that's not the purpose of it. (Although, I did learn a lot.)

The average user of the site is not a technophile. They could care less about the software. However, the average user can definitely appreciate the product - a piece of music (ahem, mostly) that is not only listenable, but danceable and entertaining. Many would call it art.

(Hopefully.)

This is a screenshot from Dead Rising 2, an awesome action-adventure game released a couple years ago by Capcom. Yes, those are zombies, and that's the main character (Chuck Greene) using a modified yard tool to mow them down. It's a great game, with a great story, great gameplay, visuals, music, and the like. Save for some vocal critics, most people would consider this art.

Visual artists modeled Chuck Greene's character. Writers crafted the brilliant story. Software engineers put it all together, and made the entirely immersive experience possible. Their work, while technical and complex, is just as much art as the models, textures, sounds and words in the game. It doesn't just allow users to interact with art; it forms the fundamental experience that is enjoyed and appreciated.

Using software to make immersive, beautiful, artistic experiences that can be appreciated by anybody is awesome.

TL;DR: Software can be art, in many ways. That's what I like to make.

Permalink | Leave a comment  »

I've noticed a distinct trend in all of my recent work. Not all of it is useful, and not all of it is feature-complete - but it all places a lot of importance on form over function. Let me give an example:

Earlier this month, I put together a quick site called lndr.me, which tracks the usage of laundry machines at VeloCity, my student residence at the University of Waterloo. It's simple and email-driven. Residents can email washer@lndr.me to say that they're using a washer, and they'll get an email back in ~30 minutes to remind them that their clothes are done. Other residents can also check the site and see if the machines are occupied.

It's an exceedingly simple idea, with very little code required on the backend. (It's a Rails app with ~300 lines of ruby.) I've even made an API to allow other residents to make apps out of it, or link in hardware sensors with Arduinos and ethernet shields.

However, before I even had the idea fleshed out, or the implementation decided on, I did a mockup. I opened Photoshop, drew some icons, found a simple colour scheme, searched for a viable domain name, and scribbled a UX flow into my Moleskine before ever typing `rails new app`.

This simple (some call it cute) design was my starting point. I added some things along the way - animation on the waves in the washing machine to show it's running, or a slightly-shaking dryer icon to show the same - but most of the product was finished before I started writing code. I essentially started from the user's perspective and then built inwards.

Now, some people will surely think this is obvious. "Of course you wait for designs first before starting implementation, that's just obvious!" you yell. In the client-and-project-driven world of software contracting, that's absolutely true. Specs must be finalized, and designs (or at least mockups) finished before the product is built.

A lot of other people, though, are confused by this. "It's only a side project, who cares how it looks?" you might say. Or "I'm not a designer, I'm a coder." I've heard both of those far too often to dismiss.

Your product's user experience is just as important as what it does. Most apps do things that are marginally useful - track laundry, wake you up in the morning, play music, or give you directions. Would you use a music player that required a screwdriver to change songs? What about a map that gave directions in a series of JSON-encoded latitude and longitude coordinates, to then be decoded by the user? Of course not.

Products are successful, useful, and a joy to use if they have great user experience. A lot of hackers and coders nowadays don't realize how important this is.

Let me give another example:

Ninjaquote is a site created by Scott Greenlay, Jinny Kim and myself in 24 hours (21:15, to be exact) during the recent Facebook hackathon at the University of Waterloo. Its goal is simple: it takes two of your Facebook friends, and finds something one of them said in the past, and quizzes you on it. The game is exceedingly simple, and has another dead-simple user experience.

1. Click to authorize the app to view your Facebook account.
2. Receive quote.
3. Click answer.
4. See if you were correct.
5. Goto step 2.

This simple UX, coupled with a good domain name and great mascot, makes the site a pleasure to use. So simple to use, in fact, that it won the hackathon.

This confused me at first. Other entries were far more technically complex - Hachi was an in-browser collaborative code editor built in Node.js and Socket.IO. FriendMozaic did some image processing to make your profile picture a mosaic of friends' pictures. PrivacyVeil used some crazy OpenCV processing to detect faces behind you while you work, and pop up an Excel spreadsheet to cover your Reddit browsing.

Our winning entry was effectively ~1000 lines of Javascript, CSS3 and HTML5. Nothing fancy, nothing new - just a working, effective, and addictive user experience. Having the minimum number of features wasn't a hinderance, as we had design to make the site appealing anyways.

tl;dr: Find the middle ground between form and function. It's much more valuable than either extreme.

Permalink | Leave a comment  »

I walk through Yonge & Dundas Square in Toronto every day.

That intersection, which some call Toronto's equivalent of Times Square, has a large number of street preachers. Loud, startling, obnoxious people that yell warnings of doom or urge repentance. Silly people.

I decided to use Twitter's real-time streaming API to make an extremely specific location-based Twitter bot. The purpose? To respond to you if you tweet near the street preachers at Yonge & Dundas, with similar messages. Call it art, or a statement about society, or making fun of those preachers, whatever - I call it a fun technical and social experiment.

Using an excellent ArsTechnica article as a guide, I created a quick Python script that watches the Twitter stream for a given area, and replies to tweets in a very specific location. (±10 meters or so, by my guess.) If you're one of the lucky few to tweet within those bounds, you'll get a reply from @yonge_dundas:

A day later, I decided to clean up the script (rewrite it in Ruby, too) and open-source it. Well, here it is, in a quick Github gist:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139

# "The Street Preacher"
# hyper-local twitter bot
#
# by Peter Sobot (psobot.com)
# November 29, 2011
#
# ---------------------------
#
# Instructions:
#   Place phrases in phrases.txt (one per line)
#   Set a latitude and longitude (@from_lat, @from_lng)
#   Set a radius (currently in degrees lat/long)
#   Set your twitter account's username (to prevent feedback)
#
#   Enter your Twitter application keys and OAuth credentials
#     (get them from https://dev.twitter.com/)
#
#   Run:
#     `ruby preacher.rb`
#
#   ???
#
#   Profit! (Not really.)
#
# ---------------------------
#
# Defaults are set to Yonge & Dundas Square, Toronto.
# @yonge_dundas is a twitter clone of the notorious street preachers
# that live at that intersection.
#
# ---------------------------
#
# TODO: 
#   Debug the tweetstream daemonizer (doesn't like Logger to file)
#   Add some rate limiting

require 'rubygems'
require 'tweetstream'
require 'twitter'
require 'logger'

@logger = Logger.new STDERR

# Twitter phrases:
@phrases = IO.readlines('phrases.txt').collect{|p|p.chomp}
def random_phrase
  @phrases.sort_by{ rand }.first
end

# Set this to your account's username, so it doesn't feedback loop.
username = "yonge_dundas"
@exclude_users = [username]  # Could exclude more users

# Tweet from:
@from_lat = 43.65641564830964
@from_lng = -79.38105940818787
radius = 0.001 # catch area in degrees lat/lng

consumer_key = "your_twitter_consumer_key_here"
consumer_secret = "your_twitter_consumer_secret_here"
oauth_token = "your_oauth_token_here"
oauth_token_secret = "your_oauth_token_secret"

# Confiruationses
Twitter.configure do |config|
  config.consumer_key = consumer_key
  config.consumer_secret = consumer_secret
  config.oauth_token = oauth_token
  config.oauth_token_secret = oauth_token_secret
end

TweetStream.configure do |config|
  config.consumer_key = consumer_key
  config.consumer_secret = consumer_secret
  config.oauth_token = oauth_token
  config.oauth_token_secret = oauth_token_secret
  config.auth_method = :oauth
  config.parser = :yajl
end

# Let's make us a bounding box to give Twitter's streaming API
N = @from_lat + radius
S = @from_lat - radius
E = @from_lng + radius
W = @from_lng - radius

def parse_tweet status
  return if @exclude_users.include? status[:user][:screen_name] 

  if status[:coordinates] and status[:coordinates][:type] == 'Point'
    lng, lat = status[:coordinates][:coordinates]

    if    lng < [E, W].max \
      and lng > [E, W].min \
      and lat < [N, S].max \
      and lat > [N, S].min

      @logger.info "Got one! Replying to @#{status[:user][:screen_name]}:"
      @logger.info "\t#{status[:id]}: \"#{status[:text]}\""

      if not status[:in_reply_to_user_id] \
        and not status[:retweeted] \
        and status[:entities][:user_mentions].empty?

        tweet = Twitter.update(
          "@#{status[:user][:screen_name]} #{random_phrase}",
          :in_reply_to_status_id => status[:id],
          :lat => @from_lat,
          :long => @from_lng,
          :display_coordinates => true
        )

        @logger.info "\t#{tweet[:id]}: \"#{tweet[:text]}\""
      else
        @logger.info "Didn't reply - tweet was mention, retweet or reply."
        puts status[:in_reply_to_user_id].inspect
        puts status[:retweeted].inspect
        puts status[:entities][:user_mentions].inspect
      end

    else
      km_away = Math.sqrt(((lat - @from_lat) * 111)**2 + ((lng - @from_lng) * 79)**2)
      @logger.info "Tweet not within bounding box:\t#{km_away} km away."
    end
  end
rescue Exception => ex
  @logger.error ex.message
  @logger.error ex.backtrace.join "\n"
end

@logger.info "Starting up the Street Preacher..."
TweetStream::Client.new.on_error do |message|
  @logger.error message
end.on_reconnect do |timeout, retries|
  @logger.error "Reconnect: timeout = #{timeout}, retries = #{retries}"
end.locations("#{W},#{S},#{E},#{N}") do |status|
  parse_tweet status
end

The only trouble I had with the resulting script was that it doesn't have proper daemonization - the Ruby Daemons gem that comes packaged with TweetStream doesn't play nice with Ruby Logging. (And it could use some rate limiting.)

Feel free to fork it, repurpose it, and do whatever! (Just keep my name at the top, if you please.)

Permalink | Leave a comment  »

Four months ago, I released the Wub Machine, an online Dubstep remixing web app. It hit Reddit for a couple days, got popular on 4chan, and has since remixed nearly 24,000 songs. About a month ago, at the wonderful Music Hack Day Montréal, I wrote and released an Electro-House remixer to complement the Dubstep one. It sounds kinda awesome - here's Stevie Wonder, remixed: 

I Wish (Wub Machine Electro Remix) by Peter Sobot

Since then, I've polished up a completely new framework for the Wub Machine - nearly everything about the site has been rewritten since its first release. The first version was held together with duct tape, PHP and prayers, which resulted in some catastrophic failures when the site was initially launched. I've sinced rebuilt it in 100% Python, load tested, and added features.

Instead of talking about the code (which I do over on GitHub), I have a better story - being featured on the immensely popular VSauce channel on YouTube. I got a seven-second mention (and the thumbnail of the video!) and on Tuesday night, when the video first went up, all hell broke loose. My little Prgmr server couldn't keep up with the 15,000 visits in 3 hours, and the load has kept up steadily ever since.

A day later, I've flirted with Amazon EC2 and other hosting solutions, migrated databases back and forth, jumped up and down and watched live Google Analytics for far too long. I moved the site to a new host (not Linode, although they're awesome) and finally, it can handle the load.

So, what lessons have I learned from *this* surge in Wub Machine usage?

• Be prepared to scale on-demand. I should have built the site on some sort of scalable, EC2 or Heroku-based architecture that I can instantly increase capacity with. As it is now, I had to scramble to find a faster web host that I could deploy onto, wait for DNS to switch over, clone the database, etc. Ideally, I could have integrated the site with EC2 to detect surges in popularity and spin up a new worker instance. Alas, that costs money and I'm cheap.
  • Know your options for scaling, too. I didn't realize I could have spun up instances running the same code, and just proxied with a cookie via one master Nginx machine. Either way, there's a number of ways I could have scaled up, and I didn't consider some of the most popular options, only because I hadn't heard of them.
• You never know who your next audience will be. I had previously prepared the site for Reddit, HN, Evolver.fm, etc: sites with a more tech-savvy audience. YouTube, on the other hand, is one of the most accessible sites on the internet. My latest surge in users has come from what seems to be teenagers and your average, casual YouTube user. (the kind with a four-digit number on the end of their username.)
  • Why is that important? Well... Reddit, Hacker News and other similarly technical audiences respond badly to advertising. I had left off ads from the site for a number of reasons, one being they wouldn't be very effective. As soon as I saw YouTube flocking to the site... I figured they'd be slightly more interested. And so far, they have been. Very much so. I think I'll leave the ads in place. (The site can finally pay for itself!)
• Know how to jump ship. In the past couple hours, as I've been trying to make the site faster, I've literally set up the site on 3 different servers. It saved me a ton of time to have an installer script that (mostly) worked. All I need to do now is make that automatic, and I can do something like a Capistrano deploy to add capacity.
  • ...and know how to take your data with you! I forgot about my DB at one point, which caused a couple conflicts, and now my statistics are missing about 100 remixes. Not a big deal, but still - have some plan in place to flip databases over instead of copying them. Or something.
• People will get fed up and leave. I have a handy statistics page now that shows me (in real-time!) the activity on the site. I can see as people upload a track, how it progresses, if it fails, why it failed, etc. I can also see clearly when people upload a track, don't want to wait, and close their browser. Although that can sometimes happen due to an overloaded server, more than half of the people who visited during this spike turned away after seeing that they'd have to wait. Perhaps something to try to avoid, but that ties in to my next point...
• Care about your users... just enough. That sounds incredibly callous, so I need to clarify myself here. Any website owner should absolutely care about their users. User experience is, in my books, the most important thing to work on. However, if your app goes viral and/or reaches a very wide, very diverse audience, you have to balance that care for UX with your own needs and sanity. I've recieved a handful of emails so far from ordinary people, demanding that I get the site running faster, or that I add feature X and feature Y. Not suggestions, demands!
  • If you can provide a working app, and do your best to keep it working and user-friendly, then you'll still never hit 100% in all of your metrics. There will always be people who have a bad experience on the site, if only because of their own personal situation. (i.e.: browser, connection, or internet literacy) I usually try to go the extra mile and make what I'm working on close to perfect, but at some point, it becomes futile.

So, what's next for the Wub Machine? I'm not sure. I still consider the algorithm a bit of a hack, although it sounds distinctive and kinda cool now. I'm planning a YouTube remixer, but that's technically challenging. There are some small technical problems I can try to fix as well, and I can continue to improve the code base and open source the changes. And of course, I need to keep it running. Otherwise... statistics!

Wub Machine Statistics (as of November 10, 2011):

• 637,568 Facebook story impressions
• 208,792 total site pageviews
• 64,673 total unique visitors
• 29,801 total songs uploaded
• 1,956 hours of music remixed (82 days worth!)
• 85% of tracks remixed successfully
• 1,143 remixes shared to SoundCloud
• Most commonly-remixed artists:
  1. The Beatles
  2. Daft Punk
  3. Adele
  4. Deadmau5
  5. Skrillex
  6. Gorillaz
  7. Blink-182
  8. Led Zeppelin
  9. Radiohead
  10. Deerhunter (oddly, only the song "Helicopter")

Permalink | Leave a comment  »

The Wub Machine, my fancy dubstep-remixing web app, unexpectedly launched last week. In the days that followed, I took a crash course in how to manage a heavily-used web service. Here's the first of many pretty graphs:

That's a graph of all of the actions happening on the server, by hour, since launch. I decided to keep track of 4 distinct actions:

1. Uploads (whenever a song was uploaded for remixing)
2. Processing (started/finished/failed) (the analysis & rendering of the remix)
3. Sharing (sharing of a remix to SoundCloud)
4. Downloads (when a user explicitly downloads their remix)

All of these actions are graphed separately, to provide a detailed look at what happened over the first week of running the Wub Machine.

So, what did I learn?

See the full gallery on Posterous

1. Don't pretend to have capacity.
   • I didn't expect such massive server load, and as such, I assumed there would be no harm in allowing people to upload tracks when other tracks were being remixed. This ended up creating a never-ending queue of songs, and prevented anybody from effectively hearing a remix for what would have been a 16 hour wait. Those who did upload songs for remixing had to wait exorbitant amounts of time for their remixes to finish, and the service effectively ground to a halt. Instead, I should have implemented a system that forces users to wait until capacity is available. (And I did, afterwards. Currently, you can't upload a track if the site is currently working on one.)
   • I did make an emergency fix, though: the giant red spike you see on the graph above is the queue of 900 songs, all from eager Redditors, being cleared at once. The queue would have taken nearly 16 hours to process, and effectively caused the site to grind to a halt while still on the front page of /r/Music. A significant portion of the songs uploaded had been abandoned, and wouldn't have been heard, but were still stuck in the processing queue. Needless to say, the entire system could have used more load testing.
2. Test, test, and load test before pushing to production.
   • I had been testing on staging for about a week, on a low-powered server, with at most 5 songs processing at once. Had I tested the site in staging with heavier load, and accounted for very unexpected amounts of traffic, I would have been much better prepared for the initial spike.
   • I had prototyped the site using SQLite and with client-side polling to deliver progress updates, as it was simplest to develop. As soon as the front page of the Wub Machine was getting 40 pageviews/sec, SQLite crumbled in production, and PHP started using a ridiculous amount of resources due to the constant polling. It wasn't until many days later that I had time to migrate the database to MySQL and patch the progress indicator to use long polling.
   • I had planned to spend the Monday testing the site with load from Twitter, before posting it to Reddit. Someone decided to post to Reddit before I had anticipated, and I wasn't prepared to make the required changes. A lot of songs failed processing, a lot of bandwidth was used needlessly, and a lot of exposure was wasted with a site too busy to remix songs.
3. Expect users to abuse features.
   • I built the site with the ability to link to individual remixes. I provided a disclaimer letting people know the links would die after an hour, figuring that anybody who wanted to share a remix would post it to SoundCloud, or at least download it. Not so. Hundreds of people started sending around links, essentially turning the Wub Machine into a very bandwidth-heavy temporary remix-sharing site. Had I removed this feature from the start, I would have caused a minor inconvenience to approximately 5% of users, while saving me a ton of bandwidth and hassle.
   • Later in the week, when 4chan's /mu/ discovered the site, I counted a couple hundred links to individual Wub Machine remixes in each threads. Obviously, 4chan is a more anonymous site, and very few people wanted to share via SoundCloud. I tried to lessen the impact of the links by forcing each remix to expire within 15 minutes, instead of 1 hour, which helped slightly. As soon as the traffic died down and the site dropped off of /mu/, I immediately disabled the link feature to save me bandwidth. (Had I disabled the feature while it was popular, I risked a backlash from 4chan... not something anybody wants. Ever.)
4. Buy more capacity than necessary.
   • I expected the Wub Machine to use a significant amount of bandwidth and tons of server load, but I could have still used more to deal with the unexpected spikes. I started by buying a Linode 512 to host the site, which worked for a while, then started to choke once it hit Reddit. That was quickly upgraded to a Linode 1024, which worked wonders for a while. 4chan drove a lot more traffic than expected, and after a week, I had used up 220GB of bandwidth.
   • After the initial traffic spike and exposure, I shut down my Linode, moved the site back to my Prgmr, and put an hourly limit on the number of songs that can be remixed. I'll probably still need to upgrade my server or increase its bandwidth next month. Who would have guessed that creating a cool web app costs money to keep running?
   • I also realized before even launching that making any money was a very slippery slope. I could have added Adsense to the site, and probably would have been able to recoup my server costs. However, I expected that if the site was ever seen by any record companies, making even one cent off of having people upload their music could be a massive legal liability. (Even though I delete uploads as soon as they're done remixing and don't keep remixes for more than 15 minutes, that wouldn't stop people from taking issue.) Besides, as long as I limit the capacity and keep the site on the VPS I already own, it costs me very little to run.

So, there you have it. Final first-week stats: 15,793 uniques, 46,062 pageviews, 1,950 Facebook likes, 273,640 story impressions on Facebook, 139 tweets and 8,808 songs remixed.

The Wub Machine's not dead, but it's slower, and during the first week, I learned a lot more than I'd ever expected to learn about scaling web services. Having a site go viral was quite an unexpected, thrilling, and crazy experience.

Permalink | Leave a comment  »

The Wub Machine was a great little auto-remixer project - some audio hackery in Python to make a neat script. Unfortunately, I can probably count on one hand the number of people who *actually* downloaded the script and tried it on their own songs. So, I decided to make it into a web app. (tl;dr: go try out the site now!) 

I opened up my trusty Photoshop, cranked out some multicoloured waves and set "The Wub Machine" in beautiful Proxima Nova. Then I set about the immense task of actually implementing the remixer on the web.

I'd go into the technical impressiveness of the system, and how it's brilliant and took me months to come up with... but it's really not. It's one big hack.

I ended up using:

• PHP to serve the front-end, as well as serve the AJAX progress updates and interface with SoundCloud
• Python to power and tie together all of the processing on the back-end
• the Echo Nest Remix API to do the heavy lifting, audio analysis and beat detection
• FFMPEG to decode & encode the MP3s
• Mutagen and PIL to rewrite the MP3's metadata, extract artwork, overlay a graphic and put it back in to the final MP3
• Beanstalkd to queue processing jobs and connect PHP to Python
• SQLite3 for logging and some queue intelligence
• HTML5 Audio, used for a beautiful HTML5 player (taken from the extremely impressive Neutron Creations blog)
• Flash for the fallback player on older browsers
• Javascript and jQuery to hold together the very rickety frontend
• CSS3 animations, for the moving waves at the top of the page
• the SoundCloud API for sharing tracks (without putting me at risk of nasty legal issues or pushing storage constraints)

I did have to make a couple changes to the original algorithm, though:

• I realized that audio volume is a nonlinear curve, so I had to account for that and create a new mixing algorithm. The volume of the original track vs. the wubwubs is now almost always about 50%.
• I went back into my dubstep template in Logic Pro and added different types of TransitionFX samples to the intro and the wubs - booms, splashes and such. Although I'm still not happy with certain parts of the template, it'll have to do for now. I'm not a dubstep producer - I'm a rock/metal/electronica/jazz guy. (for now!)
• I made the algorithm as deterministic as possible. The remixer is essentially a function (depending on the analysis I get back from the Echo Nest) so if you put in the same song, you should get the exact same remix.
• I improved the loudness calculation algorithms, fixed some stupidly-inefficient bugs, killed off a statistically-improbable-but-still-possible infinite loop, added logging, error handling, and progress indicators.

Since my blog post about the initial hack, it's taken me 3 weeks to assemble this web front end. That said, there's probably still tons of bugs - it only accepts MP3s at the moment, and it's probably somewhat unstable. If I push it too hard, or post it to Reddit or Hacker News, my shiny new Linode will probably spontaneously combust. Be gentle!

Go try out the Wub Machine, share your tracks on SoundCloud, and enjoy!

Permalink | Leave a comment  »

UPDATE: I turned the Wub Machine into a website. Go and remix your own tracks!

I like dubstep.

There, I said it!

That massive bassline, two-step beat and killer rhythm has some odd allure that I can't resist - and I'm typically a fan of rock, metal and prog!

I'm also a huge fan of the Echo Nest and their brilliant Remix API. In their words, the Remix API is an "internet synthesizer" - quite true. I can send off an mp3, and get back extremely detailed beat, timbre and pitch information within seconds. Some people have already used this to make any song swing, put a donk on any song, and much, much more.

For the first SE Hack Day, I decided to use the Remix API to automagically add dubstep to any song.

The Wub Machine by Peter Sobot

Now, as you may be able to tell from the samples above, this isn't quite ready yet. In fact, it's extremely rough. Even the code looks horrifically ugly. (And yes, you can download it, fork it, and edit it freely - it's open sourced on GitHub.) I have a lot of work left to make the results sound passable.

Technically, I'm not really doing anything too complicated:

• I used Logic Pro and Native Instruments' new Reaktor synth to make some dirty, dirty wub basslines at the proper dubstep tempo (140 bpm) and mangled my own kick and snare samples. I then rendered 8 bars of this pattern, in two different variants, in every key of one octave.
• Using Python and the Echo Nest Remix API, I get an analysis of each track's bars, beats, pitches, timbres and more. I still need to make some better use of this information, as right now, a lot of songs end up being detected and used improperly. (an 8th or 16th note off, ruining the beat)
• Using the Echo Nest Remix API's Dirac time-stretching abilities, I take the input song, bar-by-bar, and alter the tempo to be exactly 140bpm. Then, for each "section" of the song (as defined by, again, the API's analysis) I do 16 bars of dubstep with a repeating 8-bar pattern of either beats, bars or tatums (notes) from the original song.
• For the dubstep backing, I take whatever key the API tells me the song is in, and just choose the corresponding backing file from the ones I've prerendered.
• For the intro, I have a pre-rendered intro with some noise sweeps. I then use a bit of brute-force audio manipulation to play a build-up pattern before the initial "drop" after 8 bars.

I'm taking a ton of suggestions on how to improve the script - adding variables for time till drop, allowing overrides if the API mis-identifies the key or tempo, and allowing a different choice of beat, bar or tatum for sampling the original song. There's obviously tons of work left to do, and I plan to improve it whenever I get the chance.

Let me know what you think below in the comments, leave some suggestions, and check out the code on GitHub if you're interested!

UPDATE: I built a web interface and a very nice-looking site around the basic algorithm. Go and remix your own tracks!

P.S: When I said I like dubstep, I meant I really do like dubstep. When I'm not making my own music, I also enjoy drumming to dubstep:

Permalink | Leave a comment  »

I produce a lot of music.

I don't necessarily release a lot of it (or finish all of it) but I have at least 100 songs I consider developed enough to listen to, and about 300 other song files that are just riffs, beats and vocal ideas floating alone.

With so many files, projects, songs, sounds, and work in one place, I've developed musical workflow that borrows a lot from software development patterns. My music tends to be produced in stages and cycles.

I'll usually start with an idea from noodling around on some instruments, then do two things:

1. Record (track) instruments with the main riffs of the song or basic chord structure.
2. Record a basic drum loop and bass loop, then arrange to fit song structure.

Then, I don't do anything.

For any length of time between a day and a month, I usually don't touch the song-in-progress. The song needs a break, while I can forget about whatever ideas I had while writing the initial sections of the song.

Then, I'll come back to it, add some more riffs, ideas, melody, direction, possibly a scratch vocal track. Then the real fun begins.

1. Re-record any parts with mistakes or even rhythm that's slightly off.
2. Add whatever new sections, parts, instruments, riffs, or notes that need to be added.
3. Make updates, edits and changes written down from previous listens.
4. Bounce to disk.
5. Place .flac in Dropbox for remote listening and burn to CD for in-car auditioning.
6. Make comments on SoundCloud/Evernote on each track.
7. See step 1.

This process continues until I find it extremely hard to find changes to make to a track, or until I've reached the self-imposed deadline and am happy with the track.

In an ideal world, I wouldn't need to burn CDs for the car - I could plug in my phone and have it stream the latest version of the song from SoundCloud with no user intervention. (very similar to "nightlies" in the open-source programming world.) I could listen at work, make comments (that would get synced back into Logic), listen on my phone, make comments, send the links to others, get their feedback, and have this all happen with one utility.

(just to round out the post with some audio, here's one of my SoundCloud tracks.)

Cupcakes by Peter Sobot

Unfortunately, if I continue writing this script at the moment, I won't have any time to finish the album the tool would be created for. Once I've released my next album, (ETA: May 2011) I'll be open-sourcing some cool tools to make such a workflow easy.

Permalink | Leave a comment  »

14_Level_Up!.mp3 Listen on Posterous

This is my text message sound: "Level Up," sampled from Pokémon Blue on a GameBoy Colour. Short, geeky, and perfect enough to be heard every time I get a text.

However, Apple has decided that while users can set their own ringtones for their iPhones in iTunes, the text message notification sounds are off limits. I wouldn't take that answer.

Important note: This is intended to be a technical guide, not a tutorial for average users. Unless you're comfortable with SSH, you might want to be very careful trying this. This was tested on an iPhone 4, running jailbroken iOS 4.2.1, but should work on any (jailbroken) iPhone. Even experienced users should remember to always backup important files before you edit them. If you accidentally corrupt a .plist or .strings file - at best, part of an app won't work. At worst, your phone (or SpringBoard) will no longer boot.

I jumped into the filesystem of my iPhone, did some sleuthing, and found the first important path to look at:

/System/Library/Audio/UISounds

Here, you can find all of the text message sounds available on your device, in Apple's ".caf" format. (This is just .aiff, with the option of custom metadata, if I remember correctly.) All of these ringtones are encoded as Linear PCM, 16-bit, big-endian signed integer, in mono at 44.1kHz. Any text tone you create should optimally follow these guidelines. There seems to be no severe filesize limit - many of the built-in tones are more than 500kb. I try to keep mine under 100kb, but it honestly doesn't matter too much.

Now, the second important path to look at is the one where the names of the text messages are stored:

/System/Library/Frameworks/AddressBookUI.framework/

Here you can find all of the important .plist (or .strings) files that define which text message sounds are available, and what each sound is called in different languages. Although the names and availabilities are found here, it would seem that the file paths are compiled into a large binary file. (System/Library/Caches/com.apple.dyld/dyld_shared_cache_armv7) This makes adding completely new text tones alongside the existing ones very difficult - too difficult for me to bother with.

However, you can easily replace an existing sound file ("Ladder.caf" in my case) with your own text tone, and then rename the proper string (using a text editor, or Property List Editor on Mac) in:

System/Library/Frameworks/AddressBookUI.framework/<yourlanguagehere>.lproj/AB.strings

(Note: this .strings file is really just an Apple .plist file in disguise. Property List Editor will edit it properly once you change the file extension.)

Restart SpringBoard by either rebooting your device, or (more safely) by running "killall -HUP SpringBoard" from an SSH terminal.

Go into Settings > Sounds > Text Tone on your iPhone, and you should now find your new text tone in the list, named properly and all.

Permalink | Leave a comment  »

As soon as I got my shiny new iPhone about six months ago, I set up instant Push email. This remarkably useful feature has really changed the way I use my email accounts and respond to email. It's also made me reflect on exactly how dynamic and instant the web has become.

A lot of people wouldn't expect that posting a YouTube comment like this:

...would cause the device in my pocket (or on my nightstand) to vibrate and alert me instantly. This wasn't even something I had to go out of my way to set up - YouTube's default email notification settings accomplished this.

Responding to a tweet, commenting on Facebook, or any other number of nearly-instinctive online actions people do nowadays all cause unexpected side-effects: vibrating phones. It's not a bad thing, nor is it even that annoying. (yet) Just somewhat mind-blowing that the click of a mouse on one side of the world will (near-)instantly cause a device in my pocket to vibrate and alert me.

And I still think the world could and should be more connected.

Permalink | Leave a comment  »

My second year of University has been wildly more productive and interesting than my first, by far. First year taught me how to try to pass exams, while second year gave me material I wanted to know, bypassing the need for a lot of pointless memorization. But it's been more than that. Some things have become second nature now, completely. I've acquired new skills that I feel like I've always had.

From school:

• I built a compiler (from a subset of C to a subset of MIPS machine language) that taught me the basics of how all compilers work.
• I hand-wrote 1000 lines each of MIPS and Motorola 68000 assembly language, and I now feel like C is too high-level.
• I learned exactly how circuits and magnetics work, which is oddly more relevant to guitars, audio equipment and synthesis than computers.
• I learned how to interpret statistics and run unbiased studies.
• I learned how to mathematically prove that a piece of code should do something.

From a measly four months of school, I feel like I've matured years and learned much more than I should.

But wait, there's so much more!

• I redesigned, compressed, minified and beautified my own homepage.
• I started living more and more online - using Twitter, Last.fm, Posterous, Evernote, Soundcloud and countless other online services to provide me with a ridiculous amount of instant information wherever I am. (Having the web on my iPhone helps a lot too.)
• I became a proud vim and git user.
• I've linked up and consolidated my online emails and notification accounts such that if anybody wants to get in touch, I know instantly. (thank you, push on iPhone!)
• I learned best coding practices and have open-sourced a handful of useful projects so far.
• I've had more than 11,000 plays of my songs on bandcamp, with more than 600 album downloads.
• Learned to cook. (Somewhat.)

Next term, I've got a handful of coding projects lined up, but my one goal is to write and release a new album by May. This will be fun.

Permalink | Leave a comment  »

I have a lot of media on my laptop. Roughly 140GB of music, 40GB of photos, 40GB of games, video and other random stuff on my internal drive alone.

I foolishly missed an amazing deal on an SSD from Newegg.ca, so I went and bought an 80GB Intel X25-M from Future Shop instead. I then checked out eBay and bought a $20 hard drive "enclosure" of sorts. All I really needed was the proper connector, to bridge proper SATA to the odd variant of SATA (mini-SATA?) that the Macbook and most other laptops use internally for drive connections. I could have bought a cheap $1 connector for this, but the included enclosure holds the drive securely and prevents... bad things from happening. I think. (and hope.) Note: the adapter didn't come with the little ribbon cable you see on top in the photo. That was from the previous DVD drive in the Macbook.

The adapter I found fits tightly into the space that the old DVD drive took up, and is missing one screw at the back unfortunately. A bit of an odd fit, but with the case on, everything is snug and nothing is under stress. (I don't think so, at least...)

Now, onto the software and speed aspect.

With two drives, even without an SSD, you can easily partition my system files and media. In preparation for my purchase of the SSD, I had moved all of my music, photos and movies and other large files to my secondary (non-boot) drive, and linked them all from their locations. To identify some of the largest files on my hard drive that I wanted to move, I used the wonderful Mac app GrandPerspective.

I tried using Finder's aliases to keep file links from my home folder to my new drive, but a lot of software doesn't follow them properly, for some odd reason. I then turned to the good old Terminal, and ran the ln command for every folder I wanted to relocate. After moving, say, ~/Music to my secondary drive and deleting the original, I would run:

ln -s /Volumes/Fry\ HD/Music ~/Music

Now, most of this is unnecessary - I could have just as easily gone into iTunes, gone to Preferences > Advanced > Media Folder Location and changed it from there, but I wanted to keep things as consistent as possible. A handful of other programs though, like Steam, or some music software, have huge files that you can't just change a preference for. I ended up having to go through my /Library/Application Support and /Library/Audio folders to move over all of the huge sample packs I use. If you're not sure about the syntax of the ln command, it's pretty simple:

ln -s /absolute/path/to/new/location /old/location

In experimenting with all of this, I opened iTunes several times to be faced with an empty library. The urge to panic in that situation is hard to resist, but the files are just misplaced somewhere on the drive, and it's easy to relocate them or link them for iTunes to find again.

A couple caveats of this solution:

• My Time Machine backups had to be completely redone. The system didn't notice that the files I moved were the same files and folder structure but in different places. Time Machine proceeded to take an absurd amount of time to backup about 300GB of content all over again. Not a big deal, but some old backups were pushed off of the backup drive.
• Little Snitch (an awesome firewall utility) forgot all of its preferences. That seems to happen whenever I swap drives...
• I had to mess around with the pmset command to get some better battery life. The Intel SSD uses next to no power when running, so I configured my power settings to sleep the regular hard drive after only one minute of inactivity when running on battery. That way, I get an extra half hour or so of battery life at least.
• As I set the hard drive to sleep after one minute, if I'm working solely off of the SSD, I have to wait a couple seconds for the regular drive to spin up if I open iTunes or try to access files on it. A worthwhile tradeoff, in my opinion.

After running this setup for a couple days so far, everything looks great. I'm sure it helps that my secondary drive is already a Seagate Momentus Hybrid drive (with 4GB of SSD-like cache) but everything is ridiculously fast. Apps are up and running from the dock before they have the chance to bounce once. Booting the machine, which I don't do often anyways, is down to about 5 seconds. The slowest part of the boot process is waiting for my secondary drive to spin up. I decided to force verbose boot all the time (by running sudo nvram boot-args="-v") to see exactly how fast the system was booting, and it's ridiculous.

Of course, I can't read DVDs now. Oh well, big deal...

Please note: if you're going to try this,

BACK EVERYTHING UP FIRST.

I AM NOT AT ALL LIABLE IF YOU SCREW UP YOUR LAPTOP OR LOSE DATA.

TL;DR: SSDs are fast. I put one in my Macbook in place of the CD drive. Awesomeness ensued.

Permalink | Leave a comment  »

OhLife is a brilliant site that emails you nightly and lets you keep a journal through email. I've been using the site for many months now, and it's been immensely useful in spurring me to keep a journal. Not that I've read over the entries yet, but when I have a free moment, it'd be interesting to reflect.

As awesome as this service is (and it really is), I slowly realized there's no need for me to email all of my journal entries to a third party. With a physical journal, you'd probably keep it very private, and not leave it with anybody at any time - why not do the same for a digital journal? To keep the same functionality though, I still wanted an online, email-based solution.

Enter OhJournal. (Yes, the name is a blatant ripoff of OhLife. Shush, you.)

By putting a 20-odd line PHP script on a cronjob every day at 8pm and a simple Gmail filter, I can replicate the basic functionality of OhLife without using a third party.

Every day at 8pm, my server automatically sends me an email reminding me to write a journal entry. The reply-to field is automatically filled with my Gmail address, but with a tag on the end, so my response gets caught by Gmail's filter and goes into the proper folder, properly labelled. It's a very simple system, really.

As is my style lately, the source code is available on github. Feel free to download it and set it up yourself - but be careful to change the email addresses! I don't want to be receiving anybody's errant journal entries...

Permalink | Leave a comment  »

If you have a personal website, and you use Twitter, there's a chance you already have a Twitter widget embedded in your site. Most people will opt for the default Twitter-provided (Javascript-based) widget, which does its job well, is relatively customizable, and is very easy to implement.

However, some people (like myself) are stubborn and would rather come up with their own custom solution that allows for complete customization. I wrote my own basic Twitter feed widget in PHP for the latest rendition of my homepage.

This custom widget has complete PHP and CSS-based control over how you display the latest tweet. It fits the content into the exact dimensions you want, with a bare minimum of content, so you can style it exactly how you want. I've also set it up to automatically grab the geolocation data from the tweet, or to fall back to the client used to tweet if there's no geotag. You can also (by default) filter the latest tweets selectively - I've chosen to omit @replies and re-tweets, as personally, I'd rather have my own original tweets displayed prominently on my site.

I've made this widget open-source - download it from github if you'd like. You're free to use it wherever you want. There's only one PHP file to import, and only one function to call. It makes use of PHP's built-in SimpleXML module, to parse through Twitter's live RSS feed of your own tweets and extract the first one that's not an @reply or retweet.

Some future plans for the code:

• Allow for local caching to reduce fetching from Twitter's rss feed
• Find some way to allow for private twitter feeds (using their API perhaps?)
• Offer a more flexible div structure
• Add the Javascript necessary to load the widget with an Ajax request

In addition, if anybody uses Last.fm and is interested in having a similar widget for last song scrobbled, I've created and open-sourced such a widget, also available for download from github. However, this widget requires an API key, so you'll need to sign up for an API account if you'd like to use it.

If you've got any comments or suggestions, feel free to leave a comment below. 

Permalink | Leave a comment  »

What colour is the internet?

This is a very difficult question to even ask - what does colour mean? How does one measure the colour of a web page? How do you quantify and categorize the results?

For an upcoming class project (for STAT 206, to be precise,) @amtinits and I are trying to find the colour of the most successful websites on the web. Using the Alexa website rankings and some custom python hackery, we're finding the average colour of a random sampling of 1,000 websites from the top hundred thousand sites online.

We're making heavy use of the wonderful webkit2png python library and using the extremely helpful pypng as the heart of our image manipulation scripts.

We're then comparing the popularity of the site with its hue, as given by the Alexa ranking index and a simple calculation from its average colour value. Then we do some statistical magics, push some buttons, graph some pretty scatter plots, and see if there's any meaning to the data.

At the moment, we've got the scripts running full-time on my server, gathering and processing data slowly. After the data is collected, the report is written (that part won't be made public) and the marks come back, we want to write a nice front-end with some more options, a database, some crazy amounts of processing, and... do... something with it. (Is this even remotely monetizable? Who cares!)

Until the "app" eventually gets launched, you can view the results of the script in real-time at http://colour.petersobot.com/100k/ .

The real-time results of the script can be viewed at http://colour.petersobot.com/100k/output.csv. The script was run for a little while on the top one-million site dataset, but this list had too many malware/spam sites in it. This short list of results can be found at http://colour.petersobot.com/1m/output.csv.

Permalink | Leave a comment  »

But that's basic math - stuff we all learn in high school. What about a more complex function?

Permalink | Leave a comment  »

I've started tweeting again. This kinda surprised me, yes, but... when starting to micro-blog again, I decided I'd like to have a spot to post some longer (but still very random) thoughts. Yes, I do have those sometimes.

I could have spent a week coding a nice hand-made blog system in PHP, or a couple hours to properly set up WordPress and a nice custom theme... or 5 minutes to set up this posterous account. Which comes with a boatload of social media integration... this is a very, very nice system. Wonder how long it'll be until they get bought out by Google...

Permalink | Leave a comment  »