a brief history of...
28/11/10 22:29
I finally grabbed all my small screen casts i made of synthmate as i developed it. It begins with the original concept, inspired by and using Matt Legend Gemmell's multi-touch demo. It then moves on to the control panels and initial look and feel. Later, there are some different visual ideas i played with before arriving at the final look. Enjoy.
Tools
16/11/10 20:16
After writing my last post, i thought it would be nice to do a short post about the tools i use(d) for developing iOS apps. Here goes :
- 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.
ui/ux
12/10/10 10:58
I'm very interested in user interface (ui) design and user expereice (ux) 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
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
13/09/10 09:34
Recently, i needed some graphics to represent a check mark - ✓ and a cross - ✗. I automatically searched with googles lovely image search interface (except that popup) and brought some nice images into my project. WIth a few simple lines of code i had them load up and rendered where i wanted them.
Easy.
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.
Easy.
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
17/08/10 09:34
"Reading" header's files has always been something i've heard developer's do. I use header files everyday, refer to them constantly, but i never have found a reason to really "read" them, until recently. Whilst working on audio development for the iphone, building my audio engine and prototyping a music/beat making app, i was hoping to add a feature using sample rate playback of audio in real-time. I had spent a morning searching, downloading, building and running several open source libraries to do the job but found that they all had a number of drawbacks. They all looked fantastic but relied on other libraries which required other libraries etc, and i would have to do some refactoring to incorporate the library into my engine's design. I really wanted something that i could plug straight in.
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....
enum {
kAudioUnitSubType_MultiChannelMixer = 'mcmx',
#if !TARGET_OS_IPHONE
kAudioUnitSubType_StereoMixer = 'smxr',
kAudioUnitSubType_3DMixer = '3dmx',
kAudioUnitSubType_MatrixMixer = 'mxmx'
#else
kAudioUnitSubType_AU3DMixerEmbedded = '3dem'
#endif
};
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.
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....
enum {
kAudioUnitSubType_MultiChannelMixer = 'mcmx',
#if !TARGET_OS_IPHONE
kAudioUnitSubType_StereoMixer = 'smxr',
kAudioUnitSubType_3DMixer = '3dmx',
kAudioUnitSubType_MatrixMixer = 'mxmx'
#else
kAudioUnitSubType_AU3DMixerEmbedded = '3dem'
#endif
};
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.