a brief history of...
- Pen + Paper : the greatest pair of tools that has stood the test of time. i use paper with no lines and can tear off the pad.
- X-Code : for all my coding needs. not by choice. i tried using xcode with textmate but i didn't enjoy the experience. if only xcode and textmate could have children. it's a beast and there is a lot of power underneath it all. but i've seen visual studio over the years consistently impress and lead as an IDE.
- Interface Builder : i do use this for making the ui but only in terms of layout...and even then not really. it was terrible when it first came out, but it's getting better. i did hand code all my ui code back in the day and still like having that flexibility.
- Instruments : the app is kinda cool. it really needs processing power and it struggles when doing core audio stuff, but it can really help performance and memory issues.
- TextMate : i love this app; a coders very good friend. i use it for notes and design and code review....but not for coding!
- Terminal : i still use svn, although i have finally moved to git as well. that said, i still use terminal for svn and to do builds for libraries and try stuff out. i will always like to know more command line stuff.
- Flash : i know this app well and i like its object wrapping process of building objects. i mostly use this to do mock-ups, wireframe, diagrams and some production graphics.
- Acorn : this is a great graphics app. i do all my graphics work in it and would love to improve my skills in using it.
- Grab : if i need to do quick snaps shots of some part of the screen, i use this. its simple and really quick. If i want to grab whole parts of something, i use Acorns excellent layer screen grab.
- Snapz Pro X : i use this to do screen capture movies. it seems the best in terms of choice of rendering for both video and audio.
- RapidWeaver : this app is my friend. it makes making and maintaining a website really easy. if you haven't seen it check it out, it's worth it for its simple design.
Recently, working on my new ipad app synthmate, the most interesting part has been reflecting on the progress of the app's ui/ux and learning from what elements stayed and what elements changed from my initial design/ideas.
Wireframes or mock-ups were done using flash. I like using flash because i know it and i like the way you create objects inside other objects. I can easily switch between assets and generally work fast and am able to constantly tweak. The assets i used were grabbed off the web and screen shots of the ipad simulator. I should say i also don't like flash for numerous reasons but i won't go into them here.
Here's my first mock-up
Some of the things i didn't like about this first draft were :
- duplication of the keyboard image. i felt user's would probably get confused between 2 pop-overs looking very similar. I tried to put scale and scope together (below) but i felt there was now too much for the user to work with.
- I liked the idea of making rotating controls and had a nice looking image BUT i made one and it was terrible. I soon realised that trying to simulate "real world" controls on a "virtual world" device is often a gimmick and not very user friendly. I knew this from using many applications including digital mixing desks for live audio and now that i had made one, i understood why they don't work. So, i went for a more modest slider control, apple's built-in one. I dressed it up to blend in with the other controls and set the thumb and slider size to both be large enough for a finger to touch and to also show the min and max.
- I felt the green ✓'s and red ✗'s were over-kill. Very busy. The more i thought about it the more i realised that in fact what i was trying to show was not a keyboard at all. For those musicians out there, setting the scale keyboard to say D Major and then setting the Root note to say E would mean you would be playing E Major. Very confusing. To solve this, i came up with what i was really trying to represent; the notes within ANY scale. The solution was so simple and it also meant i now only had 1 keyboard image, representing the Root note.
- The control surface is a whole other post. I'll edit the screen capture movies into a quick history of its development.
I love my mock-ups. They help me see what my app is going to do. And it separates writing code and designing ui/ux. Of coarse it's hard to separate from writing code and there are always tweaks to be made. I find having a good clear idea makes writing the code a lot more fun because it's satisfying to achieve what you set out to achieve. WIthout a plan or a rough idea of something can also be fun, with some lovely results. But it doesn't always work.
I ♥ unicode
But then i thought, hang on. That wasn't easy at all. I had to find the assets and write code. Also, eventually the assets would have to be made by a designer (or me), adding more work. It then struck me that the iphone and/or any device with an OS must have a bunch of assets sitting around to be used by the OS and possibly accessible through an api. Especially a check mark and a cross! Then i thought, unicode. It's a standard, it's built-in and all the rendering and options are already in place. All i have to do is code what character i need. For ✓ in NSString/Cocoa land it's:
string = @"\u2713";
It render's as expected, i no longer had to worry about my images being pixel-perfect and i had 2 less assets to manage. My tip : look through all the unicode character's (there's quiet a few) and to try and use them as much as possible in the future.
AUMixer3D unit on the iPhone
A week later, out of frustration, i remembered a reference to something in AudioUnitParameters.h of the core audio's header files.....
// Input, rate scaler 0.5 -> 2.0
k3DMixerParam_PlaybackRate = 4;
This seemed curious but was not what i was interested in at the time. Instead, it sat somewhere in the back of my mind, niggling away for a week until i looked again. I didn't know what it was meant for but it looked at first that i could use this enum to pass a value to an audio unit to control the sample rate playback. Just what i wanted! i think....so I began searching .
Apple's core audio lack of documentation is considered the worst by some and simply frustrating for others. Turning to the web gave me a few small clues but most references were in the context of developing for the desktop, not the iphone. So, i returned to the header files and "read" them, in search of anything. And alas, i found....
kAudioUnitSubType_MultiChannelMixer = 'mcmx',
kAudioUnitSubType_StereoMixer = 'smxr',
kAudioUnitSubType_3DMixer = '3dmx',
kAudioUnitSubType_MatrixMixer = 'mxmx'
kAudioUnitSubType_AU3DMixerEmbedded = '3dem'
And this is where i became excited and discovered the reason why programmers "read" header files and not just the documentation. It looked like i could create a kAudioUnitSubType_AU3DMixerEmbedded audio unit and thus change the playback rate in real-time. Within a few minutes, both my app and engine had a new major feature. And even better, i was using code written specifically for the device and by far better programmers than myself.