This assignment was to develop a concept around a two-screen, live event experience; specifically, using TV and computer via internet. Our group’s concept was a variety-style, Gong Show inspired show with binary voting from viewers to determine via aggregate whether a performance was Fly (a rousing success) or Pie (a miserable failure) which received a whipped cream pie in the face. (We’re a classy outfit here..) (more…)

We’re using Foursquare as a data logger for one of our assignments in the Telling Stories with Sensors, Data and Humans class at ITP. As an aid to begin understanding the relationships between venues for our tracks, it’s helpful to munge the KML into CSV so it can be plotted and played with in a spreadsheet, Illustrator, R, Processing or whatever…

Below is a short python script to parse a Foursquare KML file into a simple CSV file. It outputs the check-in name, description, timestamp and location (as lat, lon). The Foursquare KML feed is available at the Feeds page on their site. (more…)

Yesterday I released a small web app; it was my first using the Sinatra microframework for Ruby: http://qwerty.robertcarlsen.net

The app arranges illustrations of animals wearing lettered t-shirts to create user-supplied messages. Kara Schlindwein created the illustrations as part of her project for the 6th Annual Fun-a-Day project in Philadelphia, and I wrote the first draft of the app while sitting in a chair at the show a couple of weeks ago, still nursing my broken ankle. (more…)

The source code for the Tesseract OCR for iPhone project has been published. It’s really simple – more of a skeleton, proof-of-concept project than anything else. Still, though, it’s neat to have nearly point-and-shoot text conversion in your pocket.

The project page is: Pocket OCR

The source code is available at github: http://github.com/rcarlsen/Pocket-OCR

There is certainly a lot of improvement to be made. Automatic color correction. Page layout recognition. Perspective correction…the list could go on. The code is there, so…fork away!

(the thumbnail is a bit tongue-in-cheek…but honest. good conversion requires a good source image: well-lit, macro, focused and tightly cropped seems best)

Update: Source code for demo project released.

i finally got around to building a proof of concept implementation of tesseract-ocr for the iPhone. months ago, i documented the steps which helped to get the library cross-compiled for the iPhone’s ARM processor, and how to build a fat library for use with the simulator as well. several folks have helped immensely in noting how to actually run the engine in obj-c++. thanks to everyone who has commented so far.

anyway, below is a short video of the POC in action. the basic workflow is: select image from photo library or camera, crop tightly on the box of text you’d like to convert, wait while it processes, select / copy or email text. (more…)

In preparation of submitting Pinwheel to the App Store I’ve gone and released a beta version via ad hoc distribution. Seems like it should be a straightforward prospect, however the various device provisioning, code signing profiles and entitlements made it a bit of a process for a first-timer.

iTunes also seems to be entirely unhelpful when something goes wrong with the “unknown error” message. What could it be? Code sign error? Unprovisioned device? Incorrect OS target? Mismatch in the app and mobileprovision file? It’s all a mystery in the iTunes universe.

Despite the inconvenience involved with having to generate a new ad hoc mobileprovision profile each time I add a new beta tester device, requiring a recompile of the beta app, it’s nice to finally get an app out to other non-development devices.

The ad hoc distribution process is documented well (enough) on Apple’s dev portal and on several other blogs, but my real stumbling block was navigating the Xcode interface to ensure that the proper code signing profile was being included in the binary (hint, look at the verbose build output for “embedded.mobileprovision” and ensure that the mobileprovision ID matches the correct version.)

I’ve also been getting trouble with Xcode not building using the correct provisioning, despite updating the target info and cleaning out the build folder. A restart of the program usually gets it sorted.

The next step will be to set up a Distribution build for the App Store submission. We’ll see how that goes in the end…

i’ve been dealing with a performance bug in a particle + accelerometer oF app. the same project which has run very smoothly on a first generation iPhone with OS 2.2.1 has a noticeable stutter on an iPhone 3GS with OS 3.0.

there was no improvement despite several rounds of optimizing the openGL drawing code and plugging several memory leaks.

finally, in frustration i bumped the explicit frame rate declaration from the default 60 fps to 120 fps. i realize that ofSetFrameRate(60) is merely the upper limit of the frame rate, and that the hardware won’t actually go faster than it can handle, however this immediately improved performance on the 3GS and the first gen is about the same as it was. further improvement was had with a declared frame rate of 240 fps.

i haven’t had a chance to look into the underlying issue, but i believe that oF is using NSTimer under the hood to trigger a scheduled update() and draw(). has there been some change in the SDK there?

i’m having a time of it tracking down a resource allocation bloat culprit in an iPhone app i’m working on. i’ve narrowed it down to when i’m rapidly updating the center property of a UIImageView. a snippet from the Instruments application is below:

there are hundreds (if not thousands) of these messages, and the object allocation graph trends steadily upwards. when i disable the portion of the method which updates the center property the allocations stop and the memory usage goes flat. this also only occurs on the device…the simulator does not exhibit this behavior.

i’m using UIImageView directly, without subclassing, and it contains data from a small PNG file. i’ve patched up several other leaks successfully today, and really wanted to nail this one too.

There was a recent comment about saving / restoring application state when using openFrameworks for iPhone which got me to thinking about how to do it. Apple’s frameworks provide a fairly thorough way to save state to the disk and restore later. There seem to be three primary ways to do this: simple plist files (usually encoded in binary on the iPhone), archived data (they like to refer to this as freeze-dried object graphs) and core data.

I believe that archiving objects require methods inherited from NSObject, which we don’t have in openFrameworks’ ofSimpleApp. Core Data seems like overkill, so I looked into using plist files.

There are likely better ways to do this, but this ad-hoc solution works wonderfully for a small app I’m working on, and only requires a bit of Objective-C code that could likely be moved up into a nice wrapper class. However, since the question was asked I’d just like to get it out there before working on a more elegant approach. (more…)

Here is a (really) basic wrapper for the UIAlertView in openFrameworks of iPhone. Not all of the necessary delegate methods have been implemented yet, but this is enough for me to get the proof of concept rolling in an app I’m building.

Feel free to let me know how I can do things better, or just tinker with the code directly at github: ofxiPhoneWrappers

Check out the example project. This is a bit of a kludge. I would like to figure out how to avoid having to declare main and testApp as mixed source files (.mm). It works for now, however.

Here are the notes on using the class: (more…)