abstractmachine

28 December, 2007

registerDraw()

Filed under: atelier hypermedia, code — Douglas Edric Stanley @ 15:42 pm

If you look inside the Processing code, you’ll find a helpful little service that isn’t mentioned in the documentation: registerDraw(java.lang.Object o) & unregisterDraw(java.lang.Object o).

These two functions are particularly helpful if you’re working with multiple objects. For example, imagine you had a class for a bunch of circles dancing around the screen; i.e. something like this (Yes, I know, this code is lame; just bear with me.):

////////////////

class Circle {

  float x, y;

  Circle() {
    x = random(width);
    y = random(height);
  }

  void draw() {
    x = ((x + random(-1,1)) + width) % width;
    y = ((y + random(-1,1)) + height) % height;
    ellipse(x,y,11,11);
  }  

}

////////////////

You can then make twenty of these circles in your setup() as so :

////////////////

Circle[] circles = new Circle[20];

void setup() {
  size(256,256);
  for(int i=0; i<circles.length; ++i) circles[i] = new Circle();
}

////////////////

Now all you have to do is to call each and every one of those 20 circles in your draw() function through a for() loop :

////////////////

void draw() {
  background(255); 
  for(int i=0; i<circles.length; ++i) circles[i].draw();
}

////////////////

But there has to be a cleaner way, right? You already wrote void draw() inside of your class, why not just let Processing do all the work of calling each object’s draw() for you?

Here is a complete re-write of the above program, which makes it all a bit cleaner:

////////////////

Circle[] circles = new Circle[20];

void setup() {
  size(256,256);
  for(int i=0; i<circles.length; ++i) circles[i] = new Circle();
}

void draw() {
  
}

public class Circle {

  float x, y;

  Circle() {
    x = random(width);
    y = random(height);
    registerDraw(this);
  }

  void draw() {
    x = ((x + random(-1,1)) + width) % width;
    y = ((y + random(-1,1)) + height) % height;
    ellipse(x,y,11,11);
  }  

}

////////////////

abstractmachine registerDraw Processing example

Note how I have left the void draw() { } function completely empty. This is to show that the objects are all drawing themselves automatically. Why draw() at all, then? Well, you have to be careful here, because draw() is a required function, otherwise the Processing core will not animate your circles. There are other ways around this, but I usually leave the draw() in there, because it allows you to add a background(255), for example, to clear out the Sketch before drawing into it.

Also note, that the classes have to be declared public. I’ll explain more on this in my upcoming courses on objects and good practices. But for a short answer as to why the public keyword: your Sketch (called an applet) has ownership of all the objects declared inside of it. These are all private, i.e. only your own Sketch can call its own functions. In order for Java to automatically call all of your draw() functions within the objects, you have to declare them accessible (public) to the Processing core which does not have ownership of those objects. If all that sounds complicated (and even worse, I might have gotten some of that wrong — comments are welcome!), just forget it.

One eventually complicated part is determining in which order you will have the various objects drawn. This is very easy to control. You just registerDraw() in the order you want them to be drawn. Easy, non? And if you want to change their order? That’s easy too: just call unregisterDraw(); and re-register it. unregisterDraw() requires the address to the object, so you probably write something like this: unregisterDraw( circles[0] ); which would unregister the first circle. Again, if you don’t understand what I’m talking about, you probably should just ignore all this.

I suppose the most complicated part for beginners is the idea of this. I don’t really have the time to go into « this » right now. But again, for a quick explanation… this is a pointer to the object that contains the draw() routine you want auto-executed. Whenever you read this, the computer instead reads something else entirely: a specific memory address. Why? For simplicity (from the computer’s perspective at least) and control. Each object reads the same code from the class Circle, but each object has its own memory space containing its own variables for that code, as well as instructions on what it is supposed to do with those variables (defined by your class). You control these different objects by talking to them wherever they reside in your computer’s memory. The word « this » points to the address of that unique object. This address is what you need to give to registerDraw() and unregisterDraw() in order for the computer to know what to register or unregister.

Although I should point out that I have performed no speed tests on this method, I suspect it is nearly identical to calling each object yourself inside of your own draw() function. Looking in the Processing core would probably give me the answer, but I’m too lazy: hey, it’s the holidays. So why do I say it’s cleaner? Well, I like to use Processing’s tabs to hide away as much of the code complexity as I can in the far depths of the various classes. I’ve even started making classes inside of classes (ex: recent Wiimote class made during the Geneva workshop), so I don’t really want to be bothered with all that complexity once I’ve gotten it right. Processing is all about making code as simple as possible, non ?

25 December, 2007

Camouflage

Filed under: random — Douglas Edric Stanley @ 23:03 pm

For Christmas, we watched Le père noël est une ordure. This great shot got me thinking about camouflage. It also reminded me of Garden State, and my daughter suggested the drapes and wallpaper sequence in Steve Martin’s Pink Panther as well.

Le père noël est une ordure Garden State

24 December, 2007

YouTube Xmas Special

Filed under: random — Douglas Edric Stanley @ 14:25 pm

More YouTube playlist fun, just in time for the holidays. I didn’t spend too much time on it, but I hope you enjoy it nonetheless.

Let’s start with some Christmas Carols:

Skiing is fun, but be careful (and be sure to clean your skiis):

Shopping sucks, but here are some pointers:

Don’t forget your Christmas spirit! Here are some Christmas specials for reminders:

This Christmas, be sure to remember the environment:

And don’t forget the Jews!

The tree is always nice:

Lolcats like Christmas too:

Decorate your house, and bring out all the crazy contraptions:

Make sure you wear the suit right:

Opening Presents is fun:

How to deal with enjoy time with family:

Make a toast to all those you love:

All of which probably will lead to some indigestion:

16 December, 2007

the pixel as residue

Filed under: atelier hypermedia, live, abstractmachine, code — Douglas Edric Stanley @ 23:55 pm

My colleague Claire Renier invited me to speak on the subject of Painting and it’s « débordements » (overflows). Obviously for anyone who reads this blog, I cannot be considered an expert on the subject — so at first I declined. I have always been extremely weary of hasty approximations of artistic periods and mediums, especially when one is used in order to somehow validate the another. Digital Art has enough problems on its own, the last thing it needs is to start comparing itself to the institution of painting, which is exactly that: an institution, and no longer just a field within the visual arts. In fact the visual arts are often confused with painting, as if painting were its model.

But then I got to thinking and realized that there was something quite singular about painting, considered solely from the perspective of its temporality. Painting as a time machine. And the more I thought about it, the more the notion of the pixel started to open up onto this temporality, especially when you dislodge it from its role as mere discrete pictorial element. Pixels are directly mapped to memory space, which makes them all that much easier to manipulate discretely, but which also means that they inherit all of the temporal eccentricities of computer memory. Pixel fields can represent very complex juxtapositions of different temporal spaces, and even a single pixel can contain many temporal layers of superposition. It is quite revealing, for example, to observe how many contemporary code artists resort to mapping vectorial forms onto pixel spaces, precisely because they allow for richer visual forms thanks to the temporal dimensions that coexist in the pixels, as opposed to the near ascetic temporality of the vector graphics.

Anyway this fairly nebulous idea has been slowly baking in my mind recently, and I’ll attempt a first crack at it on Tuesday.

14 December, 2007

Typography Machines

Filed under: atelier hypermedia, code, i like — Douglas Edric Stanley @ 01:17 am

I’ve been in Switzerland all week, where I’ve mostly been teaching a coding workshop at the Post-Grade Immediat, but also trying to meet interesting people and see all sorts of things. On Tuesday, I was in Lausanne where I quickly visited the 2007 Swiss Federal Design Grants show at the mudac (museum of design). Most of the work was, well, uh, … but I absolutely fell in love with the Type Generator by Remo Caminada and Ludovic Innocent Varone. It feels very much like Jürg Lehni’s work, such as the Rubik Maker (cf. Scratchdisk), but it’s also its own beast, and one that could be quite useful if made available.

Type Generator, Remo Caminada and Ludovic Innocent Varone

The Type Generator is very Swiss – nice clear typography with a very cool interface – and yet there’s something strangely avant-garde about it. As its name states, it’s a type generation tool that allows you to sculpt fonts in real-time using all of the basics of type design. All of these parameters brought together, and automated in this way, makes for a very pleasant form of type design that felt more like I was assembling a skateboard or some strange Ikea furniture for which I had lost the manual — as opposed to designing a font. I only had the time to fiddle around with it for a few minutes, but already I want one!

This experimental typography project reminded me of a project Émilie Brout created recently with the help of Stéphane Cousot, entitled « Prise-en-Passant ». For a type nerd like me, it is almost better than The Type Generator : a combinatory typography system based on the moves of chess pieces on a chessboard during a match. Each piece represents one pixel component of a fairly traditional bitmapped font, but which can only use the legal moves of the game of chess in order to fall into place. In the beginning, the user begins with a fairly complete set of chess pieces that arrange themselves on the blank page into a more or less complete starting glyph.

Prise-en-passant, Émilie Brout

But as you move from character to character within the text, the pieces struggle more and more to arrange themselves into the correct positions legally, making the text ever more illegible and subsequently even harder for the remaining pieces to populate the next character, and so on. If this makes no sense to you, check out the Prise-en-passant page which describes the whole process much better than I just did, or else you can watch the following video which shows Émilie playing with the system :

If the name Émilie Brout sounds familiar, it’s because she made one of the better attractions at ENIAROF 0.2, the very fun Pitch-Pong where FFT sound analysis meets William Higinbothom’s Tennis for Two.

Update: Émilie has just pointed me to an applet of her installation that will run inside of your browser: http://la-nuit-tombe.net/prog/pep.html.

7 December, 2007

pixels^3

Filed under: exhibition, abstractmachine, code, instrument, play — Douglas Edric Stanley @ 01:08 am

Les Pixels 2

Quick post for one of the quickest exhibits I’ve ever had to prepare. I’ll be exhibiting ^3 (aka Cubed) at Les Pixels, an exhibition that opens in Beauvais today. Where’s Beauvais you ask? I have no idea, but who the hell cares when it’s THE authentic « Ville Internet @@@@ 2007 » ? (Love that logo!) It’s a tiny festival, by a young non-profit with the right attitude, so I said what the hell. Who needs sleep anyway?

5 December, 2007

Immédiat

Filed under: workshop, atelier hypermedia, abstractmachine, code — Douglas Edric Stanley @ 21:21 pm

After a very pleasant meeting with the professors and students of design in Marseille last friday, I’ll now be traveling back to see my friends in Geneva at the art & design school where I’ll run another three-day workshop. So far, we don’t know exactly where it’s going to go — as always I like to keep it open — but we have decided to work from the perspective of visualist performance. So that will probably mean making visual algorithms that relate to live sound input. I’ll see how far we can push that purely technical configuration, and will probably construct some temporary concept to give us a more theoretical framework to work from.

You can see the work we did at the last two workshops in the design section of the school : Ooo and Play!. Those went very well, but apparently the school has changed quite a bit, so I’m looking forward to seeing how this new melding of the art & design schools is coming along.

I love Switzerland (and the Swiss). They have this wonderful speed at which they work — a speed that most French find maddening, because the tempo is just a tiny notch beneath their own.

My favorite Swiss moment was on my way to my first day of teaching at the design school. I was nearby, but couldn’t find the street. I stopped into a local shop and asked for directions. « Hmmm. Je crois la connaître, regardons… » the fellow said, and pulled out a map. He then proceeded to first unfold the map, and then to my amazement fold it up again, only folding it in a very specific way such that he was able to show me the precise position of my target.

The idea is very simple, and almost identical to any other map you might know. In any old dopey map you have letters (A-Z) on the vertical sides of the map, and numbers (1-666) along the horizontal sides. The problem is that you have to hold the map open with two hands, and then use the fingers of your other two hands (or your feet, I suppose) to follow those coordinates in a straight line until you end up crossing at the street you want. But the Swiss are obsessive with the little details, and in such a way that probably explains why most French people find them quaint. The Swiss have letters on the sides of their maps too, only the numbers are printed on the back of their maps. Get it? You fold the map at the letter indicated in the street index, and this lines up the bottom backside of your map precisely at the horizontal position you’re interested in. Then you follow that edge’s numbering system horizontally and bingo, you’ve got your street.

So first you have to imagine that the A-Z number does not give you the row you’re interested in, it gives you the fold you’re interested in, in order to line up the bottom of the map and your street. Very clever, that. Too bad I can’t find any pictures on the Internet to show you what I’m talking about. I’ll have to bring one back with me.

Oh, and did I mention that the typography on that map was to die for?