Bespoke computing

I was hoping to post this as a reply to a post on Martin Stall's blog. Unfortunately one of the short comings of his blog engine is that comments are limited to 'length 500'.

Martin,

I've been reading your blog for a while and am quite interested in how you tackled this question. As a computer programmer who spends much of his free time creating 'computer art', I'd like to add some thoughts to this discussion.

You ask if a machine can produce anything better than a copy. Lets say, for the time being, that it cannot. However any copy that it makes is immaculate. If I were to purchase a suit from you that I was overjoyed with, would I value having a 100% identical replica of it? Absolutely. I could rotate between wearing the original and the copy and halve the wear on the suit! Or if I were to have a terrible computer related accident and tore my suit irreparably, I would be safe in the knowledge that I had an identical replacement.

However, if someone gave me a 100% identical copy of Vase with Twelve Sunflowers, painted by computer with the exact same strokes, paint and aged canvas, would it be as valuable as the original? Probably not. The owner of the original knows that they have the original and mine is a copy (even if they can't tell the two apart). The value from the work comes from the fact that is was made by the hand of Van Gogh, and no more like it will ever be produced by that hand. Indeed there is value that arises from the physical work (paint + canvas), but the astronomical price is due to the intangible fact that it is unique.

I am not denying that this latter element is not a component of the price of bespoke suits, but I feel that the majority of the price comes from the quality of materials, construction and attention to the unique needs of the client. Imagine the thought experiment: you tailor a suit for me for the price of, lets say, $3000. You see that I am happy with the suit and decide to offer me an identical suit for $2000. The lower price of the second suit due to the fact that you no longer need to make initial measurements or adjustments. Now imagine that I accept your offer and return the next week to pick up these two suits. At this point I can no longer tell that one is 'worth' $3000, whilst the other is merely worth $2000. Because, after handing you $5000 for the pair, they are both worth $2500 to me.

Thus far, your reply has placed the value of a bespoke suit on the art of the tailor in designing an appropriate piece for the client. I am quite happy to accept that modern cutting and sewing technology is currently unable to capture the intricacies of a tailor’s hand. But let us assume that one day this arrives. In which case a tailor could produce the original, and machines could produce duplicates for a single client. Perhaps you may be kind enough to let this technology cope with different fabrics. Even so, a single client would never want more than possibly one or two copies of any single design. Fashions change; bodies accumulate mass and posture and position change. I am not familiar with the breakdown of bespoke suit prices, but if we imagine that 30% goes towards the labor of production (rather than the labor of 'art'), we at best may reduce suit prices by a fraction through duplication.

The real question is to whether technology can ever measure and notice enough about the client to have enough information to make a suit. Following the gathering of information we would need some technology to design the suit -- the creative genius, if you will. Rather than approaching this by tackling the measurement and then the design phase, let me limit my following discussion to the question of whether a computer could design a suit, given suitable measurements. I choose this approach because I am certain that your answer to this would be 'Never!'

My answer is 'Yes!' And the reason why I am so confident in this is that people often forget computers do not run by themselves. Software developers make computer software and software developers are people. And for examples of this I turn to the world of computer art, where artists use software as a medium. They take their aesthetic and use programs as a mode of creative outlet. While the majority of this work is in the graphic mode, artists around the world are writing software to generate music, sculpture, landscapes, etc.

Artistic expression is never limited by the medium. Whilst oils provide one set of opportunities and watercolours provide a different set, no one would say that watercolour is not art whilst oil is. Creative expression can and does flourish in many unexpected places. And there is no reason to think that computer software is not a valid creative outlet. Just as it took centuries for those working with cloth to establish techniques and artistic idioms, computer generated art is evolving and every day practitioners are refining their works.

I strongly believe that computers are capable of design, as they are guided by the hand of people who write the software.

Thanks again for a great blog, and keep cutting!

Josh Reich

Coding from the outside

Nico commented on The Bug, saying that he tends to put more discipline into his leisure time coding than he might put into his work. Although my original post might give you the idea that my own leisure time coding is an undisciplined mess, this is not entirely the case. I have one rule that helps to keep my code re-usable, well designed, on target and generally clean: Code from the outside.

If I am writing audio code, I'll write as much as possible without connecting a soundcard. Likewise, I will not link against bit blitting libraries until most of my graphics code is done. This is somewhat similar to starting with test cases, but not as strict. It means writing your code, manually inspecting the output and debugging without getting caught up with artifacts.

I originally learnt this when I was doing a rotation at a remote hospital back in Melbourne. I had borrowed my father's laptop but never got the obscure soundcard working with my Linux install and so when I decided to write a synth, I could only check the output when I returned home after a few months. Despite the fairly taxing nature of working the ER of a small country hospital, I was able to get a few hours of coding done every few days. It was a good escape from tractor related injuries and whatnot. Aside from my computer, I had a copy of some audio synthesis text, which was later to be stolen by a sound engineer when I left medicine to work in post production; but that's a story for another day.

Long story short, I was able to code up the system as I had intended and I wasn't distracted by the output along the way. In the past, whenever I wrote music in software, I'd get caught up in the sounds and spend hours tweaking my code, iterating between code and output. Along the way I would forget my original intent and would end up focused on aesthetics. While this is mildly pleasing, it is not as pleasurable as sticking to your original question and answering it.

At the time my original question was "What would sounds generated by drawing a vector spectrogram sound like?". In the end, the answer was something along the lines of "Crap", but at least I learnt that. If I was hooked into a soundcard, I would have been too concerned with making something that didn't sound crap that I would have never answered my original question.

I also find that when coding directly to output, I get caught into the trap of finding bugs in the output and guessing what the underlying cause is rather than properly diagnose the problem. It is much easier to find bugs in text output than it is with audio or visual output. I think that I am smart enough to look at a complex rendering output snafu and say "Duh. Off by one error". The truth is that I am not that smart and despite this I end up randomly adding +/- 1 to an iterator somewhere and seeing if that fixes the problem. I'm somewhat simplifying the situation, but I think all coders have similar behavior. It's much harder to lie to yourself when you can clearly see the underlying mechanisms in operation.

When opaque debugging coincides with a certain aesthetic I find myself adding one to an iterator, looking at the output and being surprised by the output and saying "Wow. That's kinda cool. What if I add 2?!" Two hours later, after clocking my iterators to sin((i % 17) * 0.01), my rendering looks amazing, but nothing like what I originally intended. While this might be OK if I'm working on an animation for its own sake, but this is rarely the case. Better to separate the aesthetic phase from the analytic phase.

Or so I say anyway.


In unrelated news, Dan is blogging. Watch that space.

The Planet of Leather Moomins

TPOLM is having YALS (Yet Another Lazy Sunday!)!



When: 3rd December 7006
Where: www://lazy.sunday.tpolm.internet/
Thanks: Nico for bringing this event to my attention. You will be rewarded.

Bespoke Captcha

Being the half-hearted fashion snob that I am, I read a few blogs by European bespoke tailors. While I can neither afford their services nor making any constructive comments about their posts, I do feel somewhat comfortable with saying that bespoke security measures are, by definition, a failure.

Lets examine the source for confirmation:

<input type='text' name='submit_random_code_disable' style='width:100%' value='CqDI' disabled> 
</td><input type='hidden' name='submit_random_code_org' value='CqDI'></tr><tr>
<td>Random Code Verification</td><td>
<input type=text name='submit_random_code_verify' style='width:100%'>

Excuse me while I go home and hand sew a floating canvass in my RTW coat.

The Bug

Whenever I interview programmers I always ask about their involvement with coding projects outside of their work. For the most part, the best programmers I have worked with code in their spare time. While I like to hear from candidates who contribute to open source projects, my eyes light up whenever someone says "No. Well, actually, I am currently working on something, but its a silly little thing, just a program to simulate people playing black jack." These little programs turn me on because they are not motivated by a desire to design something useful or to 'fit in' with other developers but rather because the coder wants to attack some abstract problem for the sole purpose of edification. When hiring, I want more than candidates who know how to solve problems. I want candidates who want to solve problems for the sake of solving problems. It isn't so much about walking away with the solution, but walking away with the process.

Since Coming to America I can count on my hands the number of times I've thrown myself into the deep end to tackle a problem like this. On my left hand was an algorithmic synthesizer I wrote over my first thanksgiving in Pittsburgh. More recently, on my right hand, I have my radiosity shader. Neither of these tools solved problems that hadn't been solved more elegantly by others. In both cases I was pretty sure that I could write something, but after completing them I dropped the modifier and was 100% sure that I could - and this was my primary motivation, to know that I could do it. In both cases my external motivation was the demo scene, where like-minded individuals write code to generate animations. The 'scene' provides a great outlet for me, even if I rarely actually participate in competitions, as I can write code where the beauty arises from the process rather than the specific solution.

I would like to participate in more competitions, but my previous collaborators are all back in Australia, and I don't have the same group focus to get things actually finished. I get to a point whereby I am happy with having solved the problem of interest, and don't have a group of friends to help me shape it into an entry. But until I rekindle that focus, I am building my tool chest one painful weekend at a time.

Such weekends are painful for all the reasons why you don't want a dev team that works the same way they code on weekends. Yeah, its cool to get an amazing amount of stuff done in a short period of time but I feel god awful today. With a long weekend starting on Friday, I had no qualms staying up to 4am working on my rendering engine. I went to bed having knocked off a bug that had been bothering me all day and could sleep soundly knowing that it was out of the way. I woke up relatively early on Saturday (read: 2pm) and got back to coding. By 6am Sunday, I was desperate for a repeat of the previous night's performance and was randomly changing lines of code in the hope of fixing another bug. All the while I knew that if I just went to bed the solution would come as soon as I woke. But on the other hand I knew that getting to sleep would be a pain with a bug still out in the wild. By the time the sun came up I had given up and was restless in bed, but fell asleep quickly. After 5 hours of sleep I woke up and fixed my bug in an instant.

For all the progress I made over the weekend I am somewhat upset by my lack of efficiency. The only thing that can turn an otherwise intelligent, mature and upstanding member of society into a
shut-in spaghetti coder is The Bug. The same drive that sends one person on a three day bender in Vegas sends me to forgo personal hygiene and get intimate with pixels. But like the fully functional junkie, I know when to step away, have a shave and make myself purty for another week at work.

This week I won't touch my code. I need to give it some time and space to breathe (c.f. bit rot. I need to remove myself and remember the original problem I was trying to solve (make pretty pictures) and the more important meta-problem (make pretty pictures out of the process, rather than the result).

jd-osity

I have been pretty busy at work lately and I've been using my spare time to cut code, so I haven't been blogging much. Unlike some people who write useful code in their spare time, I like to solve problems that other people have solved in much smarter ways. Recently I've been working on a radiosity rendering engine. Unlike most modern radiosity engines, I don't rely on anything apart from my CPU. Most people these days do radiosity in almost-real-time using lots of neat GPU (graphics card) tricks. I'm a bit of an old fuddy duddy, and like to do things the hard way and am shooting for real time without any GPU tricks. So far I have got the code to almost work right. After I clean up a few kinks I'll start optimizing (beyond the simple tricks I'm currently using).

I'm keeping a scatch pad at i2pi