Day 3 learning objective c

June 17th, 2009

Getting more comfortable with the language. Working on coding some custom controls, figuring out CoreGraphics, etc. Also installed the new OS 3.0 stuff.

Questions:

  • Why do I see this in some example source:  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; ….  some code …..  [pool release];
    Why is this necessary?
  • Why is it that messing up a method call on an Objective C object results in a crash that provides no useful debugging info? it seems like most crashes on the iphone don’t give you a proper line number.. Am I missing some project setting?

Day 2 learning objective C

June 16th, 2009

(for those that don’t know I am taking a week to learn apple’s Objective C. Bleep! BOX (my other iphone app) is written in C++ using LibNUI, so I haven’t had to touch any Objective C so far)

Today I investigated Objective C++. Basically, if you rename your .M files to .MM then you can mix C++ code in with your Objective C code. Seems to work just fine. It’s pretty common to interface with C/C++ libraries from Objective C (several example apps do). If I am ever forced to write iPhone apps that need to use standard GUI widgets then I would probably use regular Objective C for the interface and C++ for all the logic and data. Aside from being easier to work with (for me anyway), I think this will provide better separation between UI code and ‘back end’ code.. A lot of the Iphone examples I’ve seen so far have controllers for specific pages holding onto ‘model’ data. This can lead to architectural problems because there are a lot of cases where you want the two to be seperate and independent. I see the same issue with a lot of Flash code too, since the recommended way of doing things is always to subclass one of the Display classes. I usually find that using singletons for app-wide data is a better choice than attaching your data to a UI specific class.

I am also looking through the rest of the example apps, trying to learn more. A couple that caught my attention are the Wi-Tap app which shows how to do basic TCP connectivity (once again this references C++ code to get the job done), and also the LaunchMe app. Apparently it’s possible to set up a custom URL type to launch an iphone app.. IE, have myappname://www.someurl.com/ open up your app. This would be cool for Bleep! BOX to allow people to browse a bunch of user submitted songs in safari and have the ability to click on one to open it up in the app. Seems very easy to implement.

AccelerometerGraph is the first example I’ve looked at so far that gives a good ‘low level’ look at how to make a UI component that draws itself. It also manually creates UI items which gives a better look at how things work internally. Digging in deeper..

More learnings:

  • @selector is basically a delegate. Use it to call methods in response to actions
  • In terms of reskinning existing objects, you can use Categories to override or add methods on objects without actually subclassing them. Though I’m a little unclear on how this works. Once I’ve made a category, does this apply to all instances of that object or can I choose whether I instantiate the the regular ‘uncategorized’ version of the object or the ‘category’ version?
  • UIView - addSubView is how you add ‘child’ views.
  • Good Info: http://www.iphoneexamples.com/, http://cocoadevcentral.com/d/learn_objectivec/
  • This is interesting. A code only approach to iPhone ui - convert XIB to code: http://kosmaczewski.net/2009/03/17/nib2objc/

I’m starting to write my own Control from scratch. This is how I got started with LibNUI and should be a good way to get started with UIKit.

Thoughts on Objective C

June 15th, 2009

This is my first day trying to learn Objective C. Here’s my thoughts so far - some of these may be wrong since I am still a newb. ;) Learning a new language is always a bit frustrating at first, so bear with me.

What is it

  • Objective C seems like it started with C, took a few OO concepts from C++ and added manual reference counting memory allocation out of the box. Somewhere along the way, syntax got beaten to death with a hammer, resulting in a strange, unique syntax. This gets a big frowny face from me - almost every modern language shares a similar syntax (Java, C++, C#, Actionscript, Javascript, heck even PHP once you get past the dollar signs) - being different here only makes it hard to learn and there’s no reason it couldn’t have a more C++ or Java like syntax.

What’s weird

  • Why come up with an entirely new syntax and language? Objective C is rumored to be less efficient than C++ and doesn’t seem to offer any benefits. Programmers still have to deal with pointers (in the sense that bad reference counting can still crash your applications). Poor use of reference counting can easily lead to memory leaks. There doesn’t seem to be anything particularly slick or time saving about the language itself.
  • When declaring an interface, why are methods and variables outside of the brackets? Also, it’s not necessary to declare methods as part of the interface? Seems like this kind of defeats the purpose of having an interface.
  • Way of declaring and calling methods (esp methods with parameters) is strange and not very readable..

What’s nice

  • Interface builder is kind of nice.. Ability to click and drag to connect outlets is slick. However, I find myself wondering if I couldn’t do things faster just by creating the interface “by hand” with code. Even simple stuff requires a lot of setup..
  • @property, @synthesize

So far every application I try to write from scratch crashes and burns. Oh well, there’s always tomorrow.

First sample + name

June 14th, 2009

Here’s the first official sample of my iphone app, which will be called ‘Bleep! Box’

Bleep Box - sample1

Features me mixing it up live using the ‘looper’ in realtime. All sounds synthesized in realtime. This is only about 7 parts of a possible 10. There’s one or two more ‘big ticket’ items to finish up (such as deleting presets, copy and paste for patterns, etc), and I still have to re-skin the gui. Probably be another week or two still before I can really say it’s done.

IPhone app - finishing it up!

June 10th, 2009

I’m in the final stretch for the 1.0 version of my iphone drum machine / synthesizer app. I’ve settled on the final configuration as far as the synthesis capabilities. Doing 10 voices of 2 osc synths proved to be too much for the iphone’s CPU to handle (BTW, I’ve seen info putting the Iphone 3G’s cpu at 400 mhz, not the 666 mhz I originally thought). So, I settled for 4  2-osc “powerhouse” synths, 3 specialized bassdrum / FM synths, 1 specialized snare drum / clap synth, and 2 specialized hi-hat generators (modelled after oldschool 808 machines). Overall this gives you tons of possibilities and should enable people to make pretty decent electronic songs on their IPhone. There are no samples in this bad boy - everything is synthesized in realtime.

Realtime control is another thing that sets this app apart from other iphone apps. There is a performance page which lets you loop/remix portions of your tune using multitouch. Dual touchpads and mute / solo control is planned for this page. Another thing that would be awesome is an arpeggiator, but I dunno if that will make it into version 1.0. There is also a ‘motion’ page that will allow you to draw automation envelopes  for one parameter for each part.

These features address  what I see as the major shortcomings of the current crop of iphone music apps. Either they are simple ‘instruments’ which people will most likely use once or twice and then stop using. Or, they are mostly sample based which stifles creativity. Or they don’t offer enough options or automation abilities to make an interesting sounding song. Another shortcoming is poor interface choices. Piano roll on a touchscreen = tedious. Iphone apps (or more generally, touch UI’s) need to be based around taps and swipes. For taps, buttons need to be big enough to hit easily (I’ve found the ‘magic size’ to be about 80 pixels x 80 pixels.). Doing a piano roll on a 320 x 480 screen means that you will be trying to tap on stuff that’s 10-20 pixels wide which is highly frustrating and a bane to good workflow.

My goal is to finish all the major pages and functionality this weekend and start implementing the final UI. Hopefully I’ll be able to start posting some audio and video next week.

iPhone app

June 1st, 2009

Just wanted to drop a post to say that my iphone app is coming along pretty well. I’ve put in a ton of time on it the last few weeks and it’s starting to come together. I should be close to finishing it in another week or two.

The first few days with libnui were a little frustrating since I didn’t quite understand how the layout widgets were sizing themselves (specifically the grid based widgets). I’ve been used to juce’s more explicit (typically fixed size) layouts. Now that I’ve been working with them a while, I find them to be a more welcome addition and there are some nice things you can do with them that do save time. I am still a bit confused about how some of the CSS stuff works (mainly I think I need some more examples and documentation about how the different widgets can be styled..), though it’s perfectly acceptable to eschew css and set up your widgets styles via code (which is what I’ve been doing). I’ll avoid getting into too deep of a comparison between juce and libnui here because I want to do a full post on it later.

Now that i know my way around the framework I am pretty productive and the good news is that writing your own components is a pretty simple affair (just as easy as it is in juce).

Currently I have all the major synthesis modules written. I have most of the major ‘pages’ in the app written (only one or two left to go). I’ve had to scale back my planned # of voices due to CPU constraints.  I’m still shooting for 10 voices, though i need to get each voice down to about 6.5% cpu in order to keep the GUI snappy and avoid audio breakups. Right now I think they are at 8% and I’ve already done a fair bit of optimization. Each voice is basically a 2-Osc synth + filter and several envelopes, so you can do some cool stuff with them. I always find it hard not to throw in the kitchen sink when it comes to making synthesizers. I like to have a lot of options. I also have some pretty cool ‘live performance’ oriented features (which make use of multitouch) that I think people are going to dig. I will post some screenshots soon. We will have a more finalized gui design soon. I also did some work on a logo. ;)

One good benefit of the whole thing, is that I basically re-wrote my audio framework from scratch (this same framework is what I’m using in Genome). In doing so, I identified a bunch of optimizations and design improvements that I should be able to carry over to Genome. Re-writing things almost always yields a better product. Many parts of genome have been re-written several times by now. There is a big tendency for programmers not to want to touch old code and to just ‘leave it as is’ even if it’s flawed. I prefer to start from scratch every once in a while just to clean out the skeletons.

Good article on designing iphone UI’s

May 12th, 2009

http://www.the-soulmen.com/blog/2009/02/09/on-prototyping-iphone-ui/

The article talks about the challenges of designing a UI for such a small screen, and how you have to design elements to be bigger for a touch interface than you do for a mouse clicking interface - something I immediately noticed myself when I began designing my iphone app. Worth a read.

Hiatus alert

May 11th, 2009

I’m going to be taking a short hiatus from Genome to work on an iphone app. Should take 1-2 months. I hope to still do one or two things on genome each week so I don’t get totally rusty on the codebase. I am planning to do an analog synth/drum machine (think of a Korg Electribe A and R combined).  There are already a ton of drum machines on the iphone but most are sample based and the output is not really anything unique or interesting. For instance, there are several Rebirth clones, but they don’t offer parameter automation which results in some boringly static basslines.  Other synths don’t feature drums or are limited to mono sounds. I’d like to make a flexible drum/bass synth with up to 16 parts. Each part could be a synth drum sound or a mono bassline. All parameters would be automatable with easy to draw graphs. The goal would be to give it a lovable character of it’s own similar to how LSDJ on the gameboy has spawned an entire genre of music with it’s unique sound. We’ll see whether the iphone’s 667 mhz processor is up to the challenge.

I am already learning a lot about how to design a touch-based application for a small screen, especially one that involves a lot of parameters like a synthesizer. I’ll post a few of my wireframes oon.

I’m looking to use LibNUI for this project since it supports iphone development in C++. I’d love to use Juce, but no telling when it might support the iphone. (With my luck it will be out just as I am finishing this  project up). Expect a post comparing LibNUI and Juce. They are both pretty similar in terms of design goals (cross platform frameworks supporting sound, gui, networking, etc).  I still like Juce better, but there are some interesting features features of libNUI that deserve a look.

Currently I have a simple application up and running on my iphone and I already coded my first custom NUI GUI widget..  I have lots of code ready to go in the synthesis department, so it will mostly  be a lot of GUI work. I will be using a version of the same audio framework I developed for Genome. It will give me a chance to try out some optimization tweaks I’ve been thinking of for Genome, on the iphone.

Module View I

May 3rd, 2009

Module Menu

  • Implemented tags for modules
  • Added a more proper module menu. It can be configured via XML and is based off tags.

Work Log

May 2nd, 2009
  • modified alt-drag behavior in piano roll. No longer destroys notes as you drag
  • fixed a bug that was breaking undo behavior in the piano roll
  • Other bug fixes and updates to the piano roll. One or two other fixes left to do here, but I am gonna move over to the module view next.

To do:

Implement tagging of modules and improve the module creation process.