abstractmachine

One of the interesting effects of physicalization would naturally be the further entanglement of algorithmic machines and cosmic phenomena, whether that be relative, quantic, membranic, or whatever else might come down the theoretical pike. Of course computers are already heavily entangled with various physical properties; it’s what makes them work. But to directly entangle an abstract algorithmic process to a cosmic phenomenon, now that’s cool.

Slashdot has just linked to the Quantum Random Bit Generation Service which will generate random numbers for you over the internet using hardware that « relies on intrinsic randomness of the quantum physical process of photonic emission in semiconductors and subsequent detection by photoelectric effect ». In other words, these are kick-ass random numbers that count up to 11.

So far there is a C++ library, a command-line tool (both will compile under g++), and some other systems/protocols that I don’t really know or work with. It also looks like some web interfaces are in development as well.

Further blurings of my identity today. I’ve just gotten back from my last interview before becoming a true Frenchman, and now I’m about to get on a plane to head back to my home country for a few weeks. I’ll be in this national identity limbo for about a year, after which the paperwork will have gone through the system and returned with a big stamp. So I’m still not French yet. I.e. you still can’t call me a Frog, ask to see my beret, complain about my rude demeanor or whatever lingering Freedom Fry-esque hatreds you have yet to cure yourself of. Nope, for the moment I’ll just have to be another one of those bastard americans as far as you’re concerned. But around this time next year, I’ll be a more evenly distributed target for your bigoterie as I’ll be both an asshole imperialist pig and a pretentious frog all rolled up into one.

I’ll be in the Silicon Valley area for about a month (Los Altos Hills), with a weeklong stay near Santa Cruz in early August. If you can think of anything interesting going on, or just want to meet over a nice cup of hot tea, let me know.

(Image excerpt from The Signal)

Ah… enfin… des crochets pour des français. Merci Ben. Si vous utilisez Processing, et que vous écrivez sur un clavier Macintosh Français, allez vite télécharger la dernière version, numéro 125.

What the hell am I talking about? Well, through a strange chain of events, Processing suddenly developed a problem over the last few months with brackets. Yes, brackets. You probably already know this, but the signs [ and ] are absolutely essential to programming in Java, along with many other punctuation marks by the way: { } ( ) ; , * / % // /* */ & | and even the period (.), almost all of which take on wholly different significations than in English or French. Yes, computer languages are fussy, and without a bracket, you can’t really do anything interesting in Java. Unfortunately, they were an absolute pain in the @#$ to write on French Macintosh keyboards, because they also happened to trigger the « previous tab » and « next tab » keyboard shortcuts.

This is now fixed in the latest version — Processing 0125 — which also fixes all sorts of other major lingustic faux pas, such as calling that little color thingy a « Color Picker », which thanks to Casey Reas’ insistance is now correctly named the « Color Selector ». Oh and then there are a few other, unimportant things such as faster 2D image rendering. You know, useless things of that nature.

;-)

Although this blog is mostly dedicated to projects I’m directly or indirectly involved in, I’ve decided to open a new category — physicalization —, to discuss more often than usual news related to this (ancient) emerging phenomenon. This follows on the heels of my last post about physicalizing algorithms via rope; which you might have read as just an annecdote, but in my opinion should be reframed within a larger general tendency of computing technology.

Simply put, computers will indefinitely be entangled with the process of physicalization — even in the case of (and especially in the case of) miniaturization and dematerialization —, quite simply because the very process of phyiscalization is what made the very idea of the computer possible. It is, for lack of a better term, the achilles heel of computerization, meaning that this imprint from its ontological birth accompanies it, re-defining it structurally as the internal limit of its possibility precisely at the point of its becoming-possibile.

But while it’s interesting to look at how algorithms can directly be ported to the physical world (with or without imitating digital circuits), it is also interesting to think about how modular (and not simply algorithmic) processes might simply be piggy-backed, or bastardly hybridized with biological phenomena. Latest exhibit: Robert Krulwich’s video segment on Measuring the Temperature (in Farenheit) using Snowy Tree Crickets. Recepie: if you have a Snowy Tree Cricket in your backyard, count the number of chirps for 14 seconds, add 38°, and you have the precise temperature (in Farenheit). Apparently it’s an extremely stable guage (cf. Dolbear’s Law, via Make Blog & Geekdad Blog).

Throughout much of science fiction, you will find examples of animal/human/technology hybrids, which is quite natural given the dependence we have on these two supplementary phyla (to use a Deleuze & Guattari term). Our civilization is founded not only on technological principles — language being number one —, but also on the concept of animals used as a technology (and vice-versa). I also consider significant that early texts of cybernetics look not to chess-playing machinery for their examples, but instead to mice, cats, fish, and sleuth-hounds. The most famous animal-human-technology would probably be Douglas Adams’ idea of the Babblefish. I’m also thinking of real-world examples, such as my friend Beatriz da Costa’s brilliant Pigeonblog. I could also mention Eduardo Kac’s piece currently down the street at Second Nature, entitled An Essay Concerning Human Understanding, although that might be more of a stretch since humans are only spectators to the apparatus. But in the same vein of the Pigeonblog or the Babblefish, I figure that it wouldn’t be all that hard to build a Snowy Tree Cricket counter, i.e. find the exact frequency pattern of the chirp, build some sort of physical, electronic, or algorithmic filter for that pattern, and then count it against a timer.

I just saw this on New Scientist: programming robots with strings. No, I’m not talking about character-based programming, nor am I talking about storing information in parallel dimensions as in M-Theory. I mean quite simply that you can use string (wire, rope, chain, vine, …) to program a robot. Better still, this system was designed in Alexandria all the way back in 60 A.D.

I mention this because I’m currently working on a larger framework for looking at programs and code as epiphenomena within a larger process called « physicalisation ». I have talked in the past about plant-based algorithms, and occasionally referenced tinkertoy computers, but I had yet to discover this fascinating rope method for programming. We’ll have to discuss this further in tomorrow’s plot.

If you just happen to be hanging out in Slovenia this weekend, don’t forget that tomorrow is the last day of the latest ENIAROF incarnation: Sloveniarof.

Last week, Friends of Ed. very nicely sent me a review copy of Ira Greenberg’s book Processing: Creative Coding and Computational Art (ISBN: 159059617X).

One of the questions I consistently have to field is « are there any good books to read if I want to learn Processing? ». My answer is usually, well, Casey Reas has a book coming out, as does Daniel Shiffman, and then there was some other book announced by Friends of Ed. Unfortunately none of them are out yet, but they will be soon… So Friends of Ed. is the first out of the gate apparently, and I know that Casey’s book has been finished for a few months. I also read a bit of Daniel’s book quite a while back and it too looked great, so I have feeling all three will be out in the next few weeks.

First, the good news: it’s a good book, written in a very clear style that I can comfortably recommend to my French students (oui, si vous arrivez à comprendre l’essentiel de ce blog, vous arriverez à comprendre ce livre). But even more important for me: it’s a big rugged book. It’s a learning book (as opposed to a reference book, such as Casey’s), so you might want to wait until it goes paperback, but as for us at the Atelier Hypermedia, we’ll be quite happy to have a big strong book to throw around. Especially when there are so many great recepies in there. We’ll be dog-earing many pages, meethinks. Chapter 11 on « Motion » is worth the price of admission alone: it gives you all the basics you need to know about making things move around using all the basic rules of gravity, collision, reflection, etc. And Chapter 13 is a fairly good introduction to d*3 that we will probably use as an introduction in the atelier. So all-in-all, it’s a good classroom book, which appears to be by design. You can easily teach around this book.

He also has a nice take on the basic « Hello World! » introduction to programming. Indeed, what is the equivalent of « Hello World! » in Processing? In electronics, that’s easy: a blinking LED. In 3D, tradition says that it’s a rotated cube. But in Processing? What’s the basic shape that says, hey, look, I too can draw shapes through code. Greenberg calls his version « Hello Earth! », and I like it:

Other good news: Ira Greenberg jumps right into object-oriented programming almost from the get-go. You learn about the environment and what buttons to push, you draw some lines, you draw some shapes and curves, and then you’re making objects. This might sound a little daunting, but it’s actually a necessary evil and the number-one mistake that I made in my currently whimpy on-line offering of Processing tutorials; a mistake I will promptly rectify before classes start in October. As we discovered this year, especially thanks to Pascal Chirol’s excellent diploma work, you can’t do anything interresting in Processing without a basic knowledge of objects.

That said, Greenberg’s actual use of objects in the book is a little thin. Chapter 9 and Chapter 10 each have a quick section near the end that gives some practical experience, but he rarely uses it in the rest of the examples that I explored. Although I have to admit that I didn’t read the book in it’s entirety, from my quick perusal it seemed to me that the examples don’t use objects enough. It would have been great to base pretty much everything you do after chapter 8 on object-oriented approaches. I find that what my students really need are real-world examples of not only how to use objects in programming, but also why you should use them and the general approach to using objects in your program. (Want to make a game? Start with the objects…) I know that’s a pretty tall order, one that an introduction to Processing might take a whole book to dispense, but I still find that it’s an important missing link for my students; i.e. one of those hurdles that once you get over it, everything seems to open up. But like I said, it’s rare to find an introduction to programming tutorial with so much use of object-oriented code (including my own), so I’m probably just being too picky.

Another complaint that I have is chapter 3, entitled « Code Grammar 101 ». It starts from good intentions: list all the syntax that will be used throughout the book, declaring variables, creating functions, loops, conditionals, conditional operators, relational operators, arrays, switches, ternary operators, while loops, do…while loops, … I hope you get my point: that’s an awful lot of stuff to learn before you actually do anything with the program! My method is exactly the opposite: open up the program, click here, click there, have fun, then go back and learn the basics; or even better yet, learn them while you’re having fun making stuff. Isn’t that what Processing was designed for anyway? I.e. getting started with a minimum of fuss?

Here’s my advice on how to read the book, and in fact my first assignment to my students that will be working with this book over the summer:

1. Open the book at Chapter 4 on page 59. Avoid the rest of the chapter…
2. Turn directly to Chapter 5 (page 144)
3. Read the rest of the book

There is also a nice annex at the end of the book giving some basic trigonomety, and a pretty damn good description of bit-level operations and why they can make your video analysis faster. I actually wish he would have explored this subject even more, but that’s okay, as I can take over from there, at least with those adventurous enough to make it out to Aix-en-Provence next semester.

Again on the positive side, there’s a good section on raster-image treatment, showing you all the basics of working with a photographic image. It even shows you how to export your results, instantly transforming you into an image-filter designer, à la Photoshop.

Strangely missing from this book are discussions of external libraries. This is normal I suppose, because you can’t really trust externals to stay put while a book is being published; one of the great things about having a stable release of Processing is that books can now comfortably be published without fear of unuseable code. Nevertheless, for my money Processing really takes off as an artistic tool when you’re outputting and inputting to and from various destinations and sources. We try to get to sound input, or video and PDF output almost from day one. The lack on an in-depth discussion of PDF export (in fact, I didn’t see any discussion of PDF, but I might be wrong) is actually very strange given the purely visual concentration of this book: all the examples are oriented to give you a basic understanding of how to draw stuff. If you’re drawing stuff, you probably want to print out to PDF at some point.

A nice follow up « expert » book might be how to take all this basic knowledge of drawing stuff and show how to plug it into everything else. Real World Processing, Processing vs. World, or whatever. Of course, this is the way we work at the Atelier Hypermedia already, and in fact how we intend to teach processing starting this October. Some of that material will be directly on-line, of course. How to make high resolution prints via PDF, importing real-time data on-the-fly from the Internets for a web-based visualizer, installing an interactive wall with a video projector and camera tracking, channeling Oscar Fischinger with the MovieMaker video exporter, creating a visualist set with live audio analysis, etc. Of course, that’s my approach, and maybe there’s a whole group of people out there that don’t want to know any of that and are perfectly happy drawing bouncy, spindly lines. And when it comes to drawing hundreds of wiggly, springy lines, this Processing book is perfectly competent, and even taught me a trick or two.

Thanks Ira! Thanks Friends of Ed.!

P.S. Note to students of the Atelier Hypermedia: don’t forget to download the files for the book which you will find in the on the editor’s website (link). Some of the code is pretty long, and not all that fun to input by hand. A lot of this code is cool, and is a pretty good sell for the book. The image below is a screenshot from one of the examples. The editors should have put up online applets of all this stuff, since it’s all based on basic Processing methods and therefore should all work within applets. But what do I know, I’m not a publisher.