Category Archives: Development

sBASSdrum: Upcoming development

You have spoken. I am listening.

As sBASSdrum has largely been a side project, many features did not get implemented in the first release, nor the second. But know that your feedback on the iTunes App Store has not gone unnoticed! I’ll respond to a few of them:

  • Metronome / Pre-Record Count-In: Probably the #1 most requested feature, and I absolutely agree. I have been doing live recorded music for quite a while and even my tempo is not consistent! This is definitely slated for inclusion in an upcoming release. In fact, I have a number of ideas on a better metronome that isn’t just a “click” sound.
  • Saving Loops: There is no current way to save your loops and sometimes when you launch the app your current loop disappears. This is definitely a known issue.
  • Recording X/Y Pad: I hope to introduce X/Y pad automation recording! Actually, any “effect” ought to be automatable.
  • Importing Sounds: Absolutely. You are currently only able to use the built-in sounds but at some point your own sound fonts will be importable. After all, it’s backed by a PCM sampler!
  • Sound Exporting: There is no way to render out your sounds or loops unless you capture the audio with Audiobus. A planned feature is the “Flight Recorder” that will enable recording of a session. Possibly uploading direct to SoundCloud, out to iMovie, or other apps.
  • User-Definable Patches: Absolutely. Currently you are locked into the chord progressions that I’ve created
  • MIDI Support: All in good time.
  • iPhone Version: All in good time.

Things that were added in response to user requests:

  • Big buttons: Buttons are big and tap targets are actually generous!
  • Audiobus: Enjoy audio sharing!
  • Looper: The first version of the looper made it into the shipping version.

Developer Tip: 30×30 (60×60) is still a good custom UITabBarItem size

icon_30x30

Working with UITabBarControllers is fun. Once you get the hang of making UIViewControllers in your storyboard, Ctrl+drag linking them to your UITabBar is quick and easy. But chances are you will want custom tab bar icons. Here are some tips:

1. Icons should be 100% white with a transparent background

Even the updated iOS HIG says this. Use a PNG.

2. Make the high resolution version fit in a 60×60 rectangle

The docs will tell you that you have a 96×64 max size, but this not only doesn’t look great but it is just too large for most cases. Begin creating your art to fit in a 60×60 rectangle. Then, top-align and horizontally-center the content in a 100×100 canvas:

icon_centering

The resulting icon will be neatly centered with room at the bottom for the bar item title.

3. Save the high resolution first as “filename@2x.png”

As discussed in other tutorials, Interface Builder will do some magic for you. Save your high res version first with “@2x.png” at the end of the filename. Next, scale the image down to 50×50 and save again as just “.png”.

Note: if you are using Adobe Photoshop CC you can use the awesome Adobe Generator syntax to automatically render out both versions of the assets as you update the graphics automatically.

Developer tip: Taming UIPageViewController to do paging

I am coming off of several days of head-scratching as I have been trying to understand how UIPageViewController works. There is a lot of documentation to read and even with a good tutorial I still had questions. Hopefully this helps you:

1. Forget Interface Builder

Seriously. IB has given me more headaches. Yes, there’s a component you can drag and drop but it never worked great for me. Just make a plain view as the container that will hold your UIPageViewController. Even if you use Xcode’s new project Page-Based Application template you’ll end up with the same thing.

2. You want to implement the <UIPageViewControllerDataSource> protocol on your UIViewController

Keep things easy to begin with: whatever UIViewController that is serving up your UIView, make it the data source too. You will have two methods to implement where they will get the current UIViewController and be expected to return new UIViewControllers for the page before or after.

Note that the gist also has a factory method to return the UIViewController for the page number. In this case, all pages are just instances of SomePageViewController. You can imagine that each page might be a different view controller.

3. Don’t worry about navigation dots unless you want to.

If you want those dots on the bottom of the screen that show the user which page they are looking at, you’ll need to implement something like this:

3b. If you do implement the dots, presentationIndexForPageViewController: may only be called once

I had thought that every time you navigate this method would get called. Not necessarily true: it and the count method get called during some setup phase and don’t need to be called again. If you want to keep updating the number of dots or do some cute navigation trick where the current dot doesn’t map exactly to a specific page, good luck.

4. Alloc/init the child UIPageViewController

In your viewDidLoad: of the UIViewController mentioned in Step 1, do something like this:

5. There is no manual previous or next page … but you can reset the view controllers array and fake it with animation

UIPageViewController seems like it is overly simplistic. There is apparently no easy way to navigate prev/next. But what you can do is reset that view controllers array and indicate you want it to animate. So, let’s say you want to go to the previous page, this is a possibility:

That’s not great but it works. For instance, let’s say you wanted to go to the first page, if you followed a similar technique then:

To the user it would look like the page coming in immediately to the left is the first page. They would not see a flurry of pages fly by as it seeked to the first page.

Developer tip: Easily load a local HTML file into a UIWebView with image, CSS, and JavaScript resources

A small victory was had this morning when I finally figured out the magic combination of programming bits to make local UIWebViews work with local resources in an iOS app.

Instead of fighting with building the sBASSdrum help menus out of scrollable container views, it seemed like the best and easiest way to show the text was to load a local HTML file. This turns out to be easy but there are a number of gotchas. As I wrote on StackOverflow:

  1. Make sure all your bundle resources are unique—directories get flattened
  2. JavaScript files will be in the wrong Build Phase
  3. Use UIWebView’s loadRequest:

If you follow this recipe victory will be yours. Here is a Gist:

Even better, to make the background of the UIWebView transparent so you can see graphics behind it, follow this formula:

  1. Click on the UIWebView
  2. Set the background to Clear Color (not transparent)
  3. Unset the “opaque” property

Why “sBASSdrum Open Samples Pack” Is Free

digits_waveform

Making a music instrument is hard. Making a music instrument based on samples is harder.

One of the huge problems I had when creating my sBASSdrum app was finding open sound libraries. If you have ever done research in this area you will know what I mean. Even if the original sample has been downsampled, EQed, combined, or otherwise transformed from the original, it is still tricky. But I think that this is a challenge that can be overcome.

Even better: I would like to solve this problem for other people too.

Several sounds come from already open libraries:

But many I had to record from my own drum kit:

Or synthesize using software:

The point is, I hope to continue sBASSdrum Open Samples and give you, the developer and/or musician, tools you can use to make enjoyable music. Yes, make your own sample-based drum app. Or put these sounds into a DAW. Or use them as a foundation for your own sounds. All I ask is some attribution for the work in exchange for you making the world a more musical place.

Get the samples here:

www.freesound.org/people/ani_music/packs/13901

Why sBASSdrum is based on chord progressions

sbassdrum_l2_clip

There are many wonderful apps available that give you a fairly typical piano keyboard. On the one hand, it’s instantly familiar and people can often tap out a quick melody. But, unless you’ve been playing piano for a while I am willing to bet chord progressions are still a difficult concept to wrap your head around. What is their function in music? What actually makes up a progression?

Ultimately, sBASSdrum is a button-pushing app. It doesn’t pretend to be a powerhouse synthesizer or a study in music theory. The idea was if you had 4 chords and each button press would play one of those chords, and if you played the buttons in sequence you could get some sort of interesting music out of it. Or if you randomly whack away at the iPad and you still sound harmonious.

Each of the Combo patches attempts to play around with chords that roughly center around C—usually one of the chords on the buttons is a C or Cm. And they try to be pretty typical progressions like: I, IV, V, VII; VI, VII, I, iii; I, II, IV, I. And some are major, some are minor. The nice thing is if you tap the buttons in different orders you can get nice variations that have some relationship to the in-order progression. Plus, the free-form individual instrument patches let you truly choose the chords and melody you want to play.

In the future, the goal is to let you the user choose your own progressions so you can write your own songs and do techniques like cadences and borrowed chords. Transposition is also on the potential list of future features so you can keep the same progressions but change the root to a different note.

Music is hard. Flying a sBASSship should be fun.

Making the sBASSdrum app icon

make_s_logo

I was pleased to see one of the WWDC style guide videos talk about app icons. I had not seen this until today, but it seems that we agree on many points. When choosing the sBASSdrum icon, I wanted to have something that echoed some part of the interface. Obviously, it would have been unreasonable to just shrink down the UI:

sbass_wholeui

sbass_wholeui

sbass_wholeui

In the original design there were some smaller yellow-orange buttons with a small light above them that turned on when you pressed the button. So one of the original icons looked like:

sbass_button

sbass_button

sbass_button

It was too busy, it didn’t give enough meaning, and that button style also got eliminated. Actually, as the interface was evolving it became obvious that putting any interface control in the icon would probably be a self-limiting strategy.

So, what would not likely change? The logo. And, honestly, a lot of thought didn’t go into the logo: a fancy spacey font I had acquired a while ago for other projects turned out to evoke futuristic space themes. But, what I liked about the font was that it seemed to scale well when shrunk. And so the same thought was applied here.

Since the name of the app is “sBASSdrum”, it seemed logical to use the first letter of the logo:

sbass_logo_black

sbass_logo_black

sbass_logo_black

Another consideration was that background wallpaper can be busy. I’m a big fan of whitespace, and in this case it’s more “darkspace”. But having a plain black background was boring. Since this is a space ship and the center of the interface has a window so you can see stars rushing past, it seemed only logical to find a way to integrate that into the texture of the icon. Thus, in the end we have the S flying through space with a nice dark-colored moat around it.

sbass_actualicon

sbass_actualicon

sbass_actualicon

I thought the end result looked decent enough and it met all the goals of readability. Here are some examples of the sBASSdrum app icon on light, dark, and heavily textured backgrounds, and when shrunk small in an app group:

IMG_0222_light

IMG_0220_mediumdots

IMG_0219_darkphoto

IMG_0221_darktexture

IMG_0224_lightgroup

IMG_0225_darkgroup

Getting nerdy: sBASSdrum’s Klingon press release

sbassdrum_pIqaD

About that press release in Klingon:

This was a really fun project that wasn’t originally in the plan. It came out of brainstorming as I was in the middle of writing the original English press release. Since the drum machine’s user interface evolved into a spaceship cockpit, it only seemed right to continue on the space theme. Because of this, Star Trek kept coming back to mind. Also, as a web developer I often think about internationalization.

So, what if sBASSdrum was not just internationalized but inter-species-alized?

Recalling I had seen fans speaking in Klingon, it seemed like a great fit for this project. The pronunciation is starkly different than English, the glyphs are different, and there’s lots of people who actually speak this seriously. I asked friends on Facebook and received a few leads, but it I think it was the Twitterverse that came through:

klingon_tweet

loghaD responded:

klingon_reply_tweet

After some email coordination I sent him the English press release and a suggestion for the Klingon version which made references to big strong warrior hands, Bat’leths, and fierce sounds. He helped with cultural notes and really polished up the text. Then he went one further and also typed it up in pIqaD. The result: a really cool press release that echoes the fun of sBASSdrum.

Qapla’!

Read it yourself: http://www.seqmedia.com/sbassdrum-press-release-klingon/

The evolution of the user interface of sBASSdrum

The whole sBASSdrum interface
The whole sBASSdrum interface

One of the fun things with this project was figuring out what features to put into the interface. I wanted the UI to immediately contain all the controls the user needed so there were no hidden menus or popup panels. (In a future version those will be required, but not now.) The reasoning is especially for kids and novices, digging around menu systems means you spend more time exploring the app than making music. And immediately I wanted the user to begin playing.

But, a cockpit?

Originally it wasn’t. It was just going to be a simple drum machine. I knew I wanted it to have some sort of instantaneous readout of the audio being produced in the system. (I have a fondness for oscilloscopes.) It also needed to have relatively big buttons:

sbassdrum_l2_clip

And the more I thought about my favorite synthesizers I found they all basically did this:

  • Cool-looking 3D-ish interface
  • Blinking lights
  • Grouped controls

I also found that they:

  • Had way too many buttons
  • Controls were all over the place
  • Color palettes are typically fairly monochromatic

What I wanted was something that looked as cool as:
sunrise_cockpit_karim_nafatni

But was as simple as:

Additionally, I wanted it to be playable by holding the corners of the iPad and playing with just your thumbs.

Early sketches

First came the sketch pad. I almost always start there for any project. I’m a big fan of paper prototypes because you can get ideas out of your head quick, everyone at the table can see what you’re working on, and it has a physicality to it.

The first cut had a lot of buttons all over it. The top 1/4 of it was intended to be the visualizer and effects unit. The overall idea felt good but the buttons were too far apart: I couldn’t hold the iPad by the corners. It also meant there were too few main buttons: playing just one synth on the left was boring.

The next paper prototype attempted to focus just on the drums but the whole idea wasn’t gelling.

Finally, the idea of different instrument panel components coming together began to make more sense. The least-used or ambidextrously-used controls could be in the center, more used buttons could be towards the corners. The other reason to put scopes up top or in the center was because your hands would be covering the bottom corners.

Wireframes in Adobe Illustrator

The paper prototypes felt decent and doable even on an iPad Mini, which is the minimum target platform for this project. Now it was time to begin putting details in and trying to figure out how to make this look more entertaining. Over Thanksgiving break several iterations happened which resulted in almost the same interface that is there today.

It turns out that the buttons were still too big and too far apart. The window also took too long to render with my limited iOS skills. And despite the left hand synth looking cool, there were not enough buttons besides the awkward 45-degree turn of the wrist.

The final interfaces

After roughly tracing the Illustrator vectors in Photoshop, dimension and lighting were added to give it more depth. Ridges appeared, colors got darker, the left panel changed colors to make it distinct from the right one, the synth-switching and drum-switching controls moved farther away from the pads (because they were inadvertently being tapped), and the scopes became smaller. The looping controls at the top were actually not originally going to make the first version of the app but without them the app felt too hard to play. Most people don’t have the coordination to do right and left hand tapping independently, so looping solves a lot of this problem: record some drums or bass, then layer on top, then play with the effects later.

Conclusion

Making the user interface was a very fun and very iterative process. The early designs “failed fast” and I kept putting new designs out for friends to try. The design is still far from perfect and many aspects are overly cartoonish, but the organization feels solid and plans to upgrade all of this with better art are not long in the future.

Finally, sBASSdrum takes flight

PHEW. After several months of work the sBASSdrum iPad app is finally launched! I have so many stories to tell and hopefully over the coming weeks I’ll be able to detail a lot of them here.

First, though, I could not have done this without the tremendous help from friends, family, and internet acquaintances. Launching a product is much bigger than one person alone and there is simply not enough time in the world to learn everything to the point of high proficiency.

So, please check out the demo video, download the app for free, and have a wonderful time making music!