A quick technical note that left us scratching our heads yesterday as we prepare Hum for delivery to the gigantophones:
Without specifying an iPhone 6 or 6+ launch image, iOS will simply scale your app up to fit the new screen sizes. It will look terrible, and you will cry. Especially since you spent all this time converting your app to use Auto Layout.
It’s easy to miss this requirement in Xcode, because your LaunchImage.xcassets file won’t show you the new drop targets automatically. The way we approached it was to create a new LaunchImage.xcassets and add launch images of proper resolution. Once you do so, your Auto Layout will kick in appropriately and all that work will actually get used.
For iPhone 6, you’ll need a launch image resolution of 750 × 1334. You’ll drop that in the Retina HD 4.7 bucket.
For iPhone 6+ you’ll need a launch image of 1242 ×2208 (which gets scaled down to 1080 × 1920). You’ll drop that in the Retina 5.5 bucket.
Our LaunchImage.xcassets file ended up looking like this.
Finally, if you’ve added a new .xcassets file for this, you’ll want to make sure that your app is pointing to it correctly.
Click on your project settings and make sure the App Icons and Launch Images section has the right source:
We’re excited to announce that 1.1 has been released. It’s been named after J Roddy Walston & The Business’s “Essential Tremors”. I don’t think I’ve had as good a first listen as I have with this record in a very long time. J Roddy straddles the line between Jerry Lee Lewis piano rock n’ roll, and Zeppelin inspired riffage, but puts it all together in a cohesive record. This was played pretty incessantly while making this latest round of features.
As always, head over to the release notes page for the nitty gritty.
Now that we’ve all got bigger libraries, we’ve added searching. You can pull down on the library view to reveal the search bar. You can dive right into a song if you type in some lyrics. Big time-saver.
Sorting’s been improved. Instead of oldest / newest, we now sort by “Last Created” or “Last Edited”. Sorting by “Last Edited” will ensure that all the latest songs you’ve worked on are bubbling to the top. Nothing against Oldest First, but no one was using it.
Hum would get really unstable with songs that were around 10 minutes in length. That’s always been our maximum recording length, but we’ve cleaned up things around the edges. We’ve also got a nicer experience when you’re deleting audio from a Hum. We’ve also customized our typeface to allow for true musical sharp symbols. On top of that, we fixed a lot of under-the-hood stuff in preparation for our Dropbox syncing release. It’s coming!
We wanted to take a tiny break from building Hum to feature some of the artists that are actually using it.
We’ve created a series called The Liner Notes that features songwriters of all genres talking about their craft.
We just posted our second episode. We’ve featured Savannah Smith. She’s a folky solo ukelele-based singer / songwriter. Though her lyrics are often dark with emotional depth, her music inherits the whimsey of her chosen instrument—a powerful juxtaposition. We followed Savannah while she was in the middle of successfully funding her first record on Pledge Music.
We’ve been busy working on the next major features for Hum. You’re going to love them. We’re just about to release Dropbox syncing support to our private beta testers. It’ll be in everyone’s hands once as we find and squash some bugs.
We’ve just recently added printing support to Hum. If you tap the share button you’ll see a print button next to the email and messages. To my surprise, it was actually quite easy.
Here is what our print method ended up looking like.
UIPrintInteractionController *controller = [UIPrintInteractionController sharedPrintController];
UIPrintPageRenderer *renderer = [[UIPrintPageRenderer alloc] init];
renderer.headerHeight = 40.0f; //Optically add padding to the top of the page.
renderer.footerHeight = 30.0f; //Add some padding on the footer as well.
controller.printPageRenderer = renderer;
UISimpleTextPrintFormatter *formatter = [[UISimpleTextPrintFormatter alloc] initWithText:self.song.lyrics];
controller.printFormatter = formatter;
formatter.font = [UIFont fontWithName:@"Whitney-Print" size:14.0f]; //Change the typeface and size of our text.
formatter.contentInsets = UIEdgeInsetsMake(0.0f, 30.0f, 0.0f, 30.0f); //Add some spacing on the left and right.
[renderer addPrintFormatter: formatter startingAtPageAtIndex: 0];
UIPrintInfo *printInfo = [UIPrintInfo printInfo];
printInfo.jobName = self.song.nameOrPlaceholder;
printInfo.outputType = UIPrintInfoOutputGrayscale;
controller.printInfo = printInfo;
controller.showsNumberOfCopies = YES; //Printing lyrics is usually for sharing in a rehearsal setting.
[controller presentAnimated:YES completionHandler:NULL];
But, as I’ve experienced with every simple feature in Cocoa, there’s always at least one ‘gotcha’. Here’s what I ran into:
1. Using custom fonts is easy, so long as you aren’t using an .otf. When using an .otf, it would print fine in the simulator, but as soon as there was any real printer output, iOS would fall back to the nearest typeface that worked. When I swapped an .otf for .ttf of our typeface, it worked just fine in both the simulator and real-life printing. I didn’t find this distinction in any of my googling.
2. Default page margins are way too close to the edge of the printed page. I thought that setting some contentInsets would handle it just fine, but no. By design, the print formatter doesn’t allow for a bottom inset. With a top inset it works great on the first page, but subsequent pages it’s ignored. I had to go with a mixed approach and build a renderer to add empty headers and footers for vertical padding, and insets for left and right spacing.
3. If you want leading / line-spacing that isn’t incredibly tight, you’ll need a workaround. I chose to open up our typeface and manually adjust its vertical metrics so I could fine-tune how spread apart those lines were. I exported a TTF with a custom name and metrics so I wouldn’t get them confused in our UI declarations. After some tweaking I found these lyrics to be much more legible than the defaults. I wasn’t able to find a way to change the leading in code alone.
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.