If you’ve seen any reality zoo/wild-life program you’ll recognize this. Five minutes into the show you’re confronted with a wounded, magnificent animal, held in captivity so its caretakers can nurture and feed it. And inevitably, after three commercial breaks, they release it, teary-eyed, back into the wild. It’s a pivotal moment that turns their leopard into anyone’s/no one’s leopard. And as much as they like to see the animal run free, it hurts that only they know that that is the leopard that Bruce bottle-fed.
It’s similar with code. The moment you choose to release an algorithm, a technique, an idea, it’s no longer completely yours. It’s out there, free for everyone to do as they like. And chances are that in the end only a few people’ll know that that is the clever algorithm that Bruce came up with. Not because of malignant thievery, but because of Tumblr-like careless attribution.
Anyway, most of us don’t have to worry about this, I gladly share it all, because real innovation that’s truly worthy of attribution is rare. If someone’s uses hemesh, it’d be fun to be credited for the hard work that went into it. But I don’t need credit for the things that are created with it. Many other tools exist and in any case, it’s an implementation of an existing data structure. The thing is: anyone could’ve coded it…
There is however an idea, an algorithm out there that was shared by its creator Jonathan McCabe that is worthy of true attribution, that falls outside the realm of “anyone could’ve done it”. It’s been more than two years since I came across his multi-scale Turing patterns. They instantly intrigued me. And although I could recreate the gist of his images, I could never overcome the practical problems. In fact, the code proved hazardous to the elderly, infants and pregnant women. I thought my lack of numerical skill in tackling the huge equations I ran into was the problem. It was ponderously slow and I suspected Jonathan had a secret lair packed with supercomputers.
Turns out I was being silly. An almost incidental post on Flickr revealed that Jonathan has a paper on his cyclic symmetric multi-scale Turing patt.., what the hell, on his McCabeisms. And it’s full of DTC lines (A rarely needed acronym for “damn that’s clever”). Seems I wasn’t barking up the wrong tree, I was in the wrong forest, on the wrong continent, on the wrong planet… As if that wasn’t enough, Jason Rampe provides a blog post with useful pointers in implementing Jonathan’s idea. I say pointers, it’s actually more of a very elaborate pseudocode than a blog post. So the McCabeism is out there, ready to be implemented by anyone.
So I did, in Processing and thanks to Jason, it only took a few hours. This sketch is my small contribution to the free distribution of Jonathan’s very, very clever idea. It contains the basics as explained in the Softology blog post. I’ve added no explanations of my own. Jonathan’s paper and Jason’s post are very clear and definitely worth reading.
Feel free to use it in your own exploration of McCabeism. There’s plenty of room for experimentation. Capture it, dissect it, change it, mutate it, (now that’s a wildlife show I’d like to see) and above all attribute it to Jonathan McCabe…
What a wonderful post! Lots of laughs, and reverence emanating for the DTCs of Jonathan McCabe. Very well written, and intriguing to someone who knows a little too much to be good for her.
)
Well said. And Thanks for sharing.
thanks a ton, awesome post
is there a reason you wrote:
for (int di = –radius; di =0)?([something]):0;
}
instead of:
for (int di = 0; di <= radius; di++) {
total += [something];
}
this construct shows up a few times in TuringPattern
hmm that comment got chomped by whatever filter is running. but the question is basically: the for loop runs from –radius to +radius, but only operates on [0, +radius]. is there a reason for this?
I have been following Jonathan on flickr for months. I knew he had something when he posted his “bone art”. Way over my head, though.
Kyle: you’re right of course but that was left in because it’s a simplified implementation meant for clarity. To avoid all kinds of boundary side-effects you’ll need some kind of padded array, e.g. when applying rotation. In that case it’s useful to have a function value(i,j) instead of plain value[i][j]. So I left in the strange –radius to radius pattern and plugged the hole with some gratuitous ifs. Cheers!
hi frederik — just wanted to make sure i wasn’t missing something
thanks again for the implementation + notes! i ported it to openFrameworks and back to processing: http://openprocessing.org/visuals/?visualID=31195
Wondering if it’s worth it to give it a try and implement in AS3. Not sure how well can handle the intensive calculations.
@esimov, give Pixelbender a try! I’m already working on a GPU-accelerated version of Kyle’s awesome processing sketch — not for Flash though.
@Felix Woitzel
I saw your version, it’s truly amazing. Anyway i give it a try, and implemented in AS3 (not Pixelbender, however i think it would be much faster). Maybe some optimization should helped a little bit. Here it is my version: http://esimov.zxq.net/lab/AS3/TuringPattern.html
[…] Vanhoutte does some pretty incredible things with Processing. My favorite visual project of his is McCabeism: turning noise into a thing of beauty. It’s an algorithm created by Jonathan McCabe that was coded and realized by Vanhoutte, which […]