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.
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
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:
The resulting icon will be neatly centered with room at the bottom for the bar item title.
3. Save the high resolution first as “firstname.lastname@example.org”
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.
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.
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:
Make sure all your bundle resources are unique—directories get flattened
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:
Click on the UIWebView
Set the background to Clear Color (not transparent)
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.
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.
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.
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:
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:
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:
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.
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:
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:
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.
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:
And the more I thought about my favorite synthesizers I found they all basically did this:
Cool-looking 3D-ish interface
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:
Additionally, I wanted it to be playable by holding the corners of the iPad and playing with just your thumbs.
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.
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.
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.