You are here


WANTED: Two N8 Cameraphone apps with settings locked: default + hyperfocal street photography

Submitted by Roland on Sun, 2012-04-08 07:33

I'd like the following N8 Cameraphone Apps to avoid all the problems with accidental key presses and screen touches that I encounter every day:

  1. The default cameraphone app but with the default settings locked to still photo (not video), auto-focus, auto-white balance, no zoom, touch screen off.  And with no way to exit other than by killing it. This would be the app I'd use most of the time!
  2. A cameraphone app like #1 but with the settings locked to hyperfocal instead of auto-focus, no preview and again no way to exit other than by killing it. This would be the app I'd use for "cameraphone street photography"

Ms. Jen, can you write this for me? Or can we write this together?


My ideal mobile mad scientist language

Submitted by Roland on Tue, 2009-11-24 22:35

After some digging and research around the web, my ideal mobile mad scientist programming language would:

  • have the 2D and 3D graphic manipulation power of Processing, Nodebox and Shoes
  • be cross platform mac, windows, linux, maemo on mobile, iPhone, android
  • be 'web native' i.e. REST, JSON, XML and all the other web API stuff built in and not bolted on like it is Processing, trying to use the flickr api from Processing is shall we say kludge-o-rama (awesome code from bryan chung but indicative of the unnecessary struggle one is forced to engage with in Processing and other non web native languages)
  • not use a Java-like syntax, death to curly braces and wasted semi-colons
  • be dynamic, death to the Java/C++ cargo cult of typing for no reason 
  • be easily adaptable to new APIs and new sensors through the ability to create a domain specific language and/or easy to use and beautiful foreign function interface
  • be open source, sorry but for my mobile art,  i can't use programming environments and languages that are not open source
  • support the REAL loop, I don't want to spawn threads for the sake of questionable 'concurrency' like I am forced to with OSGI and the Bug Labs Bug

IF I were an idealist that pretty much rules out everything :-)

Fortunately I am a pragamatist. So I will continue my experiments in:

  • Nodebox & Python on the Mac
  • Cocoa Touch and Objective C on the iPhone

What about Processing? Sorry can't handle the Java syntax and the pain of doing XML and JSON and REST programming and the kludge-o-matic way to access Java libraries. processing.js? too early and too much impedance mismatch to use all the lovely JS libraries out there. And Shoes is promising especially if it were improved so you could easily use normal Ruby gems but given its current "hibernation" "post-Why" not sure it will continue to be improved.

What should I use on Maemo if/when I get an N900? Ruby plus SWIG or some such foreign function kludge er interface :-) to access the sensor APIs which I assume are only available in C and C++ ?

What should I use on Android if/when I get an Android device?

What should I use on Windows? Not that I really care :-) But it would be lovely to have Windows people join in my fun without having to do anyting. Eines Tages!

Somehow I think the "mainstream" world is moving towards my ideal solution and the mainstream solution for what I want will look more like processing.js and ruby-processing or smalltalk i.e. scratch then it will look like Processing, Nodebox or CocoaTouch

REAL - Read, Evaluate, Art, Loop - N900 is the closest thing to a "REAL" machine

Submitted by Roland on Thu, 2009-10-15 23:19

What I am looking for in my ongoing mobile art experiments is REAL!

  1. Read the sensors (GPS, accelerometer, compass, etc)
  2. Evaluate the data from the sensors
  3. Art - Make some art (sound, graphic, image, etc) and display and store it on the mobile
  4. Loop - Back to step 1

And I want to do it in a dynamic environment that doesn't force me to do yak shaving like spawning separate threads for each of the sensors or other such needless complexity that's not needed by my artistic algorithms. Nor the slings and arrows of outrageous certificates or certifications or developer programs or DRM malarkey :-) !

After reading the N900 technical reviews from the Maemo summit, it appears that the unlocked version of the N900 is the closest current device that could do this:

  1. It's Linux so assuming the sensor APIs are available from a standard Linux C (i.e. not using some non standard craziness like Carbide C++ for Symbian) library, Python, Ruby, name your favourite dynamic language here, etc (C++ and Java are just not malleable and easily hackable enough, sorry!) bindings could be (and probably are or are in the process of being) built to those C libraries
  2. No need for developer fees or ridiculous certificates
  3. It has all the sensors I want for my current experiments
  4. It's NOT mass market, but it's mass market enough for hackers (unlike Bug Labs Bug which I love but already probably has less than 1/10 the amount of developers working on it as the N900).

Am I right? Time for me to watch the blogs for signs of the N900 and Maemo 5 and 6 making dynamic languages first class citizens unlike on Symbian where S60 Python was far too many steps behind Carbide C++  (and time for to save up for the N910 since the N900 will probably be crippled in some significant way as all 1st gen Nokia devices are e.g. N95-1 not having enough memory)

Subscribe to RSS - real