Building Vibechek, a Raspberry Pi-device to search nightlife by music in real-time

August 2024

image

After several outings with bad music in 2021, I tried making nightlife music searchable by building a raspberry pi device that identifies songs and door-to-door distributing it to popular bars.

How it started: my wife and I were on a rare dinner date while my parents were in town (we have a 2yo + newborn).

On these nights we typically try to cap things off with some house music for nostalgia’s sake.

Unfortunately, we're not active enough to know which spots are good anymore -- so more often than not, the chosen venue fails to deliver.

A bad soundtrack is always devastating, even more so when it's your only night in six months.

After a few such nights circa 2021, I thought:

why can't we search for places by music genre like we search for restaurants on yelp?

Brainstorming

In theory if we had cameras in every venue, we could just "check the vibe" of places and pick where we want to go. The information is technically easy to create, and there are even apps that do this at small-scale already like BarGlance and VibeSpot.

But I wanted to go further than just a video feed -- I wanted to type in my preferred genre of music, and see which venues were:

  • currently playing music I'd like
  • historically played such music
  • or were likely to play it at a certain point

Going to restaurants today without checking reviews is almost a ridiculous concept. In 2021 I thought nightlife should be similar. I want to land in a new city, type in "hip hop" or "jazz" and be presented with the best options for that exact moment.

Interviewing potential users

While I wanted this for personal use, I interviewed friends just to sanity check. It turned out people were already trying to do this by searching reviews of places to "check the vibe" before heading out. In particular, local information was sought out -- Instagram, insta stories of recent videos, Google reviews, etc.

Another interesting discovery was why people went out:

For me, music was the biggest determinant. For others, crowd type was a factor -- e.g. was it hipsters, finance bros, burners, country, etc.

For most people interviewed, their venue choice was 70% decided by music and 30% by crowd type. The rest were about 50/50 music and crowd -- this also depended on the "type" of night they wanted to have.

My friends were also less interested in listening to the audio of a place in real-time, and said they'd prefer to see the last 5-6 played songs to get a general sense of vibe or spot trends.

Worth noting that my friend group skews towards musically inclined, lots of DJs and concert-goers.

Alright so it seems like this is info that would be useful for others besides me, the next question was could we get the data?

Getting the data

Really all we needed was to run Shazam every minute in an area with music, identify the song, and upload it to a server.

I figured there were two ways:

  1. Waze-style crowdsourcing
  2. Get the venue to send us data through a device

Coincidentally Apple had newly released ShazamKit following their acquisition of Shazam, the music identification service. So the ability to make a crowdsourcing app was possible for the first time without resorting to an unofficial API.

But the crowdsourcing approach required solving the "cold start" problem and needing people to be in locations and incentivized to record somehow, likely leading to sporadic and inconsistent coverage.

Alternatively, with venue buy-in, I could convince venues to leave my app running, sending song IDs to us every minute throughout the day.

Having recently seen some success with our B2B recruiting firm, the idea of selling to businesses seemed approachable to me, and I figured it'd be more useful to have the full picture of a smaller number of venues than a sporadic picture of more. Plus I thought there was more incentive for the businesses (e.g. could act as free marketing to bring in more business).

So I opted for the venue buy-in route.

The goal was to make it as low friction as possible for the venues, which to me meant having a device they could just plug in, without having to deal with wifi connections.

The idea of buying phones for everyone seemed expensive (probably untrue in hindsight), and I worried they'd get stolen -- so I envisioned building a cheap SIM-card device using Raspberry Pis + 3D printing.

I'd never built something like this before, but knew I'd need an enclosure, SIM card, microphone, and raspberry pi along with an API endpoint to receive the data.

Proof of Concept

I started by building a quick software proof-of-concept.

First I needed a way to identify songs, which led me to this excellent Github library (https://github.com/marin-m/SongRec) that implemented Shazam's spectrogram creation algorithm manually so we could leverage it's endpoints.

While I did have to modify some of the code and tweak it to work with raspberry pi's sound card, years of digital signal processing work to hack drones at Skysafe made this much less intimidating -- as it was mostly the same concepts but with airwaves instead of radio frequencies.

Ran a quick test and it worked.

We now had the ability to ID songs using a raspberry pi + microphone.

Next step was making the website to display.

I bought the domain vibechek.io, kicked off a design competition on 99designs, and spun up a website on AWS.

For the API, I used API Gateway + Lambda and dumped everything into Amazon RDS.

Our API request would be simple, just basic song info, timestamp, and a device ID to differentiate which venue to associate the tag with (figured I'd bump my friends Syence play counts for the test music):

{
    "song": "We Won't Leave You",
    "artist": "Syence",
    "genre": "Bass Pop",
    "device_id": "rabbit-firehouse-sd",
    "detection_timestamp": "2021-08-11T19:07:00+0000"
}

And then our website would just display this data in a simple table. After a few logo iterations and feedback from friends, I ordered our business cards from GotPrint (for our door-to-door outreach) and threw up the following app website:

image

Alright so we had the ability to ID songs, and a place to send and display the data, now we just needed to create the devices.

Building the device

The device was simple enough, a raspberry pi with a USB microphone and USB modem + SIM card for data.

Being a hardware design novice I messaged my friend Tanner at CleanRobotics for advice, who suggested using Soracom for SIMs and Balena for device management.

Supplies were still out of stock from the Covid supply chain crunch at this time so I bought 4 Raspberry Pis for $105 from BestBuy, as well as some USB microphones and ZTE USB modems.

After downloading a Fusion360 trial and watching a tutorial, I designed a basic enclosure with some sweet Vibechek lettering and started printing on my Ender 3 3D printer.

image
image
image

It took a few iterations as I learned the basics of 3D printing and made some rookie mistakes.

  1. First iteration: forgot to add supports.
  2. Second iteration: forgot to account for the modem
  3. Third iteration: forgot to account for SIM card itself, ffs. Case was 2.5mm too short.

Fourth iteration: it works 🙌

image
image

I tested our fully-enclosed device with a power hour playlist (ty college).

image

Success!

Provisioning + Production

While the enclosures were printing, I worked on a process for provisioning the modems and raspberry pis efficiently. A lot of monotonous terminal setup, testing, and documentation went into these steps for which I'll spare you the details.

To manage the fleet we used Balena, which gave us the ability to remote upgrade and manage things from a dashboard after dockerizing our code to work with their system.

Overall I was a big fan of Balena, really cool service I hope to use again in the future.

I'd set a deadline of Thursday morning, which was when I wanted to take the devices, go door-to-door to our favorite venues, and get a device plugged in so we could start collecting data before the weekend hit (and have a fun time 'testing' the search function).

At 2:04am on Thursday morning, I was finally done. Had 2 devices built, provisioned with balena, integration tested, drilled holes for the microphone, added heatsinks, glued cases together, and verified everything worked.

image
image
image

Here's what the website looked like after running two devices for some period:

image

I ran through the installation process a couple times just using a phone, and packed velcro, business cards, zip-ties, and anything else I could possibly need the next morning like extra power cables.

image

The Pitch

In parallel to the building, I was working on our pitch to bars. At this point we were several months into a fairly lucrative recruiting niche, so while I had some basic experience crafting a successful pitch, I was far from a good salesman at the time. [1]

We were approaching the go-to weekend bars in Pacific Beach, San Diego -- the ones we thought this would be most useful in like Backyard, Firehouse, etc.

Our pitch:

"We've built a service that drives people to bars by showing what music they're playing, so we're going around to our favorite bars and seeing who'd like to be a free beta customer? How does it sound?"

The goal here was:

  1. Frame it in their best interest and show the value prop ("drives people to bars")
  2. Game theory, let them know we're offering to competitors ("we're going around to all... bars")
  3. A bit of flattery ("our favorite bars")

We also wanted to work in some scarcity ("only taking two beta testers who wouldn't mind the free advertising at the moment") and let them know it was free right off the bat. [2]

Selling

Thursday morning, I went out to Pacific Beach (with Emma for moral support) armed with my backpack of devices + business cards.

And proceeded to get rejected by everyone.

Firehouse said they had to run it by their entertainment group.

At Shore Club I made a mistake of trying to use a bouncer for an intro, he got confused and then acted as a skeptical anti-champion to the GM, who rejected us immediately.

The manager at Mavericks was cool, he explained how they're entertainment ran through Sleeping Giant and said they'd think about it (just being polite I think).

The manager at The Local was also pretty friendly and seemed interested, though he admitted we'd need some social proof.

Baja just didn't want to spend the time.

We actually managed to get an afternoon meeting scheduled with the Backyard GM, so after approaching the other bars I went home and practiced my pitch for a few hours.

image

Unfortunately when I showed up, we were told the GM had changed his mind.

This is me eating ice cream after a day of rejection.

image

Thankfully my wife is great at boosting morale.

image

Conclusion

Despite the outcome, it was actually a pretty fruitful day.

I'd learned who to involve and who to avoid when trying to access the GM.

And after rejecting us the second time, Backyard showed that our value prop for bars wasn't as good as we thought -- explaining that attracting new business just wasn't a problem they faced (which is true, most nights they had a line out the door).

So we either needed:

  1. a more attractive proposition to incentivize bars
  2. or just needed to bypass them entirely

I later called a VC friend of mine to get her thoughts and she confirmed, bypassing the venues entirely would make the idea much more attractive from an investment standpoint.

Other mistakes we made/reasons we didn't make sales:

  • I was a bad salesman (I'm much less awkward now)
  • asking the wrong people for intros (best intros came from the bartenders)
  • when someone asked if our device was a speaker I said it was a "microphone" -- big mistake
  • when someone asked if it was new, I said "I finished it last night at 2am" -- another gaffe
  • not leveraging scheduled meetings with other bars as social proof

But overall, I learned to design and prototype a physical product (which worked quite well in testing) while invalidating the direction before spending too much time on it (only a week or so).

My next steps were:

  • shadow my friends having success selling point-of-sale systems to bars around town to learn their approach
  • create an app that makes crowdsourcing dead simple
  • brainstorm ways of incentivizing users to ID songs
  • brainstorm ways of extracting the audio information without needing to be physically inside a venue

Unfortunately, the birth of our son meant I had to de-prioritize this and focus on building our other company -- so Vibechek took a backseat (though friends have told me there are some new upstarts tackling this problem).

If you’re interested in more write-ups like this you can follow me on Twitter or sign-up to get these emailed out from the main page 👍

Footnotes

[1] Although I wrote the scripts, my wife, being the far more charismatic of us two, did majority of the sales calls/recruiting at the time. Things would likely go a lot better if we attempted this now.

[2] Advice I'd received from Justin & Danilov, two Australian friends that had a lot of success door-to-door signing restaurants up to a messaging app we'd worked for in Sydney