In 1.0.4 we added some pretty robust crash analytics to Hum. We’ve had a few growing pains that have come in the form of crashers, but we’re working really hard to get some fixes out the door.
Today we’ve released 1.0.5, which fixes a number of crashes stemming from the same bug. When you put Hum in the background while working on a song, Hum could lose track of if a song existed or not and cause a crash. Frustrating.
We’ve added a whole settings panel for when we ship Dropbox syncing (it’s coming!).
In the meantime we’ve had a few crashers pop up and we’re doing our best to get rid of them. Growing pains! This release will automatically send us usage statistics to help us figure out where some of them are. If you’d like to opt out tap the settings button at the lower right of your library and flip the “Usage Statistics” switch. We’ll be collecting anonymous data like how many Hums y’all are recording. How often you use the app. How long your average song is, stuff like that. Again, you can turn it off in two taps.
You can also kill the recording countdown if that was bugging you. Personally, I’ve always needed about 4 seconds to get situated, to set my phone on my knee, get my dogs to stop barking, etc. If you don’t need it, flip the switch.
You can also prefer sharps or flats now when specifying keys and tunings. We originally included a nice natural mix. I prefer calling certain notes C# but also refer to others as Bb. Now you can prefer either.
If you get stuck we’ve added a help section. You can call (for real, it’s just my phone number), email, or tweet at us. If you’re ever having a problem we want to hear about it. It’s the only way we can improve Hum.
We’ve also added a translation in Portuguese. If something doesn’t look right there let us know. Same goes for our Swedish translation.
As always, have a look at the detailed release notes. We’ll keep chasing those crashers and getting Hum to be as stable as possible. Look for a 1.0.5 very soon.
As far as minor updates goes, this one is pretty significant. We added a few little usability improvements that really add up. On top of that, we fixed a bunch of little bugs that you can always find detailed on our releases page.
We got rid of the confirm / dismiss screen every time you record something. Now it just accepts the recording automatically. Our initial assumption was that if you blew a chord, it’d get you into a new recording quicker. We ended up creating a barrier to capturing ideas by doing so, so we stripped it. We’d rather any friction in our app to be during deletion, not creation.
Sliders now have tick marks that allow you to be a little more precise. It gives you some context for sliding. This control is something we’d like to open source, so keep your eyes open for something like that after we add our Dropbox support.
Thanks to Peter Steinberger and his wonderful PSPDFTextView library, we’ve improved our Lyrics & Notes fields. Your text cursor will no longer be hidden underneath the keyboard if you’re at the last line of your lyrics or notes.
You’ll also notice that the lyrics field is now called “Title & Lyrics”. A surprising (to us, anyway) amount of users weren’t discovering that the first line you typed in the lyrics field became the title of your Hum. Again, in regards to friction, we don’t want to have to show any dialogs like “Give your Hum a title”. It’d only get in the way of capturing an idea. We really think this is the best way to title something. Just write. Hopefully this will help our users discover that.
Oh, and to all our Swedish users, who we were shocked were so many, we’ve added a translation for you. If you’re a multilingual musician and want to help translate Hum, please email me!
For all those users that are running iOS7.1 betas, pay close attention to these updates. We don’t officially support beta operating systems, but have a gander. Some annoyances should now be fixed for you.
Hum began as a shared problem between myself and Joseph. We were tired of losing song ideas to voice memos and voicemails. We met at small design agency in Minneapolis called Sevnthsin. We kept in touch over the years, even while I was in San Francisco working for Adobe. We’d usually just critique whatever we were working on at the time, or talk shit about Jamey Erickson.
We interviewed our songwriter friends about their process and found it was incredibly similar to what we had going on. We’d play a bit on the guitar or piano, whatever our instrument of choice was. We’d stumble across a riff or progression that we’d want to remember or build on. We’d open our iPhone to Voice Memos and record about a minute or two. If it was really solid we’d email it to ourselves or text to bandmates.
The problem is once ideas are in a voice memo, they’re often lost. You can’t sort them. They’re hard to revisit. Names are based on the date they were recorded. You have no idea what key they’re in or how your guitar was tuned.
Meanwhile, lyrics are written at the time of inspiration—sitting on a bus, waiting in the airport, watching a show. They’re collected as Notes. They exist between shopping lists and todos. The context for these works are lost. You can’t assign audio memos to the lyrics.
So you press record in Voice Memos, switch over to Notes, sing the lyrics while strumming the guitar. Trim and share. This could be simplified. I got to sketching.
I moved quickly to Photoshop. Originally, Hum was designed to be built for iOS6. It featured an “almost flat” look featuring buttons with very obvious shadows and structure, almost as if it was a physical device.
Shortly after our designs, iOS7 was announced. I wasn’t thrilled. On top of a jarring, new aesthetic, the iOS7 music app looked pretty similar to our red, early versions of Hum.
The teal was originally meant to be a secondary color we could use for branding and illustration purposes. With the switch to iOS7, we rolled with it as our primary color. We flattened some things out, taking cues from the only control in iOS with any shadow whatsoever—UISlider.
At this point I started hacking on early alpha versions of Hum. I opened up Xcode for one of the first times to build Hum from scratch. It was slow going, but I found things clicked for me when I built everything programmatically. For whatever reason, I just couldn’t ever wrap my head around Interface Builder. I had no working conceptual model for how things were built. I needed the control that building things programmatically offered. Hum would feature many custom transitions. I needed control over them all.
I signed up for a developer account at Apple. I downloaded all the code samples I could get my hands on. I headed to Amazon and got Hillegass’s Big Nerd Ranch Guide to Objective-C Programming. I was going to figure out how to use what could easily be the ugliest language this designer has ever seen.
And it worked out, for the most part, but I still very much needed help on the unsexy, “real” problems–audio recording, database & storage, things like that. I had a static front-end built in a few weeks, complete with transitions (and ugly code). We soon hired Ellen Shapiro to clean everything up and actually add some real functionality to it.
She’s great, and she occasionally takes on freelance stuff. You should hire her. Actually, don’t do that. We’d like all her free time to be spent on Hum.
If you’re a designer who’s afraid of Xcode, have a look at Meng To’s excellent post “Learning XCode 5 As a Designer“. It’s a good, practical starting point for all this nonsense.
After a lengthy beta process in the fall of 2013, Hum was released on January 27th, 2014. It’s been downloaded thousands of times, was featured by Apple as a Best New App, and also carries a 4.5 star rating.
Oh. We need your help to change songwriting forever. We have a strong road map and are actively looking for investors to help us take Hum full time. Get in touch.
It probably feels like we’ve spent months doing little more than writing blog posts, so I’ll keep this short: today, we released Hum on the App Store.
After months of pushing pixels and filing bug reports, Hum is ready, and we couldn’t be happier. We’re a three-person, self-funded team, but we’ve done our absolute best to build a beautiful app worthy of capturing and organizing your music and lyrics.
Our inboxes and Twitter feeds are always open, so please, tell us what you think. What’s working? What’s missing? More importantly, we’d love to hear what you’re making with our little app. Send us your songs, your raps, your anythings.
In the meantime, we’re heading back to the office to get that Dropbox syncing dialed. We won’t sleep until all those Hums are secured in the cloud, ours included.
Good news, everyone! Hum has been approved by Apple. It’ll be available on the App Store Monday, January 27. AND, for a limited time, it’ll only be $1.99.
Until then, we need help spreading the word. Help us tell everyone you know whose phone is filled with voice memos that there’s a better way to keep your riffs organized. Tell them that their lyrics no longer need to sit next to grocery lists and reminders. Post about us on Facebook. Tweet about us. Help us tell everyone about Hum. Tell your neighbor who won’t ever stop playing the guitar, or that guy who plays the flute while walking his dog. Tell hip-hoppers and indie rockers, jazz trios and djent guitarists. Tell ‘em all…please.
We’re very proud of Version 1.0. We’ve named it “Algiers” after Calexico’s latest effort. Their record was played incessantly during Hum’s development, and it’s really great. You can see the progress we took to get here by reading our release notes.
We don’t want to give away too much of our roadmap. I assure you we have big plans, but we’d rather delight and surprise when new features land in the app store.
That said, we don’t ever want you to lose any of your ideas. Ever. We can’t think of anything more heartbreaking than losing even a single idea.
Therefore, our next big feature will be enabling Dropbox syncing. It will be a free update. You’ll be able to plug in your Dropbox account and Hum will keep your library synced and backed up. That way, if your phone gets stolen or lost, you’ll always be able to restore your library from your copy on Dropbox.
Lastly, we’d like to tip our hats to our beta testers. You played a big part in making Hum great.
Do me a favor and load up the calendar app on iOS7. Now, at the bottom tap “Today”. Did the word “Today” highlight? No? Try it again. And again. Wait, it just worked? Press it again. I bet it didn’t work. It’s completely random, and depends on how quickly you press the button.
The same goes for any button in the bottom 50 or so pixels of the screen. As of iOS 7.0.4, both the back gesture and the one for bringing up the Control Center eat highlighted button states. Not only do we have borderless buttons by default, but only about 10% of the time do they have a highlighted state. This is a fundamental flaw in UX.
In Hum we took cues from the UISlider Control to create nice, tappable buttons. We have an obvious pressed or highlighted state as well. These states are important for UI feedback, if only to confirm that I did indeed press a button. These controls don’t need to be as obvious as we’ve designed for Hum, but it’s important that something happens.
So if the highlight events are being eaten by the back and control center gestures at an OS level, how am I supposed to give the user feedback that the button was even pressed?
We’ve found a pretty simple workaround for this. Instead of using standard properties like button.highlighted = YES or button.selected = YES that don’t work anyway in that bottom band, we simply fake a highlight by first delaying the final method that’s called on button press. Simply set the background image of the unhighlighted button to the highlighted state with an unperceived delay BEFORE we call the final method. It looks like this:
When creating our buttons we set two images for the button, one for normal, the other for highlighted. Pay attention to the image names.
We then tell the button to call an intermediary method that sets the unhighlighted button’s background to the highlighted state, faking the standard highlighting interaction that doesn’t work in that 50px space at the bottom of the screen. After a tiny, unperceived delay of .025 seconds we then call our real method and reset our button, if needed, to the original, unhighlighted state.
Now, regardless of how quickly the user taps the buttons within that bottom band they’ll receive the feedback that their button was pressed.
We’ve opened up Hum first to all our Kickstarter backers that contributed at the Beta level. Check your inboxes, y’all have got a fresh beta ready to be installed.
And to the rest of you, it’s not long now. We’ve gotta get feedback from our early testers to make sure Hum is as good and stable as it can be for a 1.0 release that’ll be distributed in the App Store.
Thank you for your patience. Remember, we’re a small, self-funded team. And, of course, we want everything to be great.
We’ve simplified mood and sound sorting. You can now drag a slider somewhere between happy and sad icons, allowing for more personalized categorization. This in combination with a slider between quiet and loud will offer some powerful categorization of your lyrics and melodies. The icons were kept vague enough that these sliders could represent all kinds of emotion and sound. The sound slider, for example, could be used as slow vs. fast in your library if you wanted.
Hum will be in your hands soon. Sit tight! You couldn’t be any more excited than we are!
TL;DR: We’re making Hum with traditional funding. It’s still coming soon.
22 days ago, we launched our Kickstarter to fund Hum, a modest songwriting app with much larger, long term ambitions attached to it—to change songwriting forever. Today, with a week left in our Kickstarter campaign, we’re pulling the plug and shifting our focus to more “traditional” forms of fundraising. Making this decision is on the one hand humbling and the other exciting.
A lot of things went right for us: we receive impassioned and enthusiastic responses from musicians across the globe; Forbes, Mashable, PSFK and a host of other blogs and online communities of all stripes gave Hum a nod; and, most importantly, we rallied nearly 400 supporters, something we will not soon forget and for which we will be forever grateful.
But even the most exquisitely planned ventures begin with their share of hiccups, so it goes without saying that we stumbled in a few places.
Walk, don’t run.
Hum excites us because, like you, we’re songwriters longing for better tools and a smarter process. That excitement pushed us to introduce Hum sooner rather than later. In doing so, we overlooked one very important thing: the national holiday sitting in the middle of our 30-day fundraising window. Our first 10 days brought an inspiring wave of pledges and energy. Then, just as suddenly, America went on holiday to celebrate its independence, understandably setting aside any concern for Kickstarter campaigns likes ours. Re-establishing buzz and energy for Hum proved difficult in the days after July 4th.
Regardless of whether or not the holiday was to blame, we walk away knowing that excitement should not get in the way of clear-headed planning, and were we to do it again, we’d rather not gamble a songwriting app against a week at the cabin.
A tool in the hand is worth two in the bush.
We didn’t begin this campaign with a beta version in our back pocket. Yet, almost unanimously, songwriters wanted to test out Hum before putting their name behind it – this was true for both everyday Joes and notable artists. It was our opinion that launching a Kickstarter with the tool pre-built would mean we were being dishonest with our backers. Doing so would have meant we didn’t truly need money to kickstart our project. In this case, idealism got in the way of wowing songwriters and building strong and influential partners. Trying to convince someone of the power of Hum is very different than putting that power in their hands directly and letting them experience it for themselves.
Asking for money and support, especially from those with little to spare, should always begin with honesty and transparency. However, the needs and concerns of songwriters should take precedence over the platforms one uses to engage them.
Big ideas that can’t be shared can’t be sold.
We’ve got big, big plans that will introduce a new dynamic to songwriting, and Hum is the foundation for that road map. The problem is, we don’t want to give away our plans for this larger vision. Keeping that vision a secret means we can’t get people like you excited about Hum’s future. This, in the end, is the main reason for shifting our focus to traditional funding. To be clear, while we’ve failed on Kickstarter we don’t think we’re pursuing an idea that will fail.
Nearly 400 of you have raised your hands and opened your pocketbooks in support of Hum. We can’t thank you enough for that. We’ll return that support and passion when we re-introduce Hum to the world.