countercomplex

IBNIZ - a hardcore audiovisual virtual machine and an esoteric programming language

2011-12-30T00:20:00.010Z

Some days ago, I finished the first public version of my audiovisual virtual machine, IBNIZ. I also showed it off on YouTube with the following video:

As demonstrated by the video, IBNIZ (Ideally Bare Numeric Impression giZmo) is a virtual machine and a programming language that generates video and audio from very short strings of code. Technically, it is a two-stack machine somewhat similar to Forth, but with the major execption that the stack is cyclical and also used at an output buffer. Also, as every IBNIZ program is implicitly inside a loop that pushes a set of loop variables on the stack on every cycle, even an empty program outputs something (i.e. a changing gradient as video and a constant sawtooth wave as audio).

How does it work?

To illustrate how IBNIZ works, here's how the program ^xp is executed, step by step:

So, in short: on every loop cycle, the VM pushes the values T, Y and X. The operation ^ XORs the values Y and X and xp pops off the remaining value (T). Thus, the stack gets filled by color values where the Y coordinate is XORed by the X coordinate, resulting in the ill-famous "XOR texture".

The representation in the figure was somewhat simplified, however. In reality, IBNIZ uses 32-bit fixed-point arithmetic where the values for Y and X fall between -1 and +1. IBNIZ also runs the program in two separate contexts with separate stacks and internal registers: the video context and the audio context. To illustrate this, here's how an empty program is executed in the video context:

The colorspace is YUV, with the integer part of the pixel value interpreted as U and V (roughly corresponding to hue) and the fractional part interpreted as Y (brightness). The empty program runs in the so-called T-mode where all the loop variables -- T, Y and X -- are entered in the same word (16 bits of T in the integer part and 8+8 bits of Y and X in the fractional). In the audio context, the same program executes as follows:

Just like in the T-mode of the video context, the VM pushes one word per loop cycle. However, in this case, there is no Y or X; the whole word represents T. Also, when interpreting the stack contents as audio, the integer part is ignored altogether and the fractional part is taken as an unsigned 16-bit PCM value.

Also, in the audio context, T increments in steps of 0000.0040 while the step is only 0000.0001 in the video context. This is because we need to calculate 256x256 pixel values per frame (nearly 4 million pixels if there are 60 frames per second) but suffice with considerably fewer PCM samples. In the current implementation, we calculate 61440 audio samples per second (60*65536/64) which is then downscaled to 44100 Hz.

The scheduling and main-looping logic is the only somewhat complex thing in IBNIZ. All the rest is very elementary, something that can be found as instructions in the x86 architecture or as words in the core Forth vocabulary. Basic arithmetic and stack-shuffling. Memory load and store. An if/then/else structure, two kinds of loop structures and subroutine definition/calling. Also an instruction for retrieving user input from keyboard or pointing device. Everything needs to be built from these basic building blocks. And yes, it is Turing complete, and no, you are not restricted to the rendering order provided by the implicit main loop.

The full instruction set is described in the documentation. Feel free to check it out experiment with IBNIZ on your own!

So, what's the point?

The IBNIZ project started in 2007 with the codename "EDAM" (Extreme-Density Art Machine). My goal was to participate in the esoteric programming language competition at the same year's Alternative Party, but I didn't finish the VM at time. The project therefore fell to the background. Every now and then, I returned to the project for a short while, maybe revising the instruction set a little bit or experimenting with different colorspaces and loop variable formats. There was no great driving force to insppire me to finish the VM until mid-2011 after some quite succesful experiments with very short audiovisual programs. Once some of my musical experiments spawned a trend that eventually even got a name of its own, "bytebeat", I really had to push myself to finally finishing IBNIZ.

The main goal of IBNIZ, from the very beginning, was to provide a new platform for the demoscene. Something without the usual fallbacks of the real-world platforms when writing extremely small demos. No headers, no program size overhead in video/audio access, extremely high code density, enough processing power and preferrably a machine language that is fun to program with. Something that would have the potential to displace MS-DOS as the primary platform for sub-256-byte demoscene productions.

There are also other considerations. One of them is educational: modern computing platforms tend to be mind-bogglingly complex and highly abstracted and lack the immediacy and tangibility of the old-school home computers. I am somewhat concerned that young people whose mindset would have made them great programmers in the eighties find their mindset totally incompatible with today's mainstream technology and therefore get completely driven away from programming. IBNIZ will hopefully be able to serve as an "oldschool-style platform" in a way that is rewarding enough for today's beginninng programming hobbyists. Also, as the demoscene needs all the new blood it can get, I envision that IBNIZ could serve as a gateway to the demoscene.

I also see that IBNIZ has potential for glitch art and livecoding. By taking a nondeterministic approach to experimentation with IBNIZ, the user may encounter a lot of interesting visual and aural glitch patterns. As for livecoding, I suspect that the compactness of the code as well as the immediate visibility of the changes could make an IBNIZ programming performance quite enjoyable to watch. The live gigs of the chip music scene, for example, might also find use for IBNIZ.

About some design choices and future plans

IBNIZ was originally designed with an esoteric programming language competition in mind, and indeed, the language has already been likened to the classic esoteric language Brainfuck by several critical commentators. I'm not that sure about the similarity with Brainfuck, but it does have strong conceptual similarities with FALSE, the esoteric programming language that inspired Brainfuck. Both IBNIZ and FALSE are based on Forth and use one-character-long instructions, and the perceived awkwardness of both comes from unusual, punctuation-based syntax rather than deliberate attempts at making the language difficult.

When contrasting esotericity with usefulness, it should be noted that many useful, mature and well-liked languages, such as C and Perl, also tend to look like total "line noise" to the uninitiated. Forth, on the other hand, tends to look like mess of random unrelated strings to people unfamiliar with the RPN syntax. I therefore don't see how the esotericity of IBNIZ would hinder its usefulness any more than the usefulness of C, Perl or Forth is hindered by their syntaxes. A more relevant concern would be, for example, the lack of label and variable names in IBNIZ.

There are some design choices that often get questioned, so I'll perhaps explain the rationale for them:

The colors: the color format has been chosen so that more sensible and neutral colors are more likely than "coder colors". YUV has been chosen over HSV because there is relatively universal hardware support for YUV buffers (and I also think it is easier to get richer gradients with YUV than with HSV).
Trigonometric functions: I pondered for a long while whether to include SIN and ATAN2 and I finally decided to do so. A lot of demoscene tricks depend, including all kinds of rotating and bouncing things as well as more advanced stuff such as raycasting, depends on the availability of trigonometry. Both of these operations can be found in the FPU instruction set of the x86 and are relatively fundamental mathematical stuff, so we're not going into library bloat here.

Floating point vs fixed point: I considered floating point for a long while as it would have simplified some advanced tricks. However, IBNIZ code is likely to use a lot of bitwise operations, modular bitwise arithmetic and indefinitely running counters which may end up being problematic with floating-point. Fixed point makes the arithmetic more concrete and also improves the implementability of IBNIZ on low-end platforms that lack FPU.
Different coordinate formats: TYX-video uses signed coordinates because most effects look better when the origin is at the center of the screen. The 'U' opcode (userinput), on the other hand, gives the mouse coordinates in unsigned format to ease up pixel-plotting (you can directly use the mouse coordinates as part of the framebuffer memory address). T-video uses unsigned coordinates for making the values linear and also for easier coupling with the unsigned coordinates provided by 'U'.

Right now, all the existing implementations of IBNIZ are rather slow. The C implementation is completely interpretive without any optimization phase prior to execution. However, a faster implementation with some clever static analysis is quite high on the to-do list, and I expect a considerable performance boost once native-code JIT compilers come into use. After all, if we are ever planning to displace MS-DOS as a sizecoding platform, we will need to get IBNIZ to run at least faster than DOSBOX.

The use of externally-provided coordinate and time values will make it possible to scale a considerable portion of IBNIZ programs to a vast range of different resolutions from character-cell framebuffers on 8-bit platforms to today's highest higher-than-high-definition standards. I suspect that a lot of IBNIZ programs can be automatically compiled into shader code or fast C-64 machine language (yes, I've made some preliminary calculations for "Ibniz 64" as well). The currently implemented resolution, 256x256, however, will remain as the default resolution that will ensure compatibility. This resolution, by the way, has been chosen because it is in the same class with 320x200, the most popular resolution of tiny MS-DOS demos.

At some point of time, it will also become necessary to introduce a compact binary representation of IBNIZ code -- with variable bit lengths primarily based on the frequency of each instruction. The byte-per-character representation already has a higher code density than the 16-bit x86 machine language, and I expect that a bit-length-optimized representation will really break some boundaries for low size classes.

An important milestone will be a fast and complete version that runs in a web brower. I expect this to make IBNIZ much more available and accessible than it is now, and I'm also planning to host an IBNIZ programming contest once a sufficient web implementation is on-line. There is already a Javascript implementation but it is rather slow and doesn't support sound, so we will still have to wait for a while. But stay tuned!

Materiality and the demoscene: when does a platform feel real?

2011-11-15T21:57:00.007Z

I've just finished reading Daniel Botz's 428-page PhD dissertation "Kunst, Code und Maschine: Die Ästhetik der Computer-Demoszene".

The book is easily the best literary coverage of the demoscene I've seen so far. It is basically a history of demos as an artform with a particular emphasis on the esthetical aspects of demos, going very deeply into different styles and techniques and their development, often in relation to the features of the three "main" demoscene platforms (C-64, Amiga and PC).

What impressed me the most in the book and gave me most food for thought, however, was the theoretical insight. Botz uses late Friedrich Kittler's conception of media materiality as a theoretical device to explain how the demoscene relates to the hardware platforms it uses, often contrasting the relationship to that of the mainstream media art. In short: the demoscene cares about the materiality of the platforms, while the mainstream art world ignores it.

To elaborate: mainstream computer artists regard computers as tools, universal "anything machines" that can translate pure, immaterial, technology-independent ideas into something that can be seen, heard or otherwise experienced. Thus, ideas come before technology. Demosceners, however, have an opposite point of view; for them, technology comes before ideas. A computer platform is seen as a material that can be brought into different states, in a way comparable to how a sculptor brings blocks of stone into different forms. The possibilities of a material can be explored with direct, uncompromising interaction such as low-level programming. The platform is not neutral, its characteristics are essential to what demos written for it end up being like. While a piece of traditional computer art can often be safely removed from its specific technological context, a demo is no longer a demo if the platform is neglected.

The focus on materiality also results in a somewhat unusual relationship with technology. For most people, computer platforms are just evolutionary stages on a timeline of innovation and obsolescence. A device serves for a couple of years before getting abandoned in favor of a new model that is essentially the same with higher specs. The characteristics of a digital device boil down to numerical statistics in the spirit of "bigger is better". The demoscene, however, sees its platforms as something more multi-faceted. An old computer or gaming console may be interesting as an artistic material just because of its unique combination of features and limitations. It is fine to have historical, personal or even political reasons for choosing a specific platform, but they're not necessary; the features of the system alone are enough to grow someone's creative enthusiasm. As so many people misunderstand the relationship between demoscene and old hardware as a form of "retrocomputing", it is very delightful to see such an accurate insight to it.

But is it really that simple?

I'm not entirely familiar with the semantic extent of "materiality" in media studies, but it is apparent that it primarily refers to physicality and concreteness. In many occasions, Botz contrasts materiality against virtuality, which, I think, is an idea that stems from Gilles Deleuze. This dichotomy is simple and appealing, but I disagree with Botz in how central it is to what the demoscene is doing. After all, there are, for example, quite many 8-bit-oriented demoscene artists who totally approve virtualization. Artists who don't care whether their works are shown with emulators or real hardware at parties, as long as the logical functionality is correct. Some even produce art for the C-64 without having ever owned a material C-64. Therefore, virtualization is definitely not something that is universally frowned upon on the demoscene. It is apparently also possible to develop a low-level, concrete material relationship with an emulated machine, a kind of "material" that is totally virtual to begin with!

Computer programming is always somewhat virtual, even in its most down-to-the-metal incarnations. Bits aren't physical objects; concentrations of electrons only get the role of bits from how they interact with the transistors that form the logical circuits. A low-level programmer who strives for a total, optimal control of a processor doesn't need to be familiar with these material interactions; just knowing the virtual level of bits, registers, opcodes and pipelines is enough. The number of abstraction layers between the actual bit-twiddling and the layer visible to the programmer doesn't change how programming a processor feels like. A software emulator or an FPGA reimplementation of the C-64 can deliver the same "material feeling" to the programmer as the original, NMOS-based C-64. Also, if the virtualization is perfect enough to model the visible and audible artifacts that stem from the non-binary aspects of the original microchips, even a highly experienced enthusiast can be fooled.

I therefore think it is more appropriate to consider the "feel of materiality" that demosceners experience to stem from the abstract characteristics of the platform than its physicality. Programming an Atari VCS emulator running in an X86 PC on top of an operating system may very well feel more concrete than programming the same PC directly with the X86 assembly language. When working with a VCS, even a virtualized one, a programmer needs to be aware of the bit-level machine state at all times. There's no display memory in the VCS; the only way to draw something on the screen is by telling the processor to put specific values in specific video chip registers at specific clock cycles. The PC, however, does have a display memory that holds the pixel values of the on-screen picture, as well as a video chip that automatically refreshes its contents to the screen. A PC programmer can therefore use very generic algorithms to render graphics in the display memory without caring about the underlying hardware, while on the VCS everything needs to be thought out from the specific point of view of the video chip and the CPU.

It seems that the "feel of materiality" has particularly much to do with complexity -- of both the platform and the manipulated data. A high-resolution picture, taking up megabytes of display memory, looks nearly identical on a computer screen regardless of whether it is internally represented in RGB or YUV colorspace. However, when we get a pixel artist to create versions of the same picture for various formats that use less than ten kilobytes of display memory, such as PC textmode or C-64 multicolor, the specific features and constraints of each format shine out very clearly. High levels of complexity allow for generic, platform-independent and general-purpose techniques whereas low levels of complexity require the artist to form a "material relationship" with the format.

Low complexity and the "feel of materiality" are also closely related to the "feel of total control" which I regard as an important state that demosceners tend to reach for. The lower the complexity of a platform, the easier it is to reach a total understanding of its functionality. Quite often, coders working on complex platforms choose to deliberately lower the perceived complexity by concentrating on a reduced, "essential" subset of the programming interface and ignoring the rest. Someone who codes for a modern PC, for example, may want to ignore the polygonal framework of the 3D API altogether and exclusively concentrate on shader code. Those who write softsynths, even for tiny size classes, tend to ignore high-level synthesis frameworks that may be available on the OS and just use a low-level PCM-soundbuffer API. Subsets that provide nice collections of powerful "Lego blocks" are the way to go. Even though bloated system libraries may very well contain useful routines that can be discovered and abused in things like 4-kilobyte demos, most democoders frown upon this idea and may even consider it cheating.

Emulators, virtual platforms and reduced programming interfaces are ways of creating pockets of lowered complexity within highly complex systems -- pockets that feel very "material" and controllable for a crafty programmer. Even virtual platforms that are highly abstract, idealistic and mathematical may feel "material". The "oneliner music platform", merely defined as C-like expression syntax that calculates PCM sample values, is a recent example of this. All of its elements are defined on a relatively high level, no specification of any kind of low-level machine, virtual or otherwise. Nevertheless, a kind of "material characteristic" or "immanent esthetics" still emerges from this "platform", both in how the sort formulas tend to sound like and what kind of hacks and optimizations are better than others.

The "oneliner music platform" is perhaps an extreme example, but in general, purely virtual platforms have been there for a while already. Things like Java demos, as well as multi-platform portable demos, have been around since the late 1990s, although they've usually remained quite marginal. For some reason, however, Botz seems to ignore this aspect of the demoscene nearly completely, merely stating that multi-platform demos have started to appear "in recent years" and that the phenomenon may grow bigger in the future. Perhaps this is a deliberate bias chosen to avoid topics that don't fit well within Botz's framework. Or maybe it's just an accident. I don't know.

Conclusion

To summarize: when Botz talks about the materiality of demoscene platforms, he often refers to phenomena that, in my opinion, could be more fruitfully analyzed with different conceptual devices, especially complexity. Wherever the dichotomy of materiality and immateriality comes up, I see at least three separate conceptual dimensions working under the hood:

1. Art vs craft (or "idea-first" vs "material-first"). This is the area where Botz's theory works very well: demoscene is, indeed, more crafty or "material-first" than most other communities of computer art. However, the material (i.e. the demo platform) doesn't need to be material (i.e. physical); the crafty approach works equally well with emulated and purely virtual platforms. The "artsy" approach, leading to conceptual and "avant-garde" demos, has gradually become more and more accepted, however there's still a lot of crafty attitude in "art demos" as well. I consider chip musicians, circuit-benders and homebrew 8-bit developers about as crafty on average as demosceners, by the way.

2. Physicality vs virtuality. There's a strong presence of classic hardware enthusiasm on the demoscene as well as people who build their own hardware, and they definitely are in the right place. However, I don't think the physical hardware aspect is as important in the demoscene as, for example in the chip music, retrogaming and circuit-bending communities. On the demoscene, it is more important to demonstrate the ability to do impressive things in limited environments than to be an owner of specific physical gear or to know how to solder. A C-64 demo can be good even if it is produced with an emulator and a cross-compiler. Also, as demo platforms can be very abstract and purely virtual as well and still be appealing to the subculture, I don't think there's any profound dogma that would drive demosceners towards physicality.

3. Complexity. The possibility of forming a "material relationship" with an emulated platform shows that the perception of "materiality", "physicality" and "controllability" is more related to the characteristics of the logical platform than to how many abstraction layers there are under the implementation. A low computational complexity, either in the form of platform complexity or program size, seems to correlate with a "feeling of concreteness" as well as the prominence of "emergent platform-specific esthetics". What I see as the core methodology of the demoscene seems to work better at low than high levels of complexity and this is why "pockets of lowered complexity" are often preferred by sceners.

Don't take me wrong: despite all the disagreements and my somewhat Platonist attitude to abstract ideas in general, I still think virtuality and immateriality have been getting too much emphasis in today's world and we need some kind of a countercultural force that defends the material. Botz also covers possible countercultural aspects of the demoscene, deriving them from the older hacker culture, and I found all of them very relevant. My basic disagreement comes from the fact that Botz's theory doesn't entirely match with how I perceive the demoscene to operate, and the subculture as a whole cannot therefore be put under a generalizing label such as "defenders and lovers of the materiality of the computer".

Anyway, I really enjoyed reading Botz's book and especially appreciated the theoretical insight. I recommend the book to everyone who is interested in the demoscene, its history and esthetic variety, AND who reads German well. I studied the language for about five years at school but I still found the text quite difficult to decipher at places. I therefore sincerely hope that my problems with the language haven't led me to any critical misunderstandings.

Some deep analysis of one-line music programs.

2011-10-28T16:18:00.015+01:00

It is now a month since I posted the YouTube video "Experimental music from very short C programs" and three weeks since I blogged about it. Now that the initial craze seems to be over, it's a good time to look back what has been done and consider what could be done in the future.

The developments since my last post can be summarized by my third video. It still represents the current state of the art quite well and includes a good variety of different types of formulas.

The videos only show off a portion of all the formulas that could be included. To compensate, I've created a text file where I've collected all the "worthy" formulas I've encountered so far. Most of them can be tested in the on-line JavaScript and ActionScript test tools. Some of them don't even work directly in C code, as they depend on JS/AS-specific features.

As I'm sure that many people still find these formulas rather magical and mysterious, I've decided to give you a detailed technical analysis and explanation on the essential techniques. As I'm completely self-educated in music theory, please pardon my notation and terminology that may be unorthodox at times. You should also have a grasp of C-like expression syntax and binary arithmetic to understand most of the things I'm going to talk about.

I've sorted my formula collection by length. By comparing the shortest and longest formulas, it is apparent that the longest formulas show a much more constructivist approach, including musical data stored in constants as well as entire piece-by-piece-constructed softsynths. The shortest formulas, on the other hand, are very often discovered via non-deterministic testing, from educated guesses to pure trial-and-error. One of my aims with this essay is to bring some understanding and determinism to the short side as well.

Pitches and scales

A class of formulas that is quite prominent among the shortest ones is what I call the 't* class'. The formulas of this type multiply the time counter t with some expression, resulting in a sawtooth wave that changes its pitch according to that expression.

A simple example of a t*-class formula would be t*(t>>10) which outputs a rising and falling sound (accompanied by some aliasing artifacts that create their own sounds). Now, if we introduce an AND operator to this formula, we can restrict the set of pitches and thus create melodies. An example that has been individually discovered by several people, is the so-called "Forty-Two Melody": t*(42&t>>10) or t*2*(21&t>>11).

The numbers that indicate pitches are not semitones or anything like that, but multiplies of a base frequency (sampling rate divided by 256, i.e. 31.25 Hz at the default 8 kHz rate). Here is a table that maps the integer pitches 1..31 to cents and Western note names. The pitches on a gray background don't have good counterparts in the traditional Western system, so I've used quarter-tone flat and sharp symbols to give them approximate names.

By using this table, we can decode the Forty-Two Melody into a human-readable form. The melody is 32 steps long and consists of eight unique pitch multipliers (including zero which gives out silence).

The "Forty-Two Melody" contains some intervals that make it sound a little bit silly, detuned or "Arabic" to Western ears. If we want to avoid this effect, we need to design our formulas so that they only yield pitches that are at familiar intervals from one another. A simple solution is to include a modulo operator to wrap larger numbers to the range where simple integer ratios are more probable. Modifying the Forty-Two Melody into t*((42&t>>10)%14), for example, completely transforms the latter half of the melody into something that sounds a little bit nicer to Western ears. Bitwise AND is also useful for limiting the pitch set to a specific scale; for example t*(5+((t>>11)&5)) produces pitch multipliers of 4, 5, 8 and 9, which correspond to E3, G3, C4 and D4.

Ryg's 44.1 kHz formula presented in the third video contains two different melody generators:

((t*("36364689"[t>>13&7]&15))/12&128)

+(((((t>>12)^(t>>12)-2)%11*t)/4|t>>13)&127)

The first generator, in the first half of the formula, is based on a string constant that contains a straight-forward list of pitches. This list is used for the bass pattern. The other generator, whose core is the subexpression ((t>>12)^(t>>12)-2)%11, is more interesting, as it generates a rather deep self-similar melody structure with just three operators (subtraction, exclusive or, modulo). Rather impressive despite its profound repetitiveness. Here's an analysis of the series it generates:

It is often a good idea to post-process the waveform output of a plain t* formula. The sawtooth wave tends to produce a lot of aliasing artifacts, particularly at low sampling rates. Attaching a '&128' or '&64' in the end of a t* formula switches the output to square wave which usually sounds a little bit cleaner. An example of this would be Niklas Roy's t*(t>>9|t>>13)&16 which sounds a lot noisier without the AND (although most of the noise in this case comes from the unbounded multiplication arithmetic, not from aliasing).

Bitwise waveforms and harmonies

Another class of formulas that is very prominent among the short ones is the bitwise formula. At its purest, such a formula only uses bitwise operations (shifts, negation, AND, OR, XOR) combined with constants and t. A simple example is t&t>>8 -- the "Sierpinski Harmony". Sierpinski triangles appear very often in plotted visualizations of bitwise waveforms, and t&t>>8 represents the simplest type of formula that renders into a nice Sierpinski triangle.

Bitwise formulas often sound surprisingly multitonal for their length. This is based on the fact that an 8-bit sawtooth wave can be thought of consisting of eight square waves, each an octave apart from its neighbor. Usually, these components fuse together in the human brain, forming the harmonics of a single timbre, but if we turn them on and off a couple of times per second or slower, the brain might perceive them as separate tones. For example, t&48 sounds quite monotonal, but in t&48&t>>8, the exactly same waveform sounds bitonal because it abruptly extends the harmonic content of the previous waveform.

The loudest of the eight square-wave components of an 8-bit wave is, naturally, the one represented by the most significant bit (&128). In the sawtooth wave, it is also the longest in wavelength. The second highest bit (&64) represents a square wave that has half the wavelength and amplitude, the third highest halves the parameters once more, and so on. By using this principle, we can analyze the musical structure of the Sierpinski Harmony:

The introduction of ever lower square-wave components can be easily heard. One can also hear quite well that every newly introduced component is considerably lower in pitch than the previous one. However, if we include a prime multiplier in the Sierpinski Harmony, we will encounter an anomaly. In (t*3)&t>>8, the loudest tone actually goes higher at a specific point (and the interval isn't an octave either).

This phenomenon can be explained with aliasing artifacts and how they are processed by the brain. The main wavelength in t*3 is not constant but alternates between two values, 42 and 43, averaging to 42.67 (256/3). The human mind interprets this kind of sound as a waveform of the average length (42.67 samples) accompanied by an extra sound that represents the "error" (or the difference from the ideal wave). In the t*3 example, this extra sound has a period of 256 samples and sounds like a buzzer when listened separately.

The smaller the wavelengths we are dealing with are, the more prominent these aliasing artifacts become, eventually dominating over their parent waveforms. By listening to (t*3)&128, (t*3)&64 and (t*3)&32, we notice an interval of an octave between them. However, when we step over from (t*3)&32 to (t*3)&16, the interval is definitely not an octave. This is the threshold where the artifact wave becomes dominant. This is why t&t>>8, (t*3)&t>>8 and (t*5)&t>>8 sound so different. It is also the reason why high-pitched melodies may sound very detuned.

Variants of the Sierpinski harmony can be combined to produce melodies. Examples of this approach include:

t*5&(t>>7)|t*3&(t*4>>10) (from miiro)

(t*5&t>>7)|(t*3&t>>10) (from viznut)

t*9&t>>4|t*5&t>>7|t*3&t/1024 (from stephth)

Different counters are the driving force of bitwise formulas. At their simplest, counters are just bitshifted versions of the main counter (t). These are implicitly synchronized with each other and work on different temporal levels of the musical piece. However, it has also been fruitful to experiment with counters that don't have a simple common denominator, and even with ones whose speeds are nearly identical. For example, t&t%255 brings a 256-cycle counter and a 255-cycle counter together with an AND operation, resulting in an ambient drone sound that sounds like something achievable with pulse-width modulation. This approach seems to be more useful for loosely structured soundscapes than clear-cut rhythms or melodies.

Some oneliner songs attach a bitwise operation to a melody generator for transposing the output by whole octaves. A simple example is Rrrola's t*(0xCA98>>(t>>9&14)&15)|t>>8 which would just loop a simple series of notes without the trailing '|t>>8'. This part gradually fixes the upper bits of the output to 1s, effectively raising the pitch of the melody and fading its volume out. Also the formulas from Ryg and Kb in my third video use this technique. The most advanced use of it I've seen so far, however, is in Mu6k's song (the last one in the 3rd video) which synthesizes its lead melody (along with some accompanying beeps) by taking the bassline and selectively turning its bits on and off. This takes place within the subexpression (t>>8^t>>10|t>>14|x)&63 where the waveform of the bass is input as x.

Modular wrap-arounds and other synthesis techniques

All the examples presented so far only use counters and bitwise operations to synthesize the actual waveforms. It's therefore necessary to talk a little bit about other operations and their potential as well.

By accompanying a bitwise formula with a simple addition or substraction, it is possible to create modular wrap-around artifacts that produce totally different sounds. Tiny, nearly inaudible sounds may become very dominant. Harmonious sounds often become noisy and percussive. By extending the short Sierpinski harmony t&t>>4 into (t&t>>4)-5, something that sounds like an "8-bit" drum appears on top of it. The same principle can also be applied to more complex Sierpinski harmony derivatives as well as other bitwise formulas:

(t*9&t>>4|t*5&t>>7|t*3&t/1024)-1

I'm not going into a deep analysis of how modular wrap-arounds affect the harmonic structure of a sound, as I guess someone has already done the math before. However, modular addition can be used for something that sounds like oscillator hard-sync in analog synthesizers, although its technical basis is different.

Perhaps the most obvious use for summing in a softsynth, however, is the one where modular wrap-around is not very useful: mixing of several sound sources together. A straight-forward recipe for this is (A&127)+(B&127), which may be a little long-winded when aiming at minimalism. Often, just a simple XOR operation is enough to replace it, although it usually produces artifacts that may sound good or bad depending on the case. XOR can also be used for effects that sound like hard-sync.

Of course, modular wrap-around effects are also achievable with multiplication and division, and on the other hand, even without addition or subtraction. I'll illustrate this with just a couple of interesting-sounding examples:

t>>4|t&((t>>5)/(t>>7-(t>>15)&-t>>7-(t>>15))) (from droid, js/as only)

(int)(t/1e7*t*t+t)%127|t>>4|t>>5|t%127+(t>>16)|t (from bst)

t>>6&1?t>>5:-t>>4 (from droid)

There's a lot in these and other synthesis algorithms that could be discussed, but as they already belong to a zone where traditional sound synthesis lore applies, I choose to go on.

Deterministic composition

When looking at the longest formulas in the collection, it is apparent that there's a lot of intelligent design behind most of them. Long constants and tables, sometimes several of them, containing scales, melodies, basslines and drum patterns. The longest formula in the collection is "Long Line Theory", a cover of the soundtrack of the 64K demo "Chaos Theory" by Conspiracy. The original version by mu6k was over 600 characters long, from which the people on Pouet.net optimized it down to 300 characters, with some arguable quality tradeoffs.

It is, of course, possible to synthesize just about anything with a formula, especially if there's no upper limit for the length. Synthesis and sequencing logic can be built section by section, using rather generic algorithms and proven engineering techniques. There's no magic in it. But on the other hand, there's no magic in pure non-determinism either: it is very difficult to find anything outstanding with totally random experimentation after the initial discovery phase is over.

Many of the more sophisticated formulas seem to have a good balance between random experimentation and deterministic composition. It is often apparent in their structure that some elements are results of random discoveries while others have been built with an engineer's mindset. Let's look at Mu6k's song (presented in the end of the 3rd video, 32 kHz):

(((int)(3e3/(y=t&16383))&1)*35) +

(x=t*("6689"[t>>16&3]&15)/24&127)*y/4e4 +

((t>>8^t>>10|t>>14|x)&63)

I've split the formula on three lines according to the three instruments therein: drum, bass and lead.

My assumption is that the song has been built around the lead formula that was discovered first, probably in the form of t>>6^t>>8|t>>12|t&63 or something (the original version of this formula ran at 8 kHz). As usual with pure bitwise formulas, all the intervals are octaves, but in this case, the musical structure is very nice.

As it is possible to transpose a bit-masking melody simply by transposing the carrier wave, it's a good idea to generate a bassline and reuse it as the carrier. Unlike the lead generator, the bassline generator is very straight-forward in appearance, consisting of four pitch values stored in a string constant. A sawtooth wave is generated, stored to a variable (so that it can be reused by the lead melody generator) and amplitude-modulated.

Finally, there's a simple drum beat that is generated by a combination of division and bit extraction. The extracted bit is scaled to the amplitude of 35. Simple drums are often synthesized by using fast downward pitch-slides and the division approach does this very well.

In the case of Ryg's formula I discussed some sections earlier, I might also guess that the melody generator, the most chaotic element of the system, was the central piece which was later coupled with a bassline generator whose pitches were deliberately chosen to harmonize with the generated melody.

The future

I have been contacted by quite many people who have brought up different ideas of future development. We should, for example, have a social website where anyone could enter new formulas, listen to the in a playlist-like manner and rate them. Another branch of ideas is about the production of new rateable formulas by random generation or by breeding old ones together with genetic algorithms.

All of these ideas are definitely interesting, but I don't think the time is yet right for them. I have been developing my audiovisual virtual machine, which is the main reason why I did these experiments in the first place. I regard the current concept of "oneliner music" as a mere placeholder for the system that is yet to be released. There are too many problems with the C-like infix syntax and other aspects of the concept, so I think it's wiser to first develop a better toy and then think about a community mechanism. However, these are just my own priorities. If someone feels like building the kind of on-line community I described, I'll support the idea.

I've mentioned this toy before. It was previously called EDAM, but now I've chosen to name it IBNIZ (Ideally Bare Numeric Impression giZmo). One of the I letters could also stand for "immediate" or "interactive", as I'm going to emphasize an immediate, hands-on modifiability of the code. IBNIZ will hopefully be relevant as a demoscene platform for extreme size classes, as a test bed for esoteric algorithmic trickery, as an appealing introduction to hard-core minimalist programming, and also as a fun toy to just jam around with. Here's a little screenshot of the current state:

In my previous post, I mentioned the possibility of opening a door for 256-byte demos that are interesting both graphically and musically. The oneliner music project and IBNIZ will provide valuable research for the high-level, algorithmic aspects of this project, but I've also made some

hands-on tests on the platform-level feasability of the idea. It is now apparent that a stand-alone MS-DOS program that generates PCM sound and synchronized real-time graphics can easily fit in less then 96 bytes, so there's a lot of room left for both music and graphics in the 256-byte size

class. I'll probably release a 128- or 256-byte demo as a proof-of-concept, utilizing something derived from a nice oneliner music formula as the soundtrack.

I would like to thank everyone who has been interested in the oneliner music project, as all the hype made me very determined to continue my quests for unleashing the potential of the bit and the byte. My next post regarding this quest will probably appear once there's a version of IBNIZ worth releasing to the public.

Algorithmic symphonies from one line of code -- how and why?

2011-10-02T14:15:00.003+01:00

Lately, there has been a lot of experimentation with very short programs that synthesize something that sounds like music. I now want to share some information and thoughts about these experiments.

First, some background. On 2011-09-26, I released the following video on Youtube, presenting seven programs and their musical output:

This video gathered a lot of interest, inspiring many programmers to experiment on their own and share their findings. This was further boosted by Bemmu's on-line Javascript utility that made it easy for anyone (even non-programmers, I guess) to jump in the bandwagon. In just a couple of days, people had found so many new formulas that I just had to release another video to show them off.

Edit 2011-10-10: note that there's now a third video as well! http://www.youtube.com/watch?v=tCRPUv8V22o

It all started a couple of months ago, when I encountered a 23-byte C-64 demo, Wallflower by 4mat of Ate Bit, that was like nothing I had ever seen on that size class on any platform. Glitchy, yes, but it had a musical structure that vastly outgrew its size. I started to experiment on my own and came up with a 16-byte VIC-20 program whose musical output totally blew my mind. My earlier blog post, "The 16-byte frontier", reports these findings and speculates why they work.

Some time later, I resumed the experimentation with a slightly more scientific mindset. In order to better understand what was going on, I needed a simpler and "purer" environment. Something that lacked the arbitrary quirks and hidden complexities of 8-bit soundchips and processors. I chose to experiment with short C programs that dump raw PCM audio data. I had written tiny "/dev/dsp softsynths" before, and I had even had one in my email/usenet signature in the late 1990s. However, the programs I would now be experimenting with would be shorter and less planned than my previous ones.

I chose to replicate the essentials of my earlier 8-bit experiments: a wave generator whose pitch is controlled by a function consisting of shifts and logical operators. The simplest waveform for /dev/dsp programs is sawtooth. A simple for(;;)putchar(t++) generates a sawtooth wave with a cycle length of 256 bytes, resulting in a frequency of 31.25 Hz when using the the default sample rate of 8000 Hz. The pitch can be changed with multiplication. t++*2 is an octave higher, t++*3 goes up by 7 semitones from there, t++*(t>>8) produces a rising sound. After a couple of trials, I came up with something that I wanted to share on an IRC channel:

main(t){for(t=0;;t++)putchar(t*(((t>>12)|(t>>8))&(63&(t>>4))));}

In just over an hour, Visy and Tejeez had contributed six more programs on the channel, mostly varying the constants and changing some parts of the function. On the following day, Visy shared our discoveries on Google+. I reshared them. A surprising flood of interested comments came up. Some people wanted to hear an MP3 rendering, so I produced one. All these reactions eventually led me to release the MP3 rendering on Youtube with some accompanying text screens. (In case you are wondering, I generated the screens with an old piece of code that simulates a non-existing text mode device, so it's just as "fakebit" as the sounds are).

When the first video was released, I was still unsure whether it would be possible for one line of C code to reach the sophistication of the earlier 8-bit experiments. Simultaneities, percussions, where are they? It would also have been great to find nice basslines and progressions as well, as those would be useful for tiny demoscene productions.

At some point of time, some people noticed that by getting rid of the t* part altogether and just applying logical operators on shifted time values one could get percussion patterns as well as some harmonies. Even a formula as simple as t&t>>8, an aural corollary of "munching squares", has interesting harmonic properties. Some small features can be made loud by adding a constant to the output. A simple logical operator is enough for combining two good-sounding formulas together (often with interesting artifacts that add to the richness of the sound). All this provided material for the "second iteration" video.

If the experimentation continues at this pace, it won't take many weeks until we have found the grail: a very short program, maybe even shorter than a Spotify link, that synthesizes all the elements commonly associated with a pop song: rhythm, melody, bassline, harmonic progression, macrostructure. Perhaps even something that sounds a little bit like vocals? We'll see.

Hasn't this been done before?

We've had the technology for all this for decades. People have been building musical circuits that operate on digital logic, creating short pieces of software that output music, experimenting with chaotic audiovisual programs and trying out various algorithms for musical composition. Mathematical theory of music has a history of over two millennia. Based on this, I find it quite mind-boggling that I have never before encountered anything similar to our discoveries despite my very long interest in computing and algorithmic sound synthesis. I've made some Google Scholar searches for related papers but haven't find anything. Still, I'm quite sure that at many individuals have come up with these formulas before, but, for some reason, their discoveries remained in obscurity.

Maybe it's just about technological mismatch: to builders of digital musical circuits, things like LFSRs may have been more appealing than very wide sequential counters. In the early days of the microcomputer, there was already enough RAM available to hold some musical structure, so there was never a real urge to simulate it with simple logic. Or maybe it's about the problems of an avant-garde mindset: if you're someone who likes to experiment with random circuit configurations or strange bit-shifting formulas, you're likely someone who has learned to appreciate the glitch esthetics and never really wants to go far beyond that.

Demoscene is in a special position here, as technological mismatch is irrelevant there. In the era of gigabytes and terabytes, demoscene coders are exploring the potential of ever shorter program sizes. And despite this, the sense of esthetics is more traditional than with circuit-benders and avant-garde artists. The hack value of a tiny softsynth depends on how much its output resembles "real, big music" such as Italo disco.

The softsynths used in the 4-kilobyte size class are still quite engineered. They often use tight code to simulate the construction of an analog synthesizer controlled by a stored sequence of musical events. However, as 256 bytes is becoming the new 4K, there has been ever more need to play decent music in the 256-byte size class. It is still possible to follow the constructivist approach in this size class -- for example, I've coded some simple 128-byte players for the VIC-20 when I had very little memory left. However, since the recent findings suggest that an approach with a lot of random experimentation may give better results than deterministic hacking, people have been competing in finding more and more impressive musical formulas. Perhaps all this was something that just had to come out of the demoscene and nowhere else.

Something I particularly like in this "movement" is its immediate, hands-on collaborative nature, with people sharing the source code of their findings and basing their own experimentation on other people's efforts. Anyone can participate in it and discover new, mind-boggling stuff, even with very little programming expertise. I don't know how long this exploration phase is going to last, but things like this might be useful for a "Pan-Hacker movement" that advocates hands-on hard-core hacking to greater masses. I definitely want to see more projects like this.

How profound is this?

Apart from some deterministic efforts that quickly bloat the code up to hundreds of source-code characters, the exploration process so far has been mostly trial-and-error. Some trial-and-error experimenters, however, seem to have been gradually developing an intuitive sense of what kind of formulas can serve as ingredients for something greater. Perhaps, at some time in the future, someone will release some enlightening mathematical and music-theoretical analysis that will explain why and how our algorithms work.

It already seems apparent, however, that stuff like this stuff works in contexts far beyond PCM audio. The earlier 8-bit experiments, such as the C-64 Wallflower, quite blindly write values to sound and video chip registers and still manage to produce interesting output. Media artist Kyle McDonald has rendered the first bunch of sounds into monochrome bitmaps that show an interesting, "glitchy" structure. Usually, music looks quite bad when rendered as bitmaps -- and this applies even to small chiptunes that sound a lot like our experiments, so it was interesting to notice the visual potential as well.

I envision that, in the context of generative audiovisual works, simple bitwise formulas could generate source data not only for the musical output but also drive various visual parameters as a function of time. This would make it possible, for example, for a 256-byte demoscene production to have an interesting and varying audiovisual structure with a strong, inherent synchronization between the effects and the music. As the formulas we've been experimenting with can produce both microstructure and macrostructure, we might assume that they can be used to drive low-level and high-level parameters equally well. From wave amplitudes and pixel colors to layer selection, camera paths, and 3D scene construction. But so far, this is mere speculation, until someone extends the experimentation to these parameters.

I can't really tell if there's anything very profound in this stuff -- after all, we already have fractals and chaos theory. But at least it's great for the kind of art I'm involved with, and that's what matters to me. I'll probably be exploring and embracing the audiovisual potential for some time, and you can expect me to blog about it as well.

Edit 2011-10-29: There's now a more detailed analysis available of some formulas and techniques.

A new propaganda tool: Post-Apocalyptic Hacker World

2011-09-07T13:11:00.000+01:00

I visited the Assembly demo party this year, after two years of break. It seemed more relevant than in a while, because I had an agenda.

For a year or so, I have been actively thinking about the harmful aspects of people's relationships with technology. It is already quite apparent to me that we are increasingly under the control of our own tools, letting them make us stupid and dependent. Unless, of course, we promote a different world, a different way of thinking, that allows us to remain in control.

So far, I've written a couple of blog posts about this. I've been nourishing myself with the thoughts of prominent people such as Jaron Lanier and Douglas Rushkoff who share the concern. I've been trying to find ways of promoting the aspects of hacker culture I represent. Now I felt that the time was right for a new branch -- an artistic one based on a fictional

world.

My demo "Human Resistance", that came 2nd in the oldskool demo competition, was my first excursion into this new branch. Of course, it has some echoes of my earlier productions such as "Robotic Liberation", but the setting is new. Instead of showing ruthless machines genociding the helpless mankind, we are dealing with a culture of ingenious hackers who manage to outthink a superhuman intellect that dominates the planet.

"Human Resistance" was a relatively quick hack. I was too hurried to fix the problems in the speech compressor or to explore the real potential of Tau Ceti -style pseudo-3D rendering. The text, however, came from my heart, and the overall atmosphere was quite close to what I intended. It introduces a new fictional world of mine, a world I've temporarily dubbed "Post-Apocalyptic Hacker World" (PAHW). I've been planning to use this world not only in demo productions but also in at least one video game. I haven't released anything interactive for like fifteen years, so perhaps it's about time for a game release.

Let me elaborate the setting of this world a little bit.

Fast-forward to a post-singularitarian era. Machines control all the resources of the planet. Most human beings, seduced by the endless pleasures of procedurally-generated virtual worlds, have voluntarily uploaded their minds into so-called "brain clusters" where they have lost their humanity and individuality, becoming mere components of a global superhuman intellect. Only those people with a lot of willpower and a strong philosophical stance against dehumanization remained in their human bodies.

Once the machines initiated an operation called "World Optimization", they started to regard natural formations (including all biological life) as harmful and unpredictable externalities. As a result, planet Earth has been transformed into something far more rigid, orderly and geometric. Forests, mountains, oceans or clouds no longer exist. Strange, lathe-like artifacts protrude from vast, featureless plains. Those who had studied ancient pop culture immediately noticed a resemblance to some of the 3D computer graphics of the 1980s. The real world has now started to look like the computed reality of Tron or the futuristic terrains of video games such as Driller, Tau Ceti and Quake Minus One.

Only a tiny fraction of biological human beings survived World Optimization. These people, who collectively call themselves "hackers", managed to find and exploit the blind spots of algorithmic logic, making it possible for them to establish secret, self-relying underground fortresses where human life can still struggle on. It has become a necessity for all human beings to dedicate as much of their mental capacities as possible to outthinking the brain clusters in order to eventually conquer them.

Many of the tropes in Post-Apocalyptic Hacker World are quite familiar. A human resistance movement fighting against a machine-controlled world, haven't we seen this quite many times already? Yes, we have, but I also think my approach is novel enough to form a basis for some cutting-edge social, technological and political commentary. By emphasizing things like the role of total cognitive freedom and radical understanding of things' inner workings in the futuristic hacker culture, it may be possible to get people realize their importance in the real world as well. It is also quite possible to include elements from real-life hacker cultures and mindsets in the world, effectively adding to their interestingness.

The "PAHW game" (still without a better title) is already in an advanced stage of pre-planning. It is going to become a hybrid CRPG/strategy game with random-generated worlds, very loose scripting and some very unique game-mechanical elements. This is just a side project so it may take a while before I have anything substantial to show, but I'll surely let you know once I have. Stay tuned!

Don't submit yourself to a game machine!

2011-07-24T09:45:00.000+01:00

(This is a translation of a post in my Finnish blog)

Some generations ago, when people said they were playing a game, they usually meant a social leisure activity that followed a commonly decided set of rules. The devices used for gaming were very simple, and the games themselves were purely in the minds of the players. It was possible to play thousands of different games with a single constant deck of cards, and it was possible for anyone to invent new games and variants.

Technological progress brought us "intelligent" gaming devices that reduced the possibility of negotiation. It is not possible to suggest an interesting rule variant to a pinball machine or a one-handed bandit; the machine only implements the rules it is built for. Changing the game requires technical skill and a lot of time, something most people don't have. As a matter of fact, most people aren't even interested in the exact rules of the game, they just care about the fun.

Nowadays, people have submitted ever bigger portions of their lives to "gaming machines" that make things at least superficially easier and simpler, but whose internal rules they don't necessarily understand at all. A substantial portion of today's social interaction in developed countries, for example, takes place in on-line social networking services. Under their hoods, these services calculate things like message visibility -- that is, which messages and whose messages are supposed to be more important for a given user. For most people, however, it seems to be completely OK that a computer owned by a big, distant corporation makes such decisions for them using a secret set of rules. They just care about the fun.

It has always been easy to use the latest media to manipulate people, as it takes time from the audience to develop criticism. When writing was a new thing, most people would regard any text as a "word of God" that was true just because it was written. In comparison, today's people have a thick wall of criticism against any kind of non-interactive propaganda, be that textual, aural or visual, but whenever a game-like interaction is introduced, we often become completely vulnerable. In short, we know how to be critical about an on-line news items but not how to be critical about the "like" and "share" buttons under them.

Video games, in many ways, surpasses traditional passive media in the potential of mental manipulation. A well-known example is the so-called Tetris effect caused by a prolonged playing of a pattern-matching game. The game of Tetris "programs" its player to constantly analyze the on-screen wall of blocks and mentally fit different types of tetrominos in it. When a player stops playing after several hours, the "program" may remain active, causing the player to continue mentally fitting tetrominos on outdoor landscapes or whatever they see in their environment. Other kinds of games may have other kinds of effects. I have personally also experienced an "adventure game effect" that caused me to unwillingly think about real-world things and locations from the point of view of "progressing in the script". Therefore, I don't think it is a very far-fetched idea that spending a lot of time on an interactive website gives our brains a permission to adapt to the "game mechanics" and unnoticeably alter the way how we look at the world.

So, is this a real threat? Are they already trying to manipulate our minds in game-mechanical means, and how? There has been perhaps even too much criticism of Facebook compared to other social networking sites, but I'm now it as an example as it is currently the most familiar one for the wide audience.

As many people probably understand already, Facebook's customer base doesn't consist of the users (who pay nothing for the service) but of marketeers who want their products to be sold. The users can be thought as mere raw material that can be refined to better fit the requirements of the market. This is most visible in the user profile mechanic that encourages users to define themselves primarily with multiple choices and product fandom. The only space in the profile that allows for a longer free text has been laid below all the "more important things". Marketeers don't want personal profile pages but realiable statistics, high-quality consumption habit databases and easily controllable consumers.

The most prominent game-mechanical element in Facebook is "Like", which affects nearly everything on the site. It is a simple and easily processable signal whose use is particularly encouraged. In its internal game, Facebook scores users according to how active "likers" they are, and gives more visibility to the messages of those users that score higher. Moderate users of Facebook, who use their whole brain to consider what to "Like" or not or what to share and not, gain less points and less visibility. This is how Facebook rewards the "virtuous" users and punishes the "sinful" ones.

What about those users who actually want to understand the inner workings of the service, in order to use it better for their own purposes? Facebook makes this very difficult, and I believe it is on purpose. The actual rules of the game haven't been documented anywhere, so users need to follow intuitive guesses or experiment with the thing. If a user actually manages to reverse-engineer part of the black box, he or she can never trust that it continues to work in the same way. The changes in the rules of the internal game can be totally unpredictable. This discourages users from even trying to understand the game they are playing and encourages them to trust the control of their private lives to the computers of a big, distant company.

Of course, Facebook is not representative of all forms of on-line sociality. The so-called imageboards, for example, are diagonally opposite to Facebook in many areas: totally uncommercial and simple-to-understand sites where real names or even pseudonyms are rarey used. As these sites function totally differently from Facebook, it can be guessed that they also affect their users' brains in a different way.

Technically, imageboards resemble discussion boards, but with the game-mechanical difference that they encourage a faster, more spontaneous communication which usually feels more like a loud attention-whoring contest than actual discussion. A lot of the imageboard culture can be explained as mere consequences of the mechanics. The fact that images are often more prominent than text in threads makes it possible for users to superficially skim around the pictures and only focus on the parts that seize their attention. This contributes to the fast tempo that invites the users to react very quickly and spontaneously, usually without any means of identification, as if as part of a rebellious mob. The belief in radical anonymity and hivemind power have ultimately become some kind of core values of the imageboard culture.

The possibility of anonymous commentary gives us a much greater sense of freedom than we get by using our real name or even a long-term pseudonym. Anonymous provocateurs don't need to be afraid of losing their face. They feel free to troll around from the bottom of their heart, looking for moments of "lulz" they get by heating someone up. The behavior is probably familiar to anyone who has been reading anonymous comments on news websites or toilet walls. Imageboards just take this kind of behavior to its logical extreme, basing all of its social interaction on a spontaneous mob behavior.

Critics of on-line culture, such as Lanier and Rushkoff, have often expressed their concern of how on-line socialization trivializes our view of other people. Instead of interacting with living people with rich personalities, we seem to be increasingly dealing with lists, statistics and faceless mobs who we interact with using "Like", "Block" and "Add Friend" buttons. I'm also concerned about this. Even when someone rationally understands on the rational level that this is just an abstraction required by the means of communication to work, we may accidentally and unnoticeably become programmed by the "Tetris effects" of these media. Awareness and criticism may very well reduce the risk, but I don't believe they can make anyone totally immune.

So, what can we do? Should we abandon social networking sites altogether to save the humanity of the human race? I don't think denialism helps anything. Instead, we should learn how to use the potential of interactive social technology in constructive rather than destructive means. We should develop new game mechanics that, instead of promoting collective stupidity and dehumanization, augment the positive sides of humanity and encourage us to improve ourselves. But is this anything great masses could become interested in? Do they any longer care about whether they remain as independent individuals? Perhaps not, but we can still hope for the best.

The 16-byte frontier: extreme results from extremely small programs.

2011-06-21T19:14:00.000+01:00

While mainstream software has been getting bigger and more bloated year after year, the algorithmic artists of the demoscene have been following the opposite route: building ever smaller programs to generate ever more impressive audiovisual show-offs.

The traditional competition categories for size-limited demos are 4K and 64K, limiting the size of the stand-alone executable to 4096 and 65536 bytes, respectively. However, as development techniques have gone forward, the 4K size class has adopted many features of the 64K class, or as someone summarized it a couple of years ago, "4K is the new 64K". There are development tools and frameworks specifically designed for 4K demos. Low-level byte-squeezing and specialized algorithmic beauty have given way to high-level frameworks and general-purpose routines. This has moved a lot of "sizecoding" activity into more extreme categories: 256B has become the new 4K. For a fine example of a modern 256-byter, see Puls by Rrrrola.

The next hexadecimal order of magnitude down from 256 bytes is 16 bytes. Yes, there are some 16-byte demos, but this size class has not yet established its status on the scene. At the time of writing this, the smallest size category in the pouet.net database is 32B. What's the deal? Is the 16-byte limit too tight for anything interesting? What prevents 16B from becoming the new 256B?

Perhaps the most important platform for "bytetros" is MS-DOS, using the no-nonsense .COM format that has no headers or mandatory initialization at all. Also, in .COM files we only need a couple of bytes to obtain access to most of the vital things such as the graphics framebuffer. At the 16-byte size class, however, these "couples of bytes" quickly fill up the available space, leaving very little room for the actual substance. For example, here's a disassembly of a "TV noise" effect (by myself) in fifteen bytes:

addr  bytes     asm
0100  B0 13     MOV AL,13H
0102  CD 10     INT 10H
0104  68 00 A0  PUSH A000H
0107  07        POP ES
0108  11 C7     ADC DI,AX
010A  14 63     ADC AL,63H
010C  AA        STOSB
010D  EB F9     JMP 0108H

The first four lines, summing up to a total of eight bytes, initialize the popular 13h graphics mode (320x200 pixels with 256 colors) and set the segment register ES to point in the beginning of this framebuffer. While these bytes would be marginal in a 256-byte demo, they eat up a half of the available space in the 16-byte size class. Assuming that the infinite loop (requiring a JMP) and the "putpixel" (STOSB) are also part of the framework, we are only left with five (5) bytes to play around with! It is possible to find some interesting results besides TV noise, but it doesn't require many hours from the coder to get the feeling that there's nothing more left to explore.

What about other platforms, then? Practically all modern mainstream platforms and a considerable portion of older ones are out of the question because of the need for long headers and startup stubs. Some platforms, however, are very suitable for the 16-byte size class and even have considerable advantages over MS-DOS. The hardware registers of the Commodore 64, for example, are more readily accessible and can be manipulated in quite unorthodox ways without risking compatibility. This spares a lot of precious bytes compared to MS-DOS and thus opens a much wider space of possibilities for the artist to explore.

So, what is there to be found in the 16-byte possibility space? Is it all about raster effects, simple per-pixel formulas and glitches? Inferior and uglier versions of the things that have already made in 32 or 64 bytes? Is it possible to make a "killer demo" in sixteen bytes? A recent 23-byte Commodore 64 demo, Wallflower by 4mat of Ate Bit, suggests that this might be possible:

The most groundbreaking aspect in this demo is that it is not just a simple effect but appears to have a structure reminiscent of bigger demos. It even has an end. The structure is both musical and visual. The visuals are quite glitchy, but the music has a noticeable rhythm and macrostructure. Technically, this has been achieved by using the two lowest-order bytes of the system timer to calculate values that indicate how to manipulate the sound and video chip registers. The code of the demo follows:

* = $7c
ora $a2
and #$3f
tay
sbc $a1
eor $a2
ora $a2
and #$7f
sta $d400,y
sta $cfd7,y
bvc $7c

When I looked into the code, I noticed that it is not very optimized. The line "eor $a2", for example, seems completely redundant. This inspired me to attempt a similar trick within the sixteen-byte limitation. I experimented with both C-64 and VIC-20, and here's something I came up with for the VIC-20:

* = $7c
lda $a1
eor $9004,x
ora $a2
ror
inx
sta $8ffe,x
bvc $7c

Sixteen bytes, including the two-byte PRG header. The visual side is not that interesting, but the musical output blew my mind when I first started the program in the emulator. Unfortunately, the demo doesn't work that well in real VIC-20s (due to an unemulated aspect of the I/O space). I used a real VIC-20 to come up with good-sounding alternatives, but this one is still the best I've been able to find. Here's an MP3 recording of the emulator output (with some equalization to silent out the the noisy low frequencies).

And no, I wasn't the only one who was inspired by Wallflower. Quite soon after it came out, some sceners came up with "ports" to ZX Spectrum (in 12 or 15 bytes + TAP header) and Atari XL (17 bytes of code + 6-byte header). However, I don't think they're as good in the esthetic sense as the original C-64 Wallflower.

So, how and why does it work? I haven't studied the ZX and XL versions, but here's what I've figured out of 4mat's original C-64 version and my VIC-20 experiment:

The layout of the zero page, which contains all kinds of system variables, is quite similar in VIC-20 and C-64. On both platforms, the byte at the address $A2 contains a counter that is incremented 60 times per second by the system timer interrupt. When this byte wraps over (every 256 steps), the byte at the address $A1 is incremented. This happens every 256/60 = 4.27 seconds, which is also the length of the basic macrostructural unit in both demos.

In music, especially in the rhythms and timings of Western pop music, binary structures are quite prominent. Oldschool homecomputer music takes advantage of this in order to maximize simplicity and efficiency: in a typical tracker song, for example, four rows comprise a beat, four beats (16 rows) comprise a bar, and four bars (64 rows) comprise a pattern, which is the basic building block for the high-level song structure. The macro-units in our demos correspond quite well to tracker patterns in terms of duration and number of beats.

The contents of the patterns, in both demos, are calculated using a formula that can be split into two parts: a "chaotic" part (which contains additions, XORs, feedbacks and bit rotations), and an "orderly" part (which, in both demos, contains an OR operation). The OR operation produces most of the basic rhythm, timbres and rising melody-like elements by forcing certain bits to 1 at the ends of patterns and smaller subunits. The chaotic part, on the other hand, introduces an unpredictable element that makes the output interesting.

It is almost a given that the outcomes of this approach are esthetically closer to glitch art than to the traditional "smooth" demoscene esthetics. Like in glitching and circuit-bending, hardware details have a very prominent effect in "Wallflower variants": a small change in register layout can cause a considerable difference in what the output of a given algorithm looks and sounds like. Demoscene esthetics is far from completely absent in "Wallflower variants", however. When the artist chooses the best candidate among countless of experiments, the judgement process strongly favors those programs that resemble actual demos and appear to squeeze a ridiculous amount of content in a low number of bytes.

When dealing with very short programs that escape straightforward rational understanding by appearing to outgrow their length, we are dealing with chaotic systems. Programs like this aren't anything new. The HAKMEM repository from the seventies provides several examples of short audiovisual hacks for the PDP-10 mainframe, and many of these are adaptations of earlier PDP-1 hacks, such as Munching Squares, dating back to the early sixties. Fractals, likewise producing a lot of detail from simple formulas, also fall under the label of chaotic systems.

When churning art out of mathematical chaos, be that fractal formulas or short machine-code programs, it is often easiest for the artist to just randomly try out all kinds of alternatives without attempting to understand the underlying logic. However, this easiness does not mean that there is no room for talent, technical progress or rational approach in the 16-byte size class. Random toying is just a characteristic of the first stages of discovery, and once a substantial set of easily discoverable programs have been found, I'm sure that it will become much more difficult to find new and groundbreaking ones.

Some years ago, I made a preliminary design for a virtual machine called "Extreme-Density Art Machine" (or EDAM for short). The primary purpose of this new platform was to facilitate the creation of extremely small demoscene productions by removing all the related problems and obstacles present in real-world platforms. There is no code/format overhead; even an empty file is a valid EDAM program that produces a visual result. There will be no ambiguities in the platform definition, no aspects of program execution that depend on the physical platform. The instruction lengths will be optimized specifically for visual effects and sound synthesis. I have been seriously thinking about reviving this project, especially now that there have been interesting excursions to the 16-byte possibility space. But I'll tell you more once I have something substantial to show.

We need a Pan-Hacker movement.

2011-06-17T22:25:00.000+01:00

Some decades ago, computers weren't nearly as common as they are today. They were big and expensive, and access to them was very privileged. Still, there was a handful of people who had the chance to toy around with a computer in their leisure time and get a glimpse of what a total, personal access to a computer might be like. It was among these people, mostly students in MIT and similar facilities, where the computer hacker subculture was born.

The pioneering hackers felt that computers had changed their life for the better and therefore wanted to share this new improvement method with everyone else. They thought everyone should have an access to a computer, and not just any kind of access but an unlimited, non-institutionalized one. Something like a cheap personal computer, for example. Eventually, in the seventies, some adventurous hackers bootstrapped the personal computer industry, which led to the the so-called "microcomputer revolution" in the early eighties.

The era was filled with hopes and promises. All kinds of new possibilities were now at everyone's fingertips. It was assumed that programming would become a new form of literacy, something every citizen should be familiar with -- after all, using a computer to its fullest potential has always required programming skill. "Citizens' computer courses" were broadcasted on TV and radio, and parents bought cheap computers for their kids to ensure a bright future for the next generation. Some prophets even went far enough to suggest that personal computers could augment people's intellectual capacities or even expand their consciousnesses in the way how psychedelic drugs were thought to do.

In the nineties, however, reality stroke back. Selling a computer to everyone was apparently not enough for automatically turning them into superhuman creatures. As a matter of fact, digital technology actually seemed to dumb a lot of people down, making them helpless and dependent rather than liberating them. Hardware and software have become ever more complex, and it is already quite difficult to build reliable mental models about them or even be aware of all the automation that takes place. Instead of actually understanding and controlling their tools, people just make educated guesses about them and pray that everything works out right. We are increasingly dependent on digital technology but have less and less control over it.

So, what went wrong? Hackers opened the door to universal hackerdom, but the masses didn't enter. Are most people just too stupid for real technological awareness, or are the available paths to it too difficult or time-consuming? Is the industry deliberately trying to dumb people down with excessive complexity, or is it just impossible to make advanced technology any simpler to genuinely understand? In any case, the hacker movement has somewhat forgotten the idea of making digital technology more accessible to the masses. It's a pity, since the world needs this idea now more than ever. We need to give common people back the possibility to understand and master the technology they use. We need to let them ignore the wishes of the technological elite and regain the control of their own lives. We need a Pan-Hacker movement.

What does "Pan-Hacker" mean? I'll be giving three interpretations that I find equally relevant, emphasizing different aspects of the concept: "everyone can be a hacker", "everything can be hacked" and "all hackers together".

The first interpretation, "everyone can be a hacker", expands on the core idea of oldschool hackerdom, the idea of making technology as accessible as possible to as many as possible. The main issue is no longer the availability of technology, however, but the way how the various pieces of technology are designed and what kind of user cultures are formed around them. Ideally, technology should be designed so that it invites the user to seize the control, play around for fun and gradually develop an ever deeper understanding in a natural way. User cultures that encourage users to invent new tricks should be embraced and supported, and there should be different "paths of hackerdom" for all kinds of people with all kinds of interests and cognitive frameworks.

The second interpretation, "everything can be hacked", embraces the trend of extending the concept of hacking out of the technological zone. The generalized idea of hacking is relevant to all kinds of human activities, and all aspects of life are relevant to the principles of in-depth understanding and hands-on access. As the apparent complexity of the world is constantly increasing, it is particularly important to maintain and develop people's ability to understand the world and all kinds of things that affect their lives.

The third interpretation, "all hackers together", wants to eliminate the various schisms between the existing hacker subcultures and bring them into a fruitful co-operation. There is, for example, a popular text, Eric S. Raymond's "How To Become A Hacker", that represents a somewhat narrow-minded "orthodox hackerdom" that sees the free/open-source software culture as the only hacker culture that is worth contributing to. It frowns upon all non-academic hacker subcultures, especially the ones that use handles (such as the demoscene, which is my own primary reference point to hackerdom). We need to get rid of this kind of segregation and realize that there are many equally valid paths suitable for many kinds of minds and ambitions.

Now that I've mentioned the demoscene, I would like to add that all kinds of artworks and acts that bring people closer to the deep basics of technology are also important. I've been very glad about the increasing popularity of chip music and circuit-bending, for example. The Pan-Hacker movement should actively look for new ways of "showing off the bits" to different kinds of audiences in many kinds of diverse contexts.

I hope my writeup has given someone some food of thought. I would like to elaborate my philosophy even further and perhaps do some cartography on the existing "Pan-Hacker" activity, but perhaps I'll return to that at some later time. Before that, I'd like to hear your thoughts and visions about the idea. What kind of groups should I look into? What kind of projects could Pan-Hacker movement participate in? Is there still something we need to define or refine?

Ancient binary symbolism and why it is relevant today

2011-06-06T17:50:00.000+01:00

It is a well-known fact the human use of binary strings (or even binary numbers, see Pingala) predates electronics and automatic calculators by thousands of years.

Divination was probably the earliest human application for binary arrays. There are several systems in Eurasia and Africa that assign fixed semantics to bitstrings of various lengths. The Chinese I Ching gives meanings to the 3- and 6-bit arrays, while the systems used in the Middle East, Europe and Africa tend to prefer groups of 4 and 8 bits.

These systems of binary mysticism have been haunting me for quite many years already. As someone who has been playing around with bits since childhood, I have found the idea of ancient archetypal meanings for binary numbers very attractive. However, when studying the actual systems in order to find out the archetypes, I have always encountered a lot of noise that has blocked my progress. It has been a little bit frustrating: behind the noise, there are clear hints of an underlying logic and an original protosemantics, but whenever I have tried to filter out the noise, the solution has escaped my grasp.

Recently, however, I finally came up with a solution that satisfies my sense of esthetics. I even pixelled a set of "binary tarot cards" for showing off the discovery:

For a more complete summary, you may want to check out this table that contains a more elaborate set of meanings for each array and also includes all the traditional semantics I have based them on.

Of course, I'm not claiming that this is some kind of a "proto-language" from which all the different forms of binary mysticism supposedly developed. It is just an attempt to find an internally consistent set of meanings that match the various traditional semantics as closely as possible.

Explanation

In my analysis, I have translated the traditional binary patterns into modern Leibnizian binary numbers using the following scheme:

This is the scheme that works best for I Ching analysis. The bits on the bottom are considered heavier and more significant, and they change less frequently, so the normal big-endian reading starts from the bottom. The "yang" line, consisting of a single element, maps quite naturally to the binary "1", especially given that both "yang" and "1" are commonly associated with activity.

I have drawn each "card picture" based on the African shape of the binary array (represented as rows of one or two stones). I have left the individual "stones" clearly visible so that the bitstrings can be read out from the pictures alone. Some of the visual associations are my own, but I have also tried to use traditional associations (such as 1111=road/path, 0110=crossroads, 1001=enclosure) as often as they feel relevant and universal enough.

In addition to visual associations, the traditional systems have also formed semantics by opposition: if the array 1111 means "journey", "change" and "death", its inversion 0000 may obtain the opposite meanings: "staying at home", "stability" and "life". The visual associations of 0000 itself no longer matter as much.

The two operations used for creating symmetry groups are inversion and mirroring. These can be found in all families of binary divination: symmetric arrays are always paired with their inversions (e.g. 0000 with 1111), and asymmetric arrays with their reversions (e.g. 0111 with 1110).

Because of the profound role of symmetry groups, I haven't represented the arrays in a numerical order but in a 4x4 arrangement that emphasizes the mutual relationships via inversion and mirroring. Each of the rows in the "binary tarot" picture represents a group with similar properties:

The top row contains the four symmetrical arrays (which remain the same when mirrored).
The second row contains the arrays for which mirroring and inversion are equivalent.
The two bottom rows represent the two groups whose members can be derived from each other solely by mirroring and inversion.

The semantics within each group are interrelated. For example, the third row ("up", "in", "out", "down") can be labelled "the directions". In order to emphasize this, I have chosen a pair of dichotomies for each row. For example, the row of the directions uses the dichotomies "far-near" and "horizontal-vertical", and the array called "up" combines the poles "far"+"vertical". All the dichotomies can be found in my summary table.

The arrays in the top two groups have an even parity while those on the bottom two groups have an odd parity. This difference is important at least in Al-Raml and related systems, where the array getting the role of a "judge" in a divination table must have an even parity; otherwise there is an error in the calculation.

The members of each row can be derived from one another by eXclusive-ORing them with a symmetrical array (0000, 1111, 0110 or 1001). For this reason, I have also organized the arrangement as a XOR table.

The color schemes used in the card pictures are based on the colors in various 16-color computer palettes and don't carry further symbolism (even though 0010 happens to have the meaning of "red" in Al-Raml and Geomancy as well). Other than that, I have abstained from any modern technological connections.

But why?

Our subjective worlds are full of symbolism that brings various mental categories together. We associate numbers, letters, colors and even playing cards to various real-world things. We may have superstitions about them or give them unique personalities. Synesthetics even do this involuntarily, so I guess it is quite a basic trait for the human mind.

Binary numbers, however, have remained quite dry in this area. We don't really associate them with anything else, so they remain alien to us. Even experts who are constantly dealing with binary technology prefer to hide them or abstract them away. This alienation combined to the increasing role of digitality in our lives is the reason why I think there should be more exposure for the various branches of binary symbolism.

In many cultures, binary symbolism has attained a role so central that people base their conceptions of the world on it. A lot of traditional Chinese cosmology is basically commentary of I Ching. The Yoruba of West Africa use the eight-bit arrays of the Ifa system as "hash codes" to index their whole oral tradition. Some other West African peoples -- the Fon and the Ewe -- extend this principle far enough to give every person an eight-bit "kpoli" or "life sign" at their birth.

I guess the best way to bring some binary symbolism to our modern technological culture might be using it in art. Especially the kind of art such as pixel art, chip music and demoscene productions that embrace the bits, bringing them forward instead of hiding them. This is still just a meta-level idea, however, and I can't yet tell how to implement in it practice. But once I've progressed with it, I'll let you know for sure!

What should big pixels look like?

2011-06-02T13:39:00.000+01:00

There has been some fuss recently about a new algorithm that vectorizes pixel art. And yes, judging from the example pictures, this algorithm by Johannes Kopf and Dani Lischinski indeed seems to produce results superior to the likes of hq*x and scale*x or mainstream vectorization algorithms. Let me duplicate the titular example for reference:
Impressive, yes, but as in case with all such algorithms, the first question that came to my mind was: "But does it manage dithering and antialiasing?". The paper explicitly answers this question: no.

All the depixelization algorithms so far have been succesful only with a specific type of pixel art. Pixel art of a cartoonish style that has clear lines and not too many details. This kind of pixel art may have been mainstream in Japan, but in the Western sphere, especially in Europe, there has been a strong tradition of optimalism: the tendency of maximizing the amount of detail and shading within the limited grid of pixels. An average pixel artwork on the Commodore 64 or the ZX Spectrum has an extensive amount of careful manual dithering. If we wish to find a decent general-purpose pixel art depixelization algorithm, it would definitely need to take care of that.

I once experimented by writing an undithering filter that attempts to smooth out dithering while keeping non-dithering-related pixels intact. The filter works as follows:

Flag a pixel as a dithering candidate if it differs enough from its cardinal neighborhood (no more than one of the four neighbors are more similar to the reference pixel than the neighbor average).

Extend the area of dither candidates: flag a pixel if at least five of its eight neighbors are flagged. Repeat until no new pixels are flagged.

For each flagged pixel, replace its color with the weighed average of all the flagged pixels within the surrounding 3x3 rectangle.

Would it be possible to improve the performance of a depixelization algorithm by first piping the picture thru my undithering filter? Let's try out. Here is an example of how the filter manages with a fullscreen C-64 multicolor-mode artwork (from the demoscene artist Frost of Panda Design) and how the results are scaled by the hq4x algorithm:

The undithering works well enough within the smooth areas, and hq4x is even able to recognize the undithered areas as gradients and smooth them a little bit further. However, when looking at the border between the nose and the background, we'll notice careful manual antialiasing that even adds some lonely dithering pixels to smooth out the staircasing. My algorithm doesn't recognize these lonely pixels as dithering, and neither does it recognize the loneliest pixels in the outskirts of dithered gradients as dithering. It is a difficult task to algorithmically detect whether a pixel is intended to be a dithering pixel or a contour/detail pixel. Detecting antialiasing would be a totally different task, requiring a totally new set of processing stages.

There seems to be still a lot of work to do. But suppose that, some day, we will discover the ultimate depixelization algorithm. An image recognition and rerendering pipeline that succesfully recognizes and interprets contours, gradients, dithering, antialiasing and everything else in all conceivable cases, and rerenders it in a high resolution and color without any distracting artifacts. Would that be the holy grail? I wouldn't say so.

The case is that we already have the ultimate depixelization algorithm -- the one running in the visual subsystem of the human brain. It is able to fill in amazing amounts of detail when coping with low amounts of reliable data. It handles noisiness and blurriness better than any digital system. It can extrapolate very well from low-complexity shapes such as silhouette drawings or groups of blurry dots on a CRT screen.

A fundamental problem with the "unlimited resolution" approach of pixel art upscaling is that it attempts to fill in details that aren't there -- a task in which the human brain is vastly superior. Replacing blurry patterns with crisp ones can even effectively turn off the viewer's visual imagination: a grid of blurry dots in the horizon can be just about anything, but if they get algorithmically substituted by some sort of crisp blobs, the illusion disappears. I think it is outright stupid to waste computing resources and watts for something that kills the imagination.

The reason why pixel art upscaling algorithms exist in the first place is that sharp rectangular pixels (the result of nearest-neighbor upscaling) look bad. And I have to agree with this. Too easily recognizable pixel boundaries distract the viewer from the art. The scaling algorithms designed for video scaling partially solve this problem with their interpolation, but the results are still quite bad for the opposite reason -- because there is no respect for the nature of the individual pixel.

When designing a general-purpose pixel art upscaling algorithm, I think the best route would go somewhere between the "unlimited resolution" approach and the "blurry interpolation" approach. Probably something like CRT emulation with some tasteful improvements. Something that keeps the pixels blurry enough for the visual imagination to work while still keeping them recognizable and crisp enough so that the beauty of the patterns can be appreciated.

Nevertheless, I was very fascinated by the Kopf-Lischinski algorithm, but not because of how it would improve existing art, but for its potential of providing nice, organic and blobby pixels to paint new art with. A super-low-res pixel art painting program that implements this kind of algorithm would make a wonderful toy and perhaps even vitalize the pixel art scene in a new and refreshing way. Such a vitalization would also be a triumph for the idea of Computationally Minimal Art which I have been advocating.

Is it possible to unite transhumanism and degrowth?

2011-05-17T17:45:00.000+01:00

I have always had mixed feelings about transhumanism. On one hand, the movement provides fresh ideas and great speculative material, but on the other hand, it seems to suffer from a kind of adolescent "nothing is enough" attitude on every possible level.

Transhumanism, in short, advocates the use of technology for turning humans into something better: creatures with ridiculously long lifespans, ridiculous levels of intelligence and ridiculous amounts of pleasure in life. In order to endlessly improve all the statistics, the transcendental mankind needs more and more energy and raw material. One planet is definitely not enough -- we need to populate an ever bigger portion of the universe with ever bigger brainlike structures. To me, these ideas sound like an extreme glorification of our current number one memetic plague, the ideology of endless economic growth. What a pity, since some of the stuff does make some sense.

Fortunately, there seems to be more room for diversity in transhumanist thought than that. As there are currents such as "Christian Transhumanism" or "Social-Democratic Transhumanism", would it be possible to devise something like "Degrowthian Transhumanism" as well? Something that denounces the growth ideology while still advocating scientific and technological progress in order to transform mankind into something better? This would be a form of transhumanist philosophy even I might be able to appreciate and symphatize. But could such a bastard child of two seemingly conflicting ideologies be anything else than oxymoronic and inconsistent? Let's find out.

The degrowth movement, as the name says, advocates the contraction of economies by downscaling production, as it views the excessive production and consumption in today's societies as detrimental to both the environment and the quality of human life. Consumers need to switch their materialist lifestyles into voluntary simplicity, and producers need to abandon things like planned obsolescence that artificially keep the production volumes up. Downscaling will also give people more free time, which can be used for noble quests such as charity and self-cultivation. These goals may sound agreeable on their own, even to a transhumanist, but what about the technological progress? Downscaling the industries would also slow it down or even reverse it, wouldn't it?

Actually, quite many technologies make it possible to do "more with less" and therefore scale dependency networks down. Personal computers, for example, have succesfully replaced an arsenal of special-purpose gadgets ranging from typewriters and television sets to expensive studio equipment. 3D printing technology will reduce the need for specialized mass production, and once we get nanobots to assist in it, we will never require mines or factories anymore. A degrowthian transhumanist may want to emphasize this kind of potential in emergencing technologies and advocate their use for downshifting instead of upshifting. A radical one may even take the provocative stance that only those technologies that reduce overhead are genuinely progressive.

A degrowthian transhumanist may want to advocate immaterial developments whenever possible: memetics, science, software. Information is much more lightweight to process than matter or energy and therefore an obvious point of focus for anyone who wants to support both degrowth and technological progress. Most people in our time do not understand how crucial software is in making hardware perform well, so a degrowthian transhumanist may want to shout it out every now and then. It is entirely possible that we already have the hardware for launching a technological singularity, we just don't have the software yet. We may all have savant potential in our brains, we just haven't found the magic formula to unleash it with. In general, we don't need new gadgetry as much as we need in-depth understanding of what we already have.

In a downshifted society, people will have a lot of free time. A degrowthian transhumanist may therefore be more willing to adopt time-consuming methods of self-improvement than the mainline transhumanist who fantasizes about quick and easy mass-produced magic such as instant IQ pills. Wisdom is a classical example of a psychological feature that takes time to build up, so a degrowthian transhumanist may want to put a special emphasis on it. Using intelligence without wisdom may have catastrophic results, so we need superhuman wisdom to complement superhuman intelligence, and maybe even artificial wisdom to complement artificial intelligence. The quest for immortality is no longer just about an individual desire to live as long as possible, but about having individuals and societies that get wise enough to use their superhuman capacities in a non-catastrophic way.

So, how would a race of degrowthian superhumans spend their lives? By reducing and reducing until there's nothing left but ultimate reclusion? I don't think so. The degrowth movement is mostly a reaction towards the present state of the world and not a dogma that should be adhered to its logical extreme. Once we have scaled our existence down to some kind of sustainable moderateness, we won't need to degrow any further. Degrowthian transhumans would therefore very well colonize a planet or moon every now and then, they just wouldn't regard expansion as an ends of its own. In general, these creatures would be rather serious about the principles of moderation and middle way in anything they do. They would probably also be more independent and self-sufficient than their extropian counterparts who, on their part, would have more brain cells, gadgets and space to toy around with.

This was a thought experiment I carried out in order to clarify my own relationship with the transhumanist ideology. I tried to find a fundamental disagreement between the core transhumanist ideas and my personal philosophy but didn't find one. Still, I don't think I'll be calling myself a transhumanist (even a degrowthian one) any time soon; I just wanted to be sure how much I can sympathize this bunch of freaks. I also considered my point of view fresh enough to write it up and share with others, so there you are, hope you liked it.

On electronic wastefulness

2011-02-01T02:02:00.000Z

Many things are horribly wrong in this world.

People are becoming more and more aware of this. Environmental and economic problems have strengthened the criticism towards consumer culture, monetary power and political systems, and all kinds of countercultural movements are thriving. At the same time, however, ever more people are increasingly dependent on digital technology, which gets produced, bought, used and abandoned in greater masses than ever, causing an ever bigger impact on the world in the form of waste and pollution.

Because of this, I have decided to finally summarize my thoughts on how digital technology reflects the malfunctions of our civilization. I became a hobbyist programmer as a schoolkid in the mid-eighties, and fifteen years later I became a professional software developer. Despite all this baggage, I'm going to attempt to keep my words simple enough for common people to understand. Those who want to get convinced by citations and technical argumentation will get those at some later time.

Counter-explosion

For over fifty years, the progress of digital technology has been following the so-called Moore's law, which predicts that the number of transistors that fit on a microchip doubles every two-or-so years. This means that it is possible to produce digital devices that are of the same physical size but have ever more memory, ever more processing speed and ever greater overall capabilities.

Moore's law itself is not evil, as it also means that it is possibile to perform the same functions with ever less use of energy and raw material. However, people are people and behave like people: whenever it becomes possible to do something more easily and less consumingly, they start doing more of this something. This phenomenon is called "rebound effect" based on a medical term of the same name. It can be seen in many kinds of things: less fuel-consuming cars make people drive more, and less calories in food make weight-losers eat more. The worst case is when the actual savings becomes negative: a thing that is supposed to reduce consumption actually increases it instead.

In information technology, the most prominent form of rebound effect is the bloating of software, which takes place in the same rate of explosiveness as the improvement of hardware. This phenomenon is called Wirth's law. If we took a time machine ride back to 1990 and told the contemporaries that desktop computers would be becoming thousand times faster in twenty years, they would surely assume that almost anything would happen instantaneously with them. If we then corrected them by saying that software programs still take time to start up in the 2010s and that it is sometimes painful to tolerate their slowness and unresponsiveness, they wouldn't believe it. How is it even possible to write programs so poorly that they don't run smoothly with a futuristic, thousand times more powerful computer? This fact would become even harder to believe if we told them that it also applies to things like word processors which are used for more or less exactly the same things as before.

One reason for the unnecessary largeness, slowness and complexity of software is the dominant economic ideal of indefinite growth, which makes us believe that bigger things are always better and it is better to sell customers more than they need. Another reason is that rapid cycles of hardware upgrade make software developers indifferent: even if an application program were mindlessly slow and resource-consuming even on latest hardware, no one will notice it a couple of years later when the hardware is a couple of times faster. Nearly any excuse is valid for bloat. If it is possible to shorten software development cycles even slightly by stacking all kinds of abstraction frameworks and poorly implemented scripting languages on top of one another, it will be done.

The bloat phenomenon annoys people more and more in their normal daily life, as all kinds of electric appliances starting from the simplest flashlight contain increasingly complex digital technology, which drowns the user in uncontrollable masses of functionality and strange software bugs. The digitalization of television, for example, brought a whole bunch of computer-style immaturity to the TV-watching experience. I've even seen an electric kitchen stove that didn't heat up before the user first set up the integrated digital clock. Diverse functionality itself is not evil, but if the mere existence of extra features disrupts the use of the basic ones, something is totally wrong.

Even though many things in our world tend to swell and complexify, it is difficult to find a physical-world counterpart to software bloat, as the amount of matter and living space on our planet does not increase exponentially. It is not possible to double the size of one's apartment every two years in order to fit in more useless stuff. It is not possible to increase the complexity of official paperwork indefinitely, as it would require more and more food and accommodation space for the expanding army of bureaucrats. In the physical world, it is sometimes necessary to evaluate what is necessary and how to compress the whole in order to fit more. Such necessity does not exist in the digital world, however; there, it is possible to constantly inhale and never exhale.

Disposability

The prevailing belief system of today's world equates well-being with material abundance. The more production and consumption there is, the more well-being there is, and that's it. Even though the politicians in rich countries don't want to confess this belief so clearly anymore, they still use concepts such as "gross national product", "economic growth" and "standard of living" which are based on the idealization of boundless abundance.

As it is the holy responsibility of all areas of production to grow indefinitely, it is important to increase consumption regardless of whether it is sensible or not. If it is not possible to increase the consumption in natural ways, planned obsolensce comes to rescue. Some decades ago, people bought washing machines and television sets for the twenty years to follow, but today's consumers have the "privilege" of buying at least four of both during the same timespan, as the lifespans of these products have been deliberately shortened.

The scheduled breaking of electric appliances is now easier than ever, as most of them have an integrated microprocessor running a program of some kind. It is technically possible, for example, to hide a timer in this program, causing the device to either "break" or start misbehaving shortly after the warranty is over. This kind of sabotage may be beneficial for the sales of smaller and cheaper devices, but it is not necessary in the more complex ones; in their case, the bloated poor-quality software serves the same purpose.

Computers get upgraded especially when the software somehow becomes intolerably slow or even impossible to run. This change can take place even if the computer is used for exactly the same things as before. Bloat makes new versions of familiar software more resource-consuming, and when reforms are introduced on familiar websites, they tend to bloat up as well. In addition, some operating systems tend to slow down "automatically", but this is fortunately something that can be fixed by the user.

The experience of slowness, in its most annoying form, is caused by too long response times. The response time is the time between user's action and the indication that the action has been registered. Whenever the user moves the mouse, the cursor on the screen must immediately match the movement. Whenever the user presses a letter key on the keyboard, the same letter must appear on the screen immediately. Whenever the user clicks a button on the screen, the
graphic of the button must change immediately. According to usability research, the response time must be less than 1/10 seconds or the system feels laggy. When it has taken more than a second, the user's blood pressure is already increasing. After ten seconds, the user is convinced that "the whole piece of junk has locked up".

Slow response times are usually regarded as an indicator that the device is slow and that it is necessary to buy a new one. This is a misconception, however. Slow response times are indicators of nothing else than indifferent attitudes to software design. Every computing device that has become available during the last thirty years is completely capable of delivering the response within 1/10 seconds in every possible situation. Despite this fact, the software of the 2010s is still usually designed in such a way that the response is provided once the program has first finished all the more urgent tasks. What is supposed to be more important than serving the user? In the mainframe era, there were quite many such things, but in today's personal computing, this should never be the case. Fixing the response time problems would be a way to permanently make technology more comfortable to use as well as to help the users tolerate the actual slowness. The industry, however, is strangely indifferent to these problems. Response times are, from its point of view, something that "get fixed" automatically, at least for a short while and in some areas, at hardware upgrades.

Response time problems are just a single example of how the industry considers it more important to invent new features than to fix problems that irritate the basic user. A product that has too few problems may make consumers too satisfied. So satisfied that they don't feel like buying the next slightly "better" model which replaces old problems with new ones. Companies that want to ensure their growth prefer to do everything multiple times in slightly substandard ways instead of seeking any kind of perfection. Satisfaction is the worst enemy of unnecessary growth.

Is new hardware any better?

I'm sure that most readers have at least heard about the problems caused by the rat race of upgrade and overproduction. The landfills in rich countries are full of perfectly functioning items that interest no one. Having anything repaired is stupid, as it is nearly always easier and cheaper to just buy new stuff. Selling used items is difficult, as most people won't accept them even for free. Production eats up more and more natural resources despite all the efforts of "greening up" the production lines and recycling more and more raw material.

The role of software in the overproduction cycle of digital technology, however, is not so widely understood. Software is the soul of every microprocessor-based device, and it defines most of what it is like to use the device or how much of its potential can be used. Bad software can make even good hardware useless, whereas ingenious software can make even a humble device do things that the original designer could never have imagined. It is possible to both lengthen and shortern product lifetimes via software.

New hardware is often advocated with new features that are not actually features of the hardware but of the software it runs. Most of the features of the so-called "smartphones", for example, are completely software-based. It would be perfectly possible to rewrite the software of an old and humble cellphone in order to give it a bunch of features that would effectively turn it into a "smartphone". Of course, it is not possible to do complete impossibilities with software; there is no software trick that makes a camera-less phone take photos. Nevertheless, the general rule is that hardware is much more capable than its default software. The more the hardware advances, the more contrast there is between the capabilities of the software and the potential of the hardware.

If we consider the various tasks for which personal computers are used nowadays, we will notice that only a small minority of them actually requires a lot from the hardware. Of course, bad software may make some tasks feel more demanding than what they actually are, but that's another issue. For instance, most of the new online services, from Facebook to Youtube and Spotify, could very well be implemented so that they run with the PCs of the late 1990s. Actually, it would be possible to make them run more smoothly than how the existng versions run on today's PC. Likewise, with better operating systems and other software, we could make the same old hardware feel faster and more comfortable to use than today's hardware. From this we can conclude that the computing power of the 2000s is neither useful, necessary nor pleasing for most users. Unless we count the pseudo-benefit that it makes bad and slow software easier to tolerate, of course.

Let us now imagine that the last ten years in personal computing went a little bit differently -- that most of the computers sold to the great masses would have been "People's Computers" with a fixed hardware setup. This would have meant that the hardware performance would have remained constant for the last ten years. The 2011 of this alternate universe would probably be somewhat similar to our 2011, and some things could even be better. All the familiar software programs and on-line services would be there, they would just have been implemented more wisely. The use of the computers would have become faster and more comfortable during the years, but this would have been due to the improvement of software, not hardware. Ordinary people would never need to think about "hardware requirements", as the fixedness of the hardware would ensure that all software, services and peripherials work. New computers would probably be lighter and more energy-efficient, as the lack of competition in performance would have moved the competition to these areas. These are not just fringe utopian ideas; anyone can make similar conclusions by studying the history of home computing where several computer and console models have remained constant for ten years or more.

Of course it is easy to come up with ideas of tasks that demand more processing power than what was available to common people ten years ago or even today. A typical late-1990s desktop PC, for example, plays ordinary DVD-quality movies perfectly but may have major problems with the HD resolutions that are fashionable in the early 2010s. Similarly, by increasing the numbers, it is possible to come up with imaginary resolutions that are out of the reach of even the most expensive special-purpose equipment available today. For many people, this is exactly what technological progress means -- increase in numerical measures, the possibility to do the same old things in ever greater scales. When a consumer replaces an old TV with a new one, he or she gets a period of novelty vibes from the more magnificent picture quality. After a couple of years, the consumer can buy another TV and get the novelty vibes once again. If we had an access to unlimited natural resources, it would be possible to go on with this vanity cycle indefinitely, but still without improving anyone's quality of life in any considerable extent.

Most of the technological progress facilitated by the personal computing resources of the 2000s has been quantitative -- doing the same old stuff that became possible in the 1990s but with bigger numbers. Editing movies and pictures that have ever more pixels, running around in 3D video game worlds that have ever more triangles. It is difficult to even imagine a computational task relevant to an ordinary person that would require the number-crunching power of a 2000s home computer due to its nature alone, without any quantitative exaggeration. This could very well be regarded as an indicator that we already have enough processing power for a while. The software and user culture are lagging so far behind the hardware improvements, that it would be better to concentrate on them instead and leave the hardware on the background.

Helplessness

In addition to the senseless abundance of material items, today's people are also disturbed by a senseless abundance of information. Information includes not only the ever expanding flood of video, audio and text coming from the various media, but also the structural information incorporated in material and immaterial things. The expansion of this structural information manifests as increasing complexity of everything: consumer items, society systems, cultural phenomena. Those who want to understand the tools they use and the things that affect their life, must absorb ever greater amounts of structural information about them. Many people have already given up with understanding and just try to get along.

Many frown upon people who can't boil an egg or attach a nail to a wall without a special-purpose egg-boiler or nailgun, or who are not even interested in how the groceries come to the store or the electricity to the wall socket. However, the expanding flood of information and the complexification of everything may eventually result in a world where neo-helplessness and poor common knowledge are the normal condition. In computing, complexification has already gone so far that even many experts don't dare to understand how the technology works but prefer to guess and randomize.

Someone who wants to master a tool must build a mental model of its operation. If the tool is a very simple one, such as a hammer, the mental model builds up nearly automatically after a very short study. If someone who uses a hammer accidentally hits their finger with it, they will probably accuse themself instead of the hammer, as the functionality of a hammer can be understood perfectly even by someone who is not so capable in using it. However, when a computer program behaves against the user's will, the user will probably accuse the technology instead of themself. In situations like this, the user's mental model of how the program works does not match with its actual functionality.

The more bloated a software program is, the more effort the user needs to take in order to build an adequate mental model. Some programs are even marketing-minded enough to impose its new and glorious features to the user. This doesn't help at all in forming the mental model. Besides, most users don't have a slightest interest in extensive exploration but rather use a simple map and learn to tolerate the uncertainty caused by its rudimentariness. When we also consider that programs may change their functionality quite a lot between versions, even enthusiasts will turn cynical and frustrated when their precious mental maps become obsolete.

Many software programs try to fix the complexity problem by increasing the complexity instead of decreasing it. This mostly manifests as "intelligence". An "intelligent" programs monitors the user, guesses their intents and possibly suggests various courses of actions based on the intents. For example, a word processor may offer help in writing a letter, or a file manager may suggest things to do with a newly inserted memory stick. The users are offered all kinds of controlled ready-made functionality and "wizards" even for tasks they would surely prefer to do by themselves, at least if they had a chance to learn the normal basic functionality. If the user is forced to use specialized features before learning the basic ones, he or she will be totally helpless in situations where a special-purpose feature for the particular function does not exist. Just like someone who can use egg-boilers and nailguns but not kettles or hammers.

The reasons why technology exists are making things easier to do and facilitating otherwise impossible tasks. However, if a technological appliance becomes so complex that its use is more like random guessing than goal-oriented controlling, we can say that the appliance no longer serves its purpose and that the user has been taken over by technology. For this reason, it is increasingly important to keep things simple and controllable. Simplicity, of course, does not mean mere superficial pseudo-simplicity that hides the internal complxity, but the avoidance of complexity on all levels. The user cannot be in full control without having some kind of an idea about what the tool is doing at any given time.

In software, it may be useful to reorder the complexity so that there is a simple core program from which any additional complexity is functionally separated until the user deliberately activates it. This would make the programs feel reliable and controllable even with simple mental maps. An image processing software, for example, could resemble a simple paint program at its core level, and its functionality could be learned perfectly after a very short testing period. All kinds of auxilary functions, automations and other specialities could be easily found if needed, and the user could extend the core with them depending on the particular needs. Still, their existence would never disturb those users who don't need them. Regardless of the level of the user, the mental map would always match how the program actually works, and the program would therefore never surprise the user by acting against his or her expectations.

Software is rarely built like this, however. There is not much interest in the market for movements that make technology genuinely more approachable and comprehensible. Consumer masses who feel themselves helpless in regards to the technology are, after all, easier to control than masses of people who know what they are doing (or at least think so). It is much more beneficial for the industry to feed the helplessness by drowning the people in trivialities, distancing them for the basics and perhaps even submitting them under the power of an all-guessing artificially-intelligent assistant algorithm.

Changing the world

I have now discussed all kinds of issues, of which I have mostly accused bad software, and of whose badness I have mostly accused the economic system that idealizes growth and material abundance. But is it possible to do something about these issues? If most of the problems are indeed software-related, then couldn't they be resolved by producing better software, perhaps even outside of the commercial framework if necessary?

When calling for a counter-force for commercial software development, the free and open-source software (FOSS) movement is most commonly mentioned. FOSS software has mostly been produced as volunteer work without monetary income, but as the result of the work can be freely duplicated and used as basis of new work, they have managed to cause a much greater impact than what voluntary work usually does. The greatest impact has been among technology professionals and hobbyists, but even laypeople may recognize names such as Linux, Firefox and OpenOffice (of which the two latter are originally proprietary software, however).

FOSS is not bound to the requirements of the market. Even in cases where it is developed by corporations, people operating outside the commercial framework can contribute to it and base new projects on it. FOSS has therefore, in theory, the full potential of being independent of all the misanthropic design choices caused by the market. However, FOSS suffers from most of these problems just as much as proprietary software, and it even has a whole bunch of its own extra problems. Reasons for this can be found in the history of the movement. Since the beginning, the FOSS movement has mostly concentrated on cloning existing software without spending too much energy on questioning the dominant design principles. The philosophers of the movement tend to be more concerned about legal and political issues instead of technical ones: "How can we maximize our legal rights?" instead of "How should we design our software so that it would benefit the whole humanity instead of just the expert class?"

I am convinced that FOSS would be able to give the world much more than what it has already given if it could form a stronger contrast between itself and the growth-centric industry. In order to strengthen the contrast, we need a powerful manifest. This manifest would need to profoundly denounce all the disturbances to technological progress caused by the growth ideology, and it would need to state the principles on which software design should be based on in order to benefit human beings and nature in the best possible way. Of course, this manifest wouldn't exist exclusively for reinventing the wheel, but also for re-evaluating existing technology and redirecting its progress towards the better.

But what can ordinary people do? Even a superficial awareness of the causes of problems is better than nothing. One can easily learn to recognize many types of problems, such as those related to response times. One can also learn to accuse the right thing instead of superficially crying how "the computer is slow" or "the computer is misbehaving". Changes in language are also a nice way of spreading awareness. If people in general learned to accuse software instead of hardware, then they would probably also learn to demand software-based solutions for their problems instead of needlessly purchasing new hardware.

When hardware purchases are justifiable, those concerned of the environment will prefer second-hand hardware instead of new, as long as there is enough power for the given purposes. It is a common misconception to assume that new hardware would always consume less power than old -- actually, the trend has more often been exactly the opposite. During a period of ten years from the mid-1990s to the mid-2000s, for example, the power consumption of a typical desktop PC (excluding the monitor) increased tenfold, as the industry was more zealous to increase processing power than to improve energy efficiency. Power consumption curves for video game consoles have been even steeper. Of course, there are many examples of positive development as well. For example, CRT screens are worth replacing with similarly-sized LCD screens, and laptops also typically consume less than similar desktop PCs.

There is a strong market push towards discontinuing all kinds of service and repair activity. Especially in case of cellphones and other small gadgets, "service" more and more often means that the gadget is sent out to the manufacturer which dismantles it for raw material and sends a new gadget to the customer. For this reason, it may be reasonable to consider the difficulty of do-it-yourself activity when choosing a piece of hardware. As all forms of DIY culture seem to be waning due to a lack of interest, it is worthwhile to support them in all possible ways in order to ensure that there will still be someone in the future who can repair something.

Of course, we all hope that the world would change in a way such that the human- and nature-friendly ways to do things would always be the most beneficial ones even in "the reality of numbers and charts". Such a change will probably take longer than a few decades, however, regardless of the volume of the political quarrel. It may therefore not be wise to indefinitely wait for the change of the system, as it is already possible to participate in practical countercultural activity today. Even in things related to digital technology.

The Future of Demo Art: The Demoscene in the 2010s

2010-09-03T16:45:00.000+01:00

Written by Ville-Matias Heikkilä a.k.a. viznut/pwp, released in the web on 2010-09-03. Also available in PDF format.

Introduction

An end of a decade is often regarded as an end of an era. Around the new year 2009-2010, I was thinking a lot about the future of demo art, which I have been involved with since the mid-nineties. The mental processes that led to this essay were also inspired by various events of the 2010s, such as the last Breakpoint party ever, as well as Markku Reunanen's licenciate thesis on the demoscene.

First of all, I want to make it clear that I'm not going to discuss "the death of the scene". It's not even a valid scenario for me. The demo culture is already 25 years old, and during these years, it has shown its ability to adapt to the changes in its technological and cultural surroundings, so it's not very wise to question this ability. Instead, I want to speculate what kind of changes might be taking place during the next ten years. What is the potential of the artform in the 2010s, and what kind of challenges and opportunities is it going to face?

After the nineties

Back in the early nineties, demo art still represented the technological cutting edge in what home computers were able to show. You couldn't download and playback real-life music or movies, and even if you could, the quality was poor and the file sizes prohibitive. It was possible to scan photographs and paintings, but the quality could still be tremendously improved with some skilled hand-pixelling. Demos frequently showed things that other computer programs, such as video games, did not, and this made them hot currency among masses of computer hobbyists far beyond the actual demoscene. As a result, the subculture experienced a constant influx of young and enthusiastic newcomers who wanted to become kings of computer art.

After the nineties, the traditional weapons of the demoscene became more or less ineffective. Seeing a demo on a computer screen is no longer a unique experience, as demos have the whole corpus of audiovisual culture to compete with. Programming is no longer a fashionable way of expressing creativity, as there is ready-made software easily available for almost any purpose. The massive, diverse hordes of the Internet make you feel small in comparison; the meaning of life is no longer to become a legend, but to sit in your own subcultural corner with an introvert attitude of "you make it, you watch it". Young and enthusiastic people interested in arts or programming have hundreds of new paths to choose from, and only a few pick the good, old and thorny path of demomaking.

There are many people who miss the "lost days of glory" of their teens. To them, demos have lost their "glamor" and are now becoming more and more irrelevant. I see the things a little bit differently, however.

Consider an alternative history where the glamor was never lost, and the influx of enthusiastic teenagers always remained constant. Year after year, you would have witnessed masses of newbies doing the same mistakes all over again. You would also have noticed that you are "becoming too old for this shit" and looked for a totally different channel for your creativity. The average career of a demo artist would thus have remained quite short, so there would never have been veteran artists with strong and refined visions and thus no chance for the artform to grow up. Therefore, I don't see it as a bad thing at all that demos are no longer as fashionable as they used to be.

There have been many changes in the demo culture during the last ten years. Most of them can be thought of as adaptations to the changing social and technological surroundings, but you can also think about them as belonging to a growth process. As your testosterone levels have lowered, you are no longer as arrogant about your underground trueness as you used to be. As you have gathered more experience and wisdom about life and the world, you can appreciate the diversity around yourself much better than you used to be. More outreach and less fight, you know.

When thinking about the growth process, one should also consider how the relationship between the demoscene and the technology industry has changed. In the eighties, it was all about piracy. In the nineties, people forgot about the piracy and started to dream about careers in software industry. Today, most sceners already have a job, so they have started to regard their freetime activity as a relief from their career rather than as something that would support it.

Especially those who happen to be coders "on both sides" tend to have an urge to separate the two worlds in some way or another by emphasizing the aspects that differentiate democoding from professional programming. You can't be very creative, independent, experimental or low-level in most programming jobs, so you'll want to be that in your artistic endeavours. You may want to choose totally different platforms, methods and technical approaches so that your leisure activity actually feels like leisure activity.

Thus, although many demosceners work in the software industry, the two worlds seem to be drifting apart. And it is not just because of the separation of work and freetime, but also because of the changes in the industry and the world in general.

Although the complexity of everything in human culture has been steadily increasing for a couple of centuries already, there has been a very dramatic acceleration during the past few decades, especially in technology. This means, among all, that there are more and more prepackaged blackboxes and less and less room for do-it-yourself activities.

Demo art was born in a cultural environment that advocated hobbyist programming and thorough bitwise understanding of one's gear. The technical ambitions of democoders were in complete harmony with the mainstream philosophy of that era's homecomputing. During the following decades, however, the mainstream philosophy degraded from do-it-yourself into passive consumerism, while the demoscene continued to cultivate its original values and attitudes. So, like it or not, demos are now in a "countercultural" zone.

While demos have less and less appeal to the mainstream industry where the "hardcore" niches are gradually disappearing, they are becoming increasingly interesting to all kinds starving artists, grassroots hippies, radical do-it-yourself guys and other "countercultural" people. And if you want your creative work to make any larger-scale sense in the future world, I guess it might be worthwhile to start hang around with these guys as well.

Core Demoscene Activity

The changes during the last ten years have made the demoscene activity somewhat vague. In the nineties, you basically made assembly code, pixel graphics and tracker music, and that was it. The scene was the secret cult that maintained the highest technical standards in all of these "underground" forms of creativity. Nowadays, everyone you know uses computers for creativity, some of them even being better than you, and most computer-aided creativity falls under some valid competition category at demoparties. Almost any deviantART user could submit their work in an average graphics compo, sometimes even win it. As almost anything can be a "demoscene production", being a "demoscener" is no longer about what your creative methods are like, but whom you hang around with.

When talking about demo art, it is far too easy to concentrate on the social background ("the scene") instead of the actual substance of the artform and the kind of activity that makes it unique. For the purposes of this essay, I have therefore attempted to extract and define something that I call "Core Demoscene Activity". It is something I regard as the unique essence of demo art, the pulsating heart that gives it its life. All the other creative activities of demo art stem from the core activity, either directly or indirectly.

When defining "core demoscene activity", we first need to define what it isn't. The first things to rule out are the social aspects such as participating in demoscene events. These are important in upholding the social network, but they are not vital for the existence of demos. Making demos is supposed to be the reason for attending parties, not the other way around.

The core activity is not just "doing creative things with a computer" either. Everyone does it, even your mother. And not even "making non-interactive realtime animations", as there are other branches of culture that do the same thing -- the VJ and machinima communities, for example. Demos do have their own esthetic sensibilities, yes, but we are now looking for something more profound than that.

What is the most essential thing, in my opinion, is the program code. And not just any tame industry-standard code that fulfills some given specifications, but the wild and experimental code that does something that opens up new and unpredicted possibilities. Possibilities that are simply out of the reach of existing software tools. Although there are other areas of computer culture that practise non-compromising hard-core programming, I think the demoscene approach is unique enough to work as a basis of a wholesome definition.

The core activity of the demoscene is very technical. Exploration and novel exploitation of various possible hardware and software platforms. Experimentation with new algorithms, mathematical formulas and novel technical concepts. Stretching the expressive power of the byte. You can remove musicians, graphicians and conceptual experimenters, but you cannot remove hardcore experimental programming without destroying the essence of demo art.

The values and preferences of demoscene-style programming are very similar to those of traditional hackers (of the MIT tradition). A major difference, however, seems to be that a traditional hacker determines the hack value of a program primarily by looking at the code, while a demo artist primarily looks at the audiovisual output. An ingenious routine alone is not enough; it must also be presented well, so that non-programmers are also able to appreciate the hack value. A lot of effort is put in presentational tweaking in order to maximize the audiovisual impact. This relationship between code and presentation is another unique thing in demo art.

Here is a short and somewhat idealized definition of "Core Demoscene Activity":

Core Demoscene Activity is the activity that leads to the discovery of new techniques to be used in demo art.

Everything in Core Demoscene Activity needs to directly or indirectly support the discovery of new kind of audiovisual output. Either something not seen on your platform before, or something not seen anywhere before.

The exploration should ideally concentrate on things that are beyond the reach of existing software tools, libraries or de-facto standard methods. This usually requires a do-it-yourself approach that starts from the lowest available level of abstraction.

General-purpose solutions or reusable code are never required on this level, so they should not interfere with the research. Rewrite from scratch if necessary.

Of course, the core activity alone is not enough, as the new discoveries need to be incorporated in actual productions, which also often include a lot of content created with non-programmatical methods. So, here is a four-level scheme that classifies the various creative activities of demo art based on their methodological distance from the "core". Graphically, this could be presented as nested circles. Note that the scheme is not supposed to be interpreted as a hierarchy of "eliteness" or "trueness", it is just one possible way of talking about things.

First Circle / Core Demoscene Activity: Hardcore experimental programming. Discovery of new techniques, algorithms, formulas, theories, etc. which are put in use on the Second Circle.

Second Circle Activity: Application-level programming. Demo composition, presentational tweaking of effect code, content creation via programming, development of specialized content creation tools (trackers, demomakers, softsynths), etc.

Third Circle Activity: Content creation with experimental, specialized and "highly non-standard" tools. Musical composition with trackers, custom softsynths or chip music software; pixel and character graphics; custom content creation software (such as demomakers), etc.

Fourth Circle Activity: Content creation with "industry-standard tools" including high-profile software and "real-life" instruments. Most of the bitmap graphics, 3D modelling and music in modern "full-size" demos have been created with fourth-circle techniques. Design/storyboard work also falls in the fourth circle. Blends rather seamlessly with mainstream computer-aided creativity.

It should be noted that the experimental or even "avant-garde" attitude present in the Core Activity can also be found on the other levels. This also makes the Fourth Circle important: while it is possible to do conceptual experimentation on any level, general-purpose industry-standard tools are often the best choices when trying out a random non-technical idea.

The four-circle scheme seems to be applicable to some other forms of digital art as well. In the autumn 2009, the discovery of Mandelbulb, an outstanding 3D variant of the classic Mandelbrot set, inspired me look into the fractal art community. The mathematical experimentation that led to the discovery of the Mandelbulb formula was definitely a kind of "core activity". Some time later, an "easy-to-use" rendering tool called "Mandelbulber" was released to the community in what I would classify as "second-circle" activity. The availability of such a tool made it possible for the non-programmers of the community to use the newly discovered mathematical structure in their art in activities that would fall on the third and fourth circles.

Is it only about demos?

The artistic production central to demo culture is, obviously, the demo. According to the current mainstream definition, a demo is a stand-alone computer program that shows an audiovisual presentation, a couple of minutes long, using real-time rendering. It remains exactly the same from run to run, and you can't interact with it. But is this all? Is there something that demo artists can give to the world besides demos?

I'm asking this for a reason. The whole idea of a demo, defined in this way, sounds somewhat redundant to laymen. What is the point in emphasizing real-time rendering in something that might just as well be a prerendered video? Isn't it kind of wasteful to use a clever technical discovery to only show a fixed set of special cases? In order to let the jewels of Core Demoscene Activity shine in their full splendor, there should be a larger scale of equally glorified ways of demonstrating them. Such as interactive art. Or dynamic non-interactive. Maybe games. Virtual toys. Creative toys or games. Creative tools. Or something in the vast gray areas between the previously-mentioned categories.

The idea of a "non-interactive realtime show" is, of course, tightly knit with the standard format of demoparty competitions. Demos are optimized for a single screening for a large audience, and it is therefore preferrable that you can fix as many things as possible beforehand. Realtime rendering wasn't enforced as a rule until video playback capabilities of home computers had become decent enough to be regarded as a threat to the dominance of hardcore program code.

But it's not all about party screenings. There are many other types of venues in the world, and there are, for example, people who still actually bother to download demoscene productions for watching at home. These people may even desire more from their downloaded programs than just a couple of minutes of entertainment. There may be spectators who, for example, would like to create their own art with the methods used in the demo. Of the categories mentioned before, I would therefore like to elevate creative toys and tools to a special position.

It is proven that creative tools originating in the demoscene may give rise to completely new creative subcultures. Take trackers, for example. The PC tracker scene of the nineties was much wider than the demoscene which gave it the tools to work with. In the vast mosaic of today's Internet world, there is room for all kinds of niches. Release a sufficiently interesting creative tool, and with some luck, you'll inspire a bunch of freaks to find their own preferred means of creativity. The freaks may even form a tight-knit community around your tool and raise you to a kind of legend status you can't achieve with demo compo victories alone.

Back in the testosterone-filled days, you frowned upon those who used certain creative tools without understanding their deep technicalities. But nowadays, you may already realize the importance of "laymen" exploring the expressive possibilities of your ingenious routine or engine. If you are turned off by the fact that "everyone" is able to (ab)use your technical idea, you should move on and invent an even better one. The Core Activity is about continuous pushing of boundaries, not about jealously dwelling in your invention as long as you can.

Now, is there a risk that the demoscene will "bland out" if "non-demo productions" will receive as much praise and glory as the "actual" demos? I don't think so. To me, what defines the demoscene is the Core Activity and not the "realtime non-interactive production". As long as you nurture the hardcore spirit, it manifests itself in all kinds of things you produce, regardless of how static, realtime, bouncy or cubistic they are.

Parties and social networks

An important staple in keeping demo culture alive is the demoparty. It both strengthens the social bonds and motivates the people involved to create and release new material. Of course, extensive remote communication has always been there, but flesh-and-blood meetings are the ones that strengthen the relationships to span years and decades.

As there are so many people who have deeply dedicated theirselves to demo art for so many years, I am convinced that there will be demoscene parties in 2020 as well. Only a global disaster of an apocalyptic scale can stop them from taking place.

While pure insider parties may be enough for keeping the demoscene alive, they are not enough for keeping it strong and vital. There is a need for fruitful contacts between demo artists and other relevant people, such as other kinds of artists and potential newcomers. High-profile mainstream computer parties, such as Assembly, have been succesful in establishing these contacts in the past, but much of the potential for success has faded out during the last decade, as an average demo artist has less and less in common with an average Assembly visitor.

I think it is increasingly vital for demo artists to actively establish connections with other islets of creative culture they can relate to. The other high-profile Finnish demoparty, Alternative Party, has been very adventurous in this area. Street and museum exhibitions that bring demo art to "random" people may be fruitful as well, even in surprising ways. When looking for contacts, restricting oneself to "geeky subcultures" is not very relevant anymore, as everyone uses computers and digital storage formats nowadays, and being creative with them -- even in ways relevant to demo art -- does not require unusual levels of technological obsession.

Crosscultural contacts, in general, have the potential of giving demosceners more room to breath. While a typical demoparty environment strongly encourages a specific type of artwork (i.e. demos), other cultural contexts may inspire demo artists to create totally different kinds of artifacts. I'm also sure that many experimental artists would be happy to try out some unique creative tools that the demo community may be able to give to them, so the collaboration may work well in both directions.

Real and virtual platforms

The relationship between demo artists and computing platforms has changed dramatically during the past ten years. Back in the nineties, you had a limited number of supported platforms with separate scenes and competitions. Nowadays, you can choose nearly any hardware or software platform you like, and different platforms often share the same competitions. Due to the existence of decent emulators and easy video captures, the scene is no longer divided by gear ownership. Anyone can watch demos from any platform or even try to develop for almost any platform without owning the real hardware. Also, as the average age of demosceners has risen, platform fanboyism is now far less common.

The freedom is not as full as it could be, however. There are people who build their own demo hardware and they are praised for this, but what about creating your own entirely software-based "virtual platforms"? Most demo artists don't even think about this idea. Of course, there are many coders who have created ad-hoc integrated virtual machines in order to, for example, improve the code density in 4K demos, but "actual" platforms are still something that need to be defined by the industry. In the past, it even required quite a tedious process until a new hardware platform became accepted by the community.

So, why would we need virtual platforms in the first place? Let's talk about the expressive power of chip music, for example. There are various historical soundchips that have different sets of features and limitations, and after using several of them, a musician may not be completely satisfied by any single chip. Instead, he or she may imagine a "perfect soundchip" that has the exact combination of features and limitations that inspires him/her in the best possible way. It may be a slight improvement of a favorite chip or a completely new design. Still, someone who composes for a virtual chip rather than an authentic historical chip may not be regarded as very "true". There is still certain history-fetishism that discourages this kind of activity. In my earlier essay about Computationally Minimal Art, however, I expressed my belief that the historical timeline will lose its meaning in the near future. This will make "non-historical experimentation" more acceptable.

It is already relatively acceptable to run demos with emulators instead of real hardware, even in competitions, so I think it's only a matter of time that completely virtual platforms (or "fake emulators") become common. For many, this will be a blessing. Artists will be happier and more productive working with instruments that lack the design imperfections they used to hate, and the audience will be happier as it gets new kinds of esthetic forms to appreciate.

Virtual platforms may also introduce new problems, however. One of them is that none of the achieved technical feats can be appreciated if the platform is not well-understood by the audience: if you participate in a 256-byte competition with a demo written for your own separate virtual machine, it is always relevant for the spectator to assume that you have cheated by transferring logic from the demo code into the virtual machine implementation. You could, for example, put an entire music synthesizer in your virtual machine and just use a couple of bytes in the demo code to drive it. If you want your technical feats appreciated, the platform needs to pass some kind of a community acceptance process beforehand.

On the other hand, virtual platforms may eventually become mandatory for certain technical feats. It is already difficult in modern operating systems, for example, to create very small executables that access the graphics and sound hardware. As the platforms "improve", it may eventually become impossible to do certain things from within, say, a four-kilobyte executable. In cases like this, the community may need to solve the problem with a commonly accepted "virtual platform", i.e. a loader that allows running executables given in a format that has less overhead. Such a loader may also be used for fixing various compatibility problems that are certain to arise when new versions of operating systems come out.

Within some years from now, we may have a plethora of virtual machines attempting to represent "the ultimate demo platform". There will be a need for classifying these machines and deciding about their validity in various technical competitions. Despite all the possible problems and controversies they are going to introduce, I'm going to embrace their arrival.

But what about actual hardware platforms, then? I guess that there won't be as much difference by 2020 anymore. FPGA implementations of classic hardware have already been available for several years, and I assume it won't take long until it will be common to synthesize both emulators and physical hardware from the same source code. Once we reach the point that it is easy for anyone to use a printer-type device to produce a piece of hardware from a downloadable file, I don't think it'll really matter so much to anyone whether something is running virtually or physically.

Regarding the next decade of the mainstream hardware industry, I think the infamous Moore's law makes it all quite predictable and obvious: things that were not previously possible in real time will be easy to do in real time. There will be smaller video projectors and all that. Mobile platforms will be as powerful as today's high-end PCs, so you won't be able to get "oldschool kicks" from them anymore. If you want such kicks from an emerging technology, you won't have many niches left; conductive ink may be one of the last possibilities. Before 2020, your local grocery store will probably be selling milk in packages that have ink-based circuits displaying animations, and before that happens, I'm sure that the demoscene will be having lots of fun with the technology.

Paths of initiation

It is already a commonly accepted view that the demoscene needs newcomers to remain vital, and that they need to be actively recruited since the influx is no longer as overwhelming as it used to be. This view represents a dramatic change from the underground-elitist attitudes of the nineties, when potential newcomers were often forced thru a tight social filter that was supposed to separate the gifted individuals from the "lamers". Requiring guidance was a definitive sign of weakness; if you couldn't figure out the path of initiation on your own, no one was going to help you. You simply got stuck in the filter and never got in.

According to my experiences, it is not very difficult to get people interested in demo art as long as you manage to pull the right strings. It is also relatively easy to get them participate in demoscene events. But getting them involved in the various creative activies is a much more complex task, especially when talking about the inner-circle activities that require programming. It is not about a lack of will or determination but more like about uncertainty about how to get started.

A lot of consideration should be put in the paths of initiation during the following decade. Instead of generalizing from their own past experiences, recruiters should listen to the stories of the recent newcomers. What kind of paths have they taken? What kind of niches have they found relevant? What have been the most difficult challenges in getting involved? Success stories and failure stories should both be listened to.

I'm now going to present some of my own ideas and observations about how democoder initiation works in today's world and how it does not. These are all based on my personal experiences with recent newcomers and not on any objective research, so feel free to disagree.

First, I want to outline my own theory about programming pedagogy. This is something I regard as a meaningful "hands-on" path for hobbyist programmers in general, not only for aspiring democoders. Lazy academic students (whose minds get "mutilated beyond recovery" by a careless choice of first language) may prefer a more theoretical route, but this three-phase model is something I have witnessed to work even for the young and the practical-minded, from one decade to another.

First phase: Toy Language. It should have an easy learning curve and reward your efforts as soon as possible. It should encourage you to experiment and gradually give you the first hints of a programming mindset. Languages such as BASIC and HTML+PHP have been popular in this phase among actual hobbyists.

Second phase: Assembly Language. While your toy language had a lot of different building blocks, you now have to get along with a limited selection. This immerses you into a "virtual world" where every individual choice you make has a tangible meaning. You may even start counting bytes or clock cycles, especially if you chose a somewhat
restricted platform.

Third phase: High Level Language. After working on the lowest level of abstraction, you now have the capacity for understanding the higher ones. The structures you see in C or Java code are abstractions of the kind of structures you built from your "Lego blocks" during the previous phase. You now understand why abstractions are important, and you may also eventually begin to understand the purposes of different higher-level programming techniques and conventions.

Based on this theory, I think it is a horrible mistake to recommend the modern PC platform (with Win32, DirectX/OpenGL, C++ and so on) to an aspiring democoder who doesn't have in-depth prior knowledge about programming. Even though it might be easy to get "outstanding" visual results with a relative ease, the programmer may become frustrated by his or her vague understanding of how and why their programs work.

The new democoders I know, even the youngest ones, have almost invariably tried out assembly programming in a constrained environment at some point of their path, even if they have eventually chosen another niche. 8-bit platforms such as C-64 or NES, usually via emulator, have been popular choices for "first hardcore coding". Sizecoding on MS-DOS has also been quite common.

Not everyone has the mindset for learning an actual "oldschool platform" on their own, however. I therefore think it might be useful to develop an "educational demoscene platform" that is easy to learn, simple in structure, fun to experiment with and "hardcore" enough for promoting a proper attitude. It might even be worthwhile to incorporate the platform in some kind of a game that motivates the player to go thru varying "challenges". Putting the game online and binding it to a social networking site may also motivate some people quite a lot and give the project some additional visibility.

Conclusion

We have now covered many different aspects of the future of demo art in the 2010s, and it is now the time to summarize. If we crystallize the prognosis to a single word, "diversity" might be a good choice.

It indeed seems that the diversity in what demo artists produce will continue to increase in all areas. There will be more platforms available, many of them designed by the artists themselves. There will be more alternatives to the traditional realtime non-interactive demo, especially via the various "new" venues provided by "crosscultural contacts". And I'm sure that the range of conceptual and esthetic experimentation will broaden as well.

Back in the nineties, most demo artists were "playing the same game", with the same rules with relatively similar goals. After that, the challenges became much more individual, with different artists finding their very own niches to operate in. There are still "major categories" today, but as the new decade continues, they will have less and less meaning compared to the more individual quests. This may also reduce the competitive aspect of the demo culture: as everyone is playing their own separate game, it is no longer possible to compare the players. Perhaps, at some point of time, someone will even question the validity of the traditional compo format.

Another keyword for the next decade could be "openness". It will show both in the increased outreach and "crossculturality". There will be an increasing amount of demo artists who operate in other contexts besides the good old demoscene, and perhaps there will also be more and more "outsiders" who want to try out the "demoscene way" for a chance, without intentions of becoming more integral members of the subculture.

In the nineties, many in the scene were dreaming about careers in the video game industry. After that, there have been similar dreams about the art world: gaining acceptance, perhaps even becoming professional artists. The dreams about the video game industry came true for many, so I'm convinced that the dreams about the art world will come true as well.

Behind "Dramatic Pixels"

2010-04-18T16:36:00.000+01:00

I released a minimalistic demo called "Dramatic Pixels" at Breakpoint 2010. It is an experiment in narrative using very minimal visual output: three colored character blocks ("big pixels") moving on an entirely black background, synchronized to musical accompaniment. (CSDB, Pouet.net)

I was expecting the demo to cause very mixed reactions in the audience, but to my surprise, it actually won the competition it was in (4-kilobyte Commodore 64 demo) and the reception has been almost entirely positive. This -- along with the fact that a somewhat similar production was released by Skrju and Triebkraft for the ZX Spectrum just two months earlier -- inspired me to write this short essay about the philosophy behind this production. And besides, visy/trilobit has also blogged about "Dramatic Pixels" recently, so I think I am obliged to do the same.

Background

For quite some time already, I have been on a philosophical excursion to the nature of "hard-core" digital creativity, especially the deep essences of the demoscene and the "8-bit" culture. The so far biggest visible result of this excursion has been my recent essay about Computationally Minimal Art, which, among all, separates the ideas of "optimalism" and "reductivism". I have noticed that the audiovisual digital culture (including the demoscene) has traditionally been very optimalist in nature, aiming at fitting as much complexity as possible within given boundaries. The opposite approach, reductivism, which embraces minimal complexity itself as an esthetic goal, is very seldom used by the demoscene, however.

In December 2009, I was pondering about how to express "complex real-world phenomena" such as human emotions via "extreme reductivism". I was planning to design a low-pixel "video game character" that shows a wide range of emotions with facial and bodily expressions, and I particularly wanted to find out the minimum number of facial pixels required to express all the nine emotional responses (rasas) of the Indian theatre. When minimizing the number of pixels, however, I realized that facial expressions might not in fact be necessary at all; movement patterns and rhythms alone seemed to be enough for differentiating fear from bravery, or certainty from uncertainty. If the character only needs to move around for full expressive power, its pixel pattern can very well be reduced to a single pixel.

I quickly did a couple of experiments with this idea of "pixel drama". As the results were convincing enough, I started to plan a minimalistic movie using only single-pixel characters. As the movie was quite probably to be implemented as a demoscene production, I thought it would be important to have a somewhat "operatic" approach, synchronizing the visual action with a strong musical accompaniment.

After some initial sketches, I didn't really think about the idea for a couple of months. But less than a week before the Breakpoint party, I decided to implement it on the C-64. The choice of platform could have been just about anything, however, from VCS to Win32. C-64 just seemed like the best and easiest choice considering the competition categories available at Breakpoint. The size of the demo ended up to be about 1.5K bytes, and I later also released a 1K version where the introductionary text was removed.

The demo itself

Technically, everything in "Dramatic Pixels" is centered around the music player routine, which is also responsible for the choreography: the bytes that encode the notes of the lead channel also contain bits that control the movement of the pixels. To be exact, every time a new note is played by the lead instrument, exactly one of the three pixels takes a single step towards one of the four cardinal directions. This is an intentional technical decision that ties the pixel movement seamlessly to the music. Internally, the whole show is a series of looping sequences that are both musical and visual at the same time.

All the actual musical notes, by the way, are encoded by only two bits each. These two bits form an index to a four-note set, which is defined by two variables (indicating base pitch and harmonic structure). These variables are manipulated on the fly by a higher-level control routine that is also responsible for the other macro-level changes in the demo. I prefer to encode melodies in this way rather than as absolute pitches, as a more "indirect" approach makes it more compact and closer to the essence of the musical structure. And, in the case of this demo, I wanted some minimalism (or maybe serialism) in the musical score as well, and the possibility to repeat the same patterns in different modes helps in this goal.

The 6502 assembly source code of the 1K version is available for those who are interested. It should be relatively easy to port to any 6502-based platform (with the music player probably requiring most work), so I've been planning on releasing separate versions for VIC-20 and Atari 2600 as well.

So, what about the story, then? Most of the interpretations I've heard have been somewhat similar and close to my own intentions, so I think my decisions about the audiovisual language have been relatively succesful: Red and Blue meet, fall in love, become estranged, cheat on each other with Green, and in the end everyone gets killed. However, there are some portions that are apparently more difficult.

When I created the characters, I had no intentions of assigning genders to the pixels. Still, some people have interpreted Red as male and Blue as female. This probably stems from the differences in the base pitches (when Blue moves, the pitch is an octave higher than when Red moves), but the personalities of the pixels may also matter. Red is more stereotypically masculine, making more initiatives, while Blue mostly responds to these initiatives. I don't know whether the interpretations would have been different if I had chosen Blue to be the initiator.

The second part, where Red and Blue spend time on the opposite sides of the screen, is perhaps the most difficult to follow. I intended this part to represent everyday life where both pixels have their own daytime activities and only see each other at home very briefly in evenings (and don't pay much attention to one another even then). Also, the workplaces are so far away that the pixels can't see each other cheating until Red decides to get closer to Blue's workplace. And no, Green does not represent two different pixel personalities depending on the partner -- it's the same despisable creature in all cases. The part is intentionally slightly too long and repetitive in order to emphasize the frustration that repetitive everyday routines may lead to.

Comparison to the Spectrum demo

I would now like to compare "Dramatic Pixels" to the 256-byte Spectrum demo I mentioned earlier, "A true story from the life of a lonely cell" by Sq/Skrju and Psndcj/Triebkraft. Although I'm trying to follow the Spectrum demoscene due to some very visionary groups therein, this demo was so recent that I never managed to even hear about it until I had finished "Dramatic Pixels".

In both demos, there are three characters represented by solid-colored blocks. The blocks express emotion mostly by the way how they move. In "A true story", all movement happens in one dimension, so it is basically all about back-and-forth movement in varying rhythms. "Dramatic Pixels" can be very easily seen as a refinement of this concept, adding a musical accompaniment and another dimension (although it may very well have worked in 1D as well). The stories in both demos are based on the love triangle model, although my story is a little bit more complex.

"Great minds think alike", yes, but the coincidence still baffles me. Is it really just a coincidence or a result of some external factors? Deep thoughts about the state of the demoscene, perhaps combined with some general angst about the potential of the art form in the 2010s, were part of the mental process that lead me to create "Dramatic Pixels". I haven't discussed this with Sq, but perhaps there was something similar going on in his mind as well.

To add an additional spice to the mystery: the recent video game inspired short film called "Pixels" was put on the web on the same day (2010-04-07) as I put the video of "Dramatic Pixels" on Youtube.

The bigger purpose

For some time already, I have been writing pretty words about "thinking out of the box" in the demoscene context. But pretty words are hollow unless you back them up with some practical evidence, such as an actual demo.

I considered it important to finish "Dramatic Pixels" for Breakpoint, as I had just recently released my essay about Computationally Minimal Art. I wanted to release a production that would support some of its ideas, especially the equality of reductivism as a "boundary-pushing" approach.

When working on "Dramatic Pixels", I made two observations about my mental reactions. First, extreme visual minimalism can give me the same kind of "boundary-pushing shivers" as some groundbreaking optimalist demos can, so I got the subjective evidence I desired about the power of the reductivist approach. And second, despite the existence of the narrative, I never felt any "narrative embarrasment" that is almost a given with story-based demos (even the good ones). I don't yet know what the missing embarrassing element is; narrative text, dialogue, human-like characters? I still need to think this over, I guess.

Anyway, I hope this experiment broke some new ground that would inspire some further experimentation in computational minimalism. I think traditional minimalists have already done quite a lot of "basic research" during the last hundred years or so, so I would like the inspired productions to choose a fresh route by emphasizing those areas that are unique in the computational approach.

Defining Computationally Minimal Art (or, taking the "8" out of "8-bit")

2010-03-15T20:38:00.000Z

Introduction

"Low-tech" and "8-bit" are everywhere nowadays. Not only are the related underground subcultures thriving, but "retrocomputing esthetics" seems to pop up every now and then in mainstream contexts as well: obvious chip sounds can be heard in many pop music songs, and there are many examples of "old video game style" in TV commercials and music videos. And there are even "pixel-styled" physical products, such as the pictured watch sold by the Japanese company "&design". I'm not a grand follower of popular culture, but it seems to me that the trend is increasing.

The most popular and widely accepted explanation for this phenomenon is the "nostalgia theory", i.e. "People of the age group X are collectively rediscovering artifacts from the era Y". But I'm convinced that there's more to it -- something more profound that is gradually integrating "low-tech" or "8-bit" into our mainstream cultural imagery.

Many people have became involved with low-tech esthetics via nostalgia, but I think it is only the first phase. Many don't experience this phase at all and jump directly to the "second phase", where pixellated graphics or chip sounds are simply enjoyed the way they are, totally ignoring the
historical baggage. There is even an apparent freshness or novelty value for some people. This happens with audiences that are "too young" (like the users of Habbo Hotel) or otherwise more or less unaffected by the "oldskool electronic culture" (like many listeners of pop music).

Since the role of specific historical eras and computer/gaming artifacts is diminishing, I think it is important to provide a neutral conceptual basis for "low-tech esthetics"; an independent and universal definition that does not refer to the historical timeline or some specific cultural technology. My primary goal in this article is to provide this definition
and label it as "Computationally Minimal Art". We will also be looking for support for the universality of Computationally Minimal Art and finding ur-examples that are even older than electricity.

A definition: Computationally Minimal Art

Once we strip "low-tech esthetics" from its historical and cultural connections, we will be left with "pixellated shapes and bleepy sounds" that share an essential defining element. This element stems from what is common to the old computing/gaming hardware in general, and it is perfectly possible to describe it in generic terms, without mentioning specific platforms or historical eras.

The defining element is LOW COMPUTATIONAL COMPLEXITY, as expressed in all aspects of the audiovisual system: the complexity of the platform (i.e. the number of transistors or logic gates in the hardware), the complexity of the software (i.e. the length in bits of the program code and static data), as well as the time complexity (i.e. how many state changes the computational
tasks require). A more theoretical approach would eliminate the differentiation of software and hardware and talk about description/program length, memory complexity and time complexity.

There's little more that needs to be defined; all the important visible and audible features of "low-tech" emerge from the various kinds of low complexity. Let me elaborate with a couple of examples:

A low computing speed leads to a low number of processed and output bits per time frame. In video output, this means low resolutions and limited color schemes. In audio output, this means simple waveforms on a low number of discrete channels.

A short program+data length, combined with a low processing speed, makes it preferrable to have a small set of small predefined patterns (characters, tiles, sprites) that are extensively reused.

A limited amount of temporary storage (emerging from the low hardware complexity) also supports the former two examples via the small amount of available video memory.

In general, the various types of low complexity make it possible for a human being (with some expertise) to "see the individual bits with a naked eye and even count them".

In order to complete the definition, we will still have to know what "low" means. It may not be wise to go for an arbitrary threshold here ("less than X transistors in logic, less than Y bits of storage and less than Z cycles per second"), so I would like to define it as "the lower the better". Of course, this does not mean that a piece of low-tech artwork would ideally
constitute of one flashing pixel and static square-wave noise, but that the most essential elements of this artistic branch are those that persist the longest when the complexity of the system approaches zero.

Let me therefore dub the idealized definition of "low-tech art" as Computationally Minimal Art (CMA).

To summarize: "Computationally Minimal Art is a form of discrete art governed by a low computational complexity in the domains of time, description length and temporary storage. The most essential features of Computationally Minimal Art are those that persist the longest when the
various levels of complexity approach zero."

How to deal with the low complexity?

Traditionally, of course, low complexity was the only way to go. The technological and economical conditions of the 1970s and 1980s made the microelectronic artist bump into certain "strict boundaries" very soon, so the art needed to be built around these boundaries regardless of the artist's actual esthetic ideals. Today, on the other hand, immense and virtually non-limiting amounts of computing capacity are available for practically everyone who desires it, so computational minimalism is nearly always a conscious choice. There are, therefore, clear differences in how the low complexity has been dealt with in different eras and
disciplines.

I'm now going to define two opposite approaches to low complexity in computational art: optimalism (or "oldschool" attitude), which aims at pushing the boundaries in order to fit in "as much beauty as possible", and reductivism (or "newschool" attitude), which idealizes the low complexity itself as a source of beauty.

Disclaimer: All the exaggeration and generalization is intentional! I'm intending to point out differences between various extremities, not to portray any existing "philosophies" accurately.

Optimalism

Optimalism is a battle of maximal goals against a minimal environment. There are absolute predefined boundaries that provide hard upper limits for the computational complexity, and these boundaries are then pushed by fitting as much expressive power as possible between them. This approach is the one traditionally applied to mature and static hardware platforms by the
video game industry and the demoscene, and it is characterized by the appreciation of optimization in order to reach a high content density regardless of the limitations.

A piece of traditional European-style pixel graphics ("Frog, Landscape and a lot of Clouds" by oys) exemplifies many aspects of optimalism. The resolution and color constraints of a video mode (in this case, non-tweaked C-64
multicolor) provide the hard limits, and it is the responsibility of the artist to fill up the space as wisely and densely as possible. Large single-colored areas would look "unfinished", so they are avoided, and if it is possible to fit in more detail or dithering somewhere, it should be done. It is also avoidable to leave an available color unused -- an idea which leads to the infamous "Dutch color scheme" when applied to high/truecolor video modes.

When applied to chip music, the optimalist dogma tells, among all, to fill in all the silent parts and avoid "simple beeps". Altering the values of as many sound chip registers per frame as possible is thought to be efficient use of the chip. This adds to the richness of the sound, which is though to correlate with the quality of the music.

On platforms such as the Commodore 64, the demoscene and video game industry seem to have been having relatively similar ideals. Once an increased computing capacity becomes available, however, an important difference between these cultures is revealed. Whenever the video game
industry gets more disk space or other computational resources, it will try to use it up as aggressively as possible, without starting any optimization efforts until the new boundaries have been reached. The demoscene, on the other hand, values optimality and content density so much that it often prefers to stick to old hardware or artificial boundaries in order to keep the "art of optimality" alive. The screenshot is from the 4K demo "Artefacts" by Plush (C-64).

Despite the cultural differences, however, the core esthetic ideal of optimalism is always "bigger is better"; that an increased perceived content complexity is a requirement for increased beauty. Depending on the circumstances, more or less pushing of boundaries is required.

Reductivism

Reductivism is the diagonal opposite of optimalism. It is the appreciation of minimalism within a maximal set of possibilities, embracing the low complexity itself as an esthetic goal. The approach can be equated with the artistic discipline of minimal art, but it should be remembered that the idea is much older than that. Pythagoras, who lived around 2500 years ago, already appreciated the role of low complexity -- in the form of mathematical beauty such as simple numerical ratios -- in music and art.

The reductivist approach does not lead to a similar pushing of boundaries as optimalism, and in many cases, strict boundaries aren't even introduced. Regardless, a kind of pushing is possible -- by exploring ever simpler structures and their expressive power -- but most reductivists don't seem to be interested in this aspect. It is usually enough that the output comes out as "minimal enough" instead of being "as minimal as possible".

The visuals of the recent acclaimed Flash-based platformer game, VVVVVV, are a good example of computational minimalism with a reductivist approach. The author, Terry Cavanagh, has not only chosen a set of voluntary "restrictions" (reminiscent of mature computer platforms) to guide the
visual style, but keeps to a reductivist attitude in many other aspects as well. Just look at the "head-over-heels"-type main sprite -- it is something that a child would be able to draw in a minute, and yet it is perfect in the same iconic way as the Pac-Man character is. The style totally serves its purpose: while it is charming in its simplicity and downright naivism, it
shouts out loud at the same time: "Stop looking at the graphics, have fun with the actual game instead!"

Although reductivism may be regarded as a "newschool" approach, it is possible to find some slightly earlier examples of it as well. The graphics of the 1986 computer game Thrust, for example, has been drawn with simple geometrical lines and arcs. The style is reminiscent of older vector-based arcade games such as Asteroids and Gravitar, and it definitely serves a technical purpose on such hardware. But on home computers with bitmapped screens and sprites, the approach can only be an esthetical one.

Optimalism versus Reductivism

Optimalism and reductivism sometimes clash, and an example of this can be found in the chip music community. After a long tradition of optimalism thru the efforts of the video game industry and the demoscene, a new kind of cultural branch was born. This branch, sometimes mockingly called
"cheaptoon", seems to get most of its kicks from the unrefined roughness of the pure squarewave rather than the pushing of technological and musical boundaries that has been characteristic of the "oldschool way". To an optimalist, a reductivist work may feel lazy or unskilled, while an
optimalist work may feel like "too full" or "too refined" to a reductivist mindset.

Still, when working within constraints, there is room for both approaches. Quite often, an idea is good for both sides; a simple and short algorithm, for example, may be appreciated by an optimalist because the saved bytes leave room for something more,, while a reductivist may regard
the technical concept as beautiful on its own right.

Comparison to Low-Complexity Art

Now I would like to compare my definition of Computationally Minimal Art to another concept with a somewhat similar basis: Jürgen Schmidhuber's Low-Complexity Art.

While CMA is an attempt to formalize "low-tech computer art", Schmidhuber's LCA comes from another direction, being connected to an ages-old tradition that attempts to define beauty by mathematical simplicity. The specific mathematical basis used in Schmidhuber's theory is Kolmogorov complexity, which defines the complexity of a given string of information (such as a picture) as the length of the shortest computer program that outputs it. Kolmogorov's theory works on a high level of generalization, so the choice of language does not matter as long as you
stick to it.

Schmidhuber sees, in "down-to-earth coder terms", that the human mind contains a built-in "compressor" that attempts to represent sensory input in a form as compact as possible. Whenever this compression process succeeds well, the input is perceived as esthetically pleasing. It is a well-studied fact that people generally perceive symmetry and regularity as more beautiful than unsymmetry and irregularity, so this hypothesis of a "mental compressor" cannot be dismissed as just an arbitrary crazy idea.

Low-Complexity Art tests this hypothesis by deliberately producing graphical images that are as compressible as possible. One of the rules of LCA is that an "informed viewer" should be able to perceive the algorithmic simplicity quite easily (which also effectively limits the time complexity of the algorithm, I suppose). Schmidhuber himself has devised a system based
on indexed circle segments for his pictures.

The above picture is from "Superego", a tiny pc demo I made in 1998. The picture takes some tens of bytes and the renderer takes less than 100 bytes of x86 code. Unfortunately, there is only one such picture in the demo, although the 4K space could have easily contained tens of pictures. This is because the picture design process was so tedious and counter-intuitive --
something that Schmidhuber has encountered with his own system as well. Anyway, when I encountered Schmidhuber's LCA a couple of years after this experiment, I immediately realized its relevance to size-restricted demoscene productions -- even though LCA is clearly a reductivist approach as opposed to the optimalism of the mainstream demoscene.

What Low-Complexity Art has in common with Computationally Minimal Art is the concern about program+data length; a minimalized Kolmogorov complexity has its place in both concepts. The relationship with other types of complexity is different, however. While CMA is concerned about all the types of complexity of the audiovisual system, LCA leaves time and memory complexity out of the rigid mathematical theory and into the domain of a "black box" that processes sensory input in the human brain. This makes LCA much more theoretical and psychological than CMA, which is mostly concerned about "how the actual bits move". In other words, LCA makes you look at
visualizations of mathematical beauty and ignore the visualization process, while CMA assigns an utmost importance to the visualizer component as well.

Psychological considerations

Now, an important question: why would anyone want to create Computationally Minimal Art for purely esthetical reasons -- novelty and counter-esthetic values aside? After all, those "very artificial bleeping sounds and flashing pixels" are quite alien to an untrained human mind, aren't they? And even many fans admit that a prolonged exposure to those may cause headache.

It is quite healthy-minded to assume that the perception mechanisms of the human species, evolved during hundreds of millions of years, are "optimized" for perceiving the natural world, a highly complex three-dimensional environment with all kinds of complex lighting and shading conditions. The extremely brief technological period has not yet managed to alter the "built-in defaults" of the human mind anyhow. Studies show, for example, that people all over the world prefer to be surrounded by wide-open landscapes with some water and trees here and there -- a preference that was fixed to our minds during our millions of years on the African savannah.

So, the untrained mind prefers a photorealistic, high-fidelity sensory input, and that's it? No, it isn't that simple, as the natural surroundings haven't evolved independently from the sensory mechanisms of their inhabitants. Fruits and flowers prefer to be symmetric and vivid-colored because animals prefer them that way, and animals prefer them that way because it is beneficial for their survival to like those features, and so on. The natural world is full of signalling which is a result of millions of years of coevolutionary feedback loops, and this is also an important source for our own sense of esthetics. (The fish in the picture, by the way, is a Synchiropus splendidus, photographed by Luc
Viatour.)

I'm personally convinced that natural signalling has a profound preference for low complexity. Symmetries, regularities and strong contrasts are important because they are easy and effortless to detect, and the implementation requires a relatively low amount of genetic coding on both
the "transmitter" and "receiver" sides. These are completely analogous to the various types of computational complexity.

So, why does enjoying Computationally Minimal Art require "mental training" in the first place? I think it is not because of the minimality itself but because of certain pecularities that arise from the higher complexity of the natural world. We can't see individual atoms or even cells, so we haven't evolved a built-in sense for pixel patterns. Also, the sound generation
mechanisms in nature are mostly optimized to the constraints of pneumatics rather than electricity, so we don't really hear squarewave arpeggios in the woods (although some birds may come quite close).

But even though CMA requires some special adjustment from the human mind, it is definitely not alone in this area. Our cultural surroundings are full of completely unnatural signals that need similar adjustments. Our music uses instruments that sound totally different from any animal, and
practically all musical genres (apart from the simplest lullabies, I think) require an adjustment period. So, I don't think there's nothing particularly "alien" in electronic CMA apart from the fact that it still hasn't yet integrated in our mainstream culture.

CMA unplugged

The final topic we cover here is the extent where Computationally Minimal Art, using our strict definition, can be found. As the definition is independent from technology, it is possible to find ur-examples that predate computers or even electricity.

In our search, we are ignoring the patterns found in the natural world because none of them seem to be discrete enough -- that is, they fail to have "human-countable bits". So, we'll limit ourselves to the artifacts found in human culture.

Embroidery is a very old area of human culture that has its own tradition of pixel patterns. I guess everyone familiar with electronic pixel art has seen cross-stitch works that immediately bring pixel graphics in mind. The similarities have been widely noted, and there have been href="http://www.spritestitch.com/">quite many craft projects inspired by old video games. But is this just a superficial resemblance or can we count it as Computationally Minimal Art?

Cross-stitch patterns are discrete, as they use a limited set of colors and a rigid grid form which dictates the positions of each of the X-shaped, single-colored stitches. "Individual bits are perceivable" because each pixel is easily visible and the colors of the "palette" are usually easy to tell apart. The low number of pixels limits the maximum description length, and one doesn't need to keep many different things in mind while working either. Thus, cross-stitch qualifies all the parts of the definition of Computationally Minimal Art.

What about the minimization of complexity? Yes, it is also there! Many traditional patterns in textiles are actually algorithmic or at least highly repetitive rather than "fully hand-pixelled". This is somewhat natural, as the old patterns have traditionally been memorized, and the memorization is much easier if mnemonic rules can be applied.

There are also some surprising similarities with electronic CMA. Many techniques (like knitting and weaving) proceed one complete row of "pixels" at a time (analogous to the raster scan of TV-like displays), and often, the set of colors is changed between rows, which is corresponds very well to the use of raster synchronization in oldschool computer graphics. There are even peculiar technique-specific constraints in color usage, just like there are similar constraints in many old video chips.

The picture above (source) depicts a pillow knitted with the traditional Fair Isle technique. It is apparent that there are two colors per "scanline", and these colors are changed between specific lines (compare to rasterbars). The patterns are based on sequential repetition, with the sequence changing on a per-scanline basis.

Perhaps the most interesting embroidery patterns from the CMA point of view are the oldest ones that remain popular. During centuries, the traditional patterns of various cultures have reached a kind of multi-variable optimality, minimizing the algorithmical and technical complexity while maximizing the eye-pleasingness of the result. These patterns may very well
be worth studying by electronic CMA artists as well. Things like this are also an object of study for the field of ethnomathematics, so that's another word you may want to look up if you're interested.

What about the music department, then? Even though human beings have written music down in discrete notation formats for a couple of millennia already, the notes alone are not enough for us. CMA emphasizes the role of the rendering, and the performance therefore needs to be discrete as well. As it seems that every live performance has at least some non-discrete variables, we will need to limit ourselves to automatic systems.

The earliest automatic music was mechanical, and arguably the simplest conceivable automatic music system is the musical box. Although the musical box isn't exactly discrete, as the barrel rotates continuously rather than stepwise, I'm sure that the pins have been positioned in an engineer's accuracy as guided by written music notation. So, it should be discrete enough to satisfy our demands, and we may very well declare the musical box as being the mechanical counterpart of chip music.

Conclusion

I hope these ideas can provide food for thought for people interested in the various forms of "low-tech" electronic art as well as computational art or "discrete art" in general. I particularly want people to realize the universality of Computationally Minimal Art and how it works very well outside of the rigid "historical" contexts it is often confined into.

I consciously skipped all the cultural commentary in the main text on my quest for proving the universality of my idea, so perhaps it's time for that part now.

In this world of endless growth and accumulation, I see Computationally Minimal Art as standing for something more sustainable, tangible and crafty than what the growth-oriented "mainstream cultural industry" provides. CMA represents the kind of simplicity and timelessness that is totally immune to the industrial trends of fidelity maximization and planned obsolescence. It is something that can be brought to a perfection by an individual artist,
without hiring a thousand-headed army of specialists.

As we are in the middle of a growth phase, we can only guess what kind of forms Computationally Minimal Art will get in the future, and what kind of position it will eventually acquire in our cultural framework. We are living interesting times indeed.

Putting the demoscene in a context

2009-11-07T21:25:00.000Z

A couple of months ago, there were a couple of interesting attempts at introducing the demoscene to art-oriented audiences.

After the Alternative Party 2008, I wrote about the demoscene seminar held in the premises of the Finnish Academy of Fine Arts. Many of the participants (mostly the presenters themselves) then ended up writing articles which were published in the December 2008 issue of Mustekala, a Finnish art webzine.

One of the articles -- that is, elfh/inward's text about the development of the Spectrum demoscene in Russia -- was also later partially republished on a new and promising "8-bit" website called 8bittoday.com. Some of the articles have also been recently quoted in href="http://www.minedu.fi/OPM/Julkaisut/2009/Mediataiteen_mahdollisuudet__Selvitys_mediataiteesta">Finnish Ministry of Education study on the current state and future possibilities of new media art in Finland, which, among all, discusses the demoscene as a separate branch of new media art.

Another related thing that seized my attention in December was Rosa Menkman's summary of Anders "Goto80" Carlsson's
presentation he held at the HAIP Festival in Slovenia about the chip music scene and the 8-bit demoscene. A great deal of things in this summary seems to have been "lost in translation", i.e. mutated into somewhat hilarious misconceptions and inaccuracies.
Fortunately, after finding Goto80's own summary and having a correspondence with him I think I have been able to catch the message he wished to deliver.

In all, there was a lot of material to digest in all these texts, and the digestion process produced quite many thoughts, so be aware that this article will be quite long and covers a multitude of topics.

Which box does this stuff belong in?

Arguably the most difficult task in introducing the demoscene to any audience is, due to the relative self-sufficiency of the community, the task of fitting it in some pre-existing framework. I have noticed that there are basically four different "boxes" for trying to fit the scene into:

The "digital underground box", along with the mainstream hacker culture, open-source movement, political pirates and many Internet-based creative communities.

The "artistic movements box", in the same corner as experimental film and video art.

The "youth subcultures box", just between the punks, the graffiti painters and the LAN gamers.

The "trash box", which contains all the various clueless views that do not tolerate a deeper analysis, such as ones with obvious causality errors ("demos are primarily made for gaining employment in the video game industry").

Of the material I previously mentioned, Anders Carlsson's presentation represents the "first-box approach", whereas the Mustekala articles mostly go for the "second box". The "third box" was quite dominant in the nineties, especially prior to the mainstream penetration of the Internet and the cultural forms therein, and it still quite often used when discussing big "computer lifestyle" parties which originated as demoparties (i.e. Assembly).

I think each one of these "boxes" (or at least the first three of them) represents a valid approach, but none of them alone is enough. Thus, all of them need to be considered in order to build a complete picture of how the demoscene relates to everything else. Each "box" also has its own traps which can be hard to avoid.

It is also possible to talk about demo art without binding it inseparably to the scene. Computer programs that resemble demoscene demos can indeed be found outside of the demoscene context, and some even predate mass-produced microcomputers for several decades (i.e. the display hacks in the academic hacker culture).

Is it open-source?

The demoscene (along with the early software piracy/cracking scene where it comes from) pioneered quite many things which are nowadays seen as integral to the modern "digital subcultures". Let me list the ones I consider the most important:

global unrestricted peer-to-peer sharing of digital data (albeit originally primarily with snailmail instead of electronic telecommunications)

creating music and other types of art primarily or even exclusively for free non-commercial digital sharing (I think this is quite obvious)

using elements taken from video games and other creative digital works in one's own creations (ripped game music in demos was commonplace in the early years, as was sample-ripping slightly later)

Anders Carlsson dubs it "the first digital global subculture", which I consider quite accurate.

It is far too easy to extrapolate from the known facts, however. Outsiders, having done such an extrapolation in their minds, are particularly eager to associate the concept of "open source" to the demoscene. Rosa Menkman, when referring to Anders Carlsson's presentation, writes: "Because most products are open source, remixing is very easy". This mistake shows how careful
"outreachers" need to be when talking about this fashionable concept -- especially at an event like HAIP Festival, which is centered around artistic expression in open-source media.

Also Jarkko Räsänen mentions this tendency of finding "open-source" connections in his Mustekala article, and both Räsänen and Carlsson use tracker music as a prime example of an "open source" approach on the scene: you can load a song to a tracker and have the same editing capabilities as the original author had. Carlsson even extends this concept to anything made with a machine code monitor or an assembler: the disassembly you're reading is the same code the original author worked on.

My own stance in this matter is still more or less the same as in one of my 2007 articles. In the early days, crackers were quite accustomed to reading and modifying other people's machine code, so practically all software was "open-source" to them, and similar forms of hacking could be applied. This is still quite far from today's open-source culture, however, and binary-hacking of other people's code is quite rare on today's demoscene.

Those who know about various "hacking" subcultures may very well assume that an open-source ideology and a total freedom of "remixing" are the logical conclusion of anything that grows out of free digital sharing. The demoscene, however, is an example of a digital subculture that took a
totally different route -- one that emphasizes the author's own vision and talent -- resulting in a radical do-it-yourself attitude to which many "open-source" ideas (such as derivative works) are alien. Rosa Menkman refers to this attitude as "originality dogma".

The freedom of distribution is embraced on the demoscene mainly for the maximization of one's own (group's) fame via the maximization of the potential audience. Even many of the outreach efforts (such as presentations, lectures and articles about the scene) can be explained as part of this "quest for fame". If you spread the word about the demoscene to other people and make the productions more accessible to them, you are also more likely to get your own work appreciated.

Still, I disagree with Räsänen's view that the source code is usually hidden because of "jealousy". In my opinion, the main reason for this is the do-it-yourself attitude (or "originality dogma") itself: most sceners simply do not need or even want the source code, as they think it is "cooler" to do all the stuff on their own (or, alternatively, think it is
"lame" to use a piece of code whose inner workings they don't understand perfectly).

Source code, whenever it is available, is supposed to be handled with respect, primarily for technical inspiration and learning material. Whenever something is copied, the original author must always be credited. This differs quite radically from the culture of unrestricted use, remixing and bastardization one can find in the open source culture as well as today's Internet culture, including popular websites such as Wikipedia, YouTube and 4chan.

Does it fit in the art world?

The question whether demos are art is an old one, but it still continues to divide people. Anders Carlsson, for example, has chosen to present the demoscene as craftmanship rather than art. Indeed, the "crafty" aspect is still quite strong, and many sceners dislike their works being referred to as "art". However, there's also a big portion of sceners who have "true"
artistic ambitions and sometimes even a willingness to receive appreciation from the "mainstream" art world. Quite many sceners have even studied in art schools, which has lead them to a position from which to compare the two worlds.

Jarkko Räsänen (whom I remember as having been in wAmmA but whose handle I can't recollect) is one of the demoscene-affiliated people who have been studying in the Finnish Academy of Fine Arts in the recent years. In his article in Mustekala, he mostly compares the demoscene and some areas of the art world, based on his studies and first-hand
experiences.

As for social aspects, Räsänen finds similarities between the demoscene and the various audiovisual technology hobbyist groups he learned about when studying the history of experimental film and video art. These hobbyists had their own happenings, competitions and workshops, and especially the stories about dedicated club activity of Finnish narrow-film
hobbyists of the seventies brought the demoscene and demoparties in mind.

A strong common denominator between these art groups and the demoscene, according to the article, can be found in the self-sufficient attitude: the creators and the audience are the same. The esthetic criteria are those of the creators themselves, not anyone else's. Sometimes, a work "leaks" out of the community, and these leaked works are labelled as "underground".

As for outward appearances, Räsänen has found similarities between demos and the works of certain video artists. He describes the demo-likeness of the works of a video art group called Pink Twins as "baffling", and also Kari Yli-Annala, who reviewed their recent Helsinki exhibition, describes their esthetic as very similar to that of the demoscene. However, I wouldn't regard this similarity as a mere coincidence. Given that the guys are two brothers in their thirties living in Helsinki, formed their group in the late nineties and create their art on
computers via programming, it would be quite improbable that they were not at least aware of demos.

Still, astounding outwards similarity to demos can be found in some art films that predate the demoscene by several decades. In 2007, when I found a video of Whitney's Catalog on YouTube, for example, I was baffled by its demo-likeness (which probably stems from the procedural basis of the animation). Also, some very early experimental films by Oskar Fischinger were screened at the Breakpoint demoparty in 2004 because some scener thought it would be nice to enlighten the participants about "the first demos ever". In this case, the apparent similarity probably comes from the use of abstract music-synchronized visuals.

So, common grounds between the demoscene and film/video-based art can be found in the areas of social structures and outward esthetics. The biggest differences, according to Räsänen, seem to be in the conventions of distribution: while the demoscene has grown within a culture of unrestricted digital distribution, the art world has its legacy of galleries and expensive artifacts. Even art videos presented in galleries, despite being shown from materially cheap and easily duplicable DVDs, may cost "tens of thousands of euros", which is somewhat difficult for someone grown in the "pirate generation" to understand.

Modernism and medium-specificity

The modernist movement(s) have been referred to by both Jarkko Räsänen and Kari Yli-Annala in their articles. Relating the demoscene to something that saw its golden age in the early 20th century, in very different cultural and technological conditions, may sound far-fetched, but I personally find this comparison quite intriguing.

Modernist thought, if I've interpreted my art history correctly, is characterized by a certain kind of "engineer's idealism": the artist is like an engineer who avoids the old, outdated and inefficient "traditional" way of thinking and constantly tries to innovate something better, more
efficient and more optimal. This kind of progressivism can also be found on the demoscene, where it has been important to reach new technical standards in code optimality and an ever-deeper understanding of the platform of choice.

The modernist principle of medium-specificity holds that each art form has its own unique "essence", and artists should try to find this essence in the medium they're working on. A film-maker, for example, should not try to imitate staged theatre on film but create something that is only possible on film.

According to Räsänen, the demoscene has been able to get closer to the "essence" of computer-based art than most of the "true" artists who explore the medium, and this is why these artists should look into demos for an important lesson. Video art, for example, often neglects the role of the actual technological platform: if loudspeakers or computers are present in
the gallery space, a mainstream artist may just ignore them, while a demoscener would find them essential to the experience.

To me it seems that the medium is explored on the demoscene particularly on the lowest level of abstraction, in the form of "platform-specificity": traditional demos, especially ones written for more restricted platforms, use highly platform-specific tricks in order to implement their effects. Sometimes, the features of a specific platform lead the author to use a
specific, "platform-optimal" means of representation (for instance, preferring vertical scrolling direction on the Atari 2600, or using simple and inexpensive copper tricks for transitions on the Amiga 500). In this way, each demoscene platform builds its own platform-specific audiovisual
"dialect". Similarly, size-restricted categories and software platforms also build their own "dialects".

Still, there are some areas where the demoscene has done relatively little in regards to finding the medium-specific essence. Räsänen brings up the rareness of generativity (productions that are different on each run and maybe even interactive) as well as the tendency of sticking to the basic structure of a music video. This leads me to my next topic --

The forgotten levels of content

The general unwillingness to question the traditional demo structure is, in my opinion, connected to the demoscene's overwhelming focus on the lowest levels of abstraction. The higher the level, the less important it is considered to be, and the very highest levels are simply out of the scope where variation, exploration and innovation are generally considered to be "allowed". It's a pity, since, in my opinion, the core creative ideals of the demoscene can very well be extrapolated to higher levels (for example, think about the idea of "Homo Sapiens" as a demo platform).

It has always been important for demos to be technically solid. Another important element has been the superficial esthetics (looking good, sounding good, flowing good). Esthetic experimentation has also been taking place in the form of different styles and moods. For most demos, however, there's nothing beyond technique and esthetics. No message, no story, no underlying philosophy, no point. These demos are, from a conceptual point of view,
hollow works of craft.

Of course, there are also demos with a stronger focus on content, but even they are usually defined by their technical and esthetical choices rather than the content itself; bottom-to-top instead of top-to-bottom. The concept in a "high-concept demo" or the story in a "storydemo" is far too often just an additional spice, just another element that pleases the crowd, increases
the entertainment value and adds to the perceived coherence.

It is a regrettably common view that the low-level craftwork is what the demoscene has always been and should always be all about, and all attempts to extend the experimentation to higher levels are futile. I always hate hearing closed-minded opinions like this, as I see so much untapped potential within the immediate reach of most demoscene artists.

Interactivity is an example of a dimension that has always been within an easy reach for demoscene artists but has still remained nearly untouched. While demos experiment very deeply on the audiovisual nature of various technological platforms, they have barely managed to scratch the surface of what I consider part of the very essence of the real-time computer art
medium itself.

When sticking to static non-interactive works, a demo artist is not really doing anything that couldn't be achieved by non-realtime means. However, when experimenting with interactivity, the artist steps into a territory where the concept of real-time calculation gains actual meaning. This territory is totally unreachable by traditional non-realtime mediums such as
motion picture.

I've understood that interactivity is an idea where both the demoscene and the traditional art world have encountered "compatibility problems". Video games, however, have always been interactive to their very core, so I think they are the form of art where everyone willing to create interactive art should take a look at. "The Realtime Art Manifesto", coming from a group of artistic video game developers, is, in my opinion, worth reading by anyone interested in interactive art, despite having been written from the point of view of a specific kind of narrative games, and despite having
some silly misconceptions (like its references to "modern art").

Of course, there are also video games released in the demoscene context, but they rarely commit deep excursions into the essence of interactivity. Instead, they tend to focus on the technical issues where the existing strengths of existing demoscene methods can be applied.

The role of humor

It is difficult for the demoscene to explore the higher levels of abstraction, as the community primarily observes the lower levels. One always needs to consider the technical and esthetical standards of excellence in order to receive the praise and encouragement from the
community, and this burden often leaves "groundbreaking conceptual ideas" in a secondary position.

"Non-serious" productions, however, are a totally different issue. Even though they are often regarded as mere "comic relief" productions, they have, in my opinion, a vast amount of experimental potential that is often overlooked. When working on a "joke" production, especially under a "fake" pseudonym, a demoscener is much freer to experiment on some higher-level
aspects than with a "serious" approach.

Well-established "jokegroups" often have very distinctive styles and attitudes. I would particularly like to praise a well-established Finnish group, ISO, for being an example of a true "avant-garde" approach by turning nearly every traditional demoscene value upside down. For me, ISO is the punk and dadaism
of the Finnish demoscene, especially as it often goes quite deep into consciousness-streamed absurdism.

I would also like to mention my own group, PWP, which originated as a pseudo-jokegroup with a focus on humorous character-driven stories. I still carry something from the original PWP style and mindset even in my "serious" demos, so I think the "silly jokes" definitely served a greater purpose than being short-lived crowd-pleasers at various events.

The role of humor in some experimental demoscene-originating games, such as Sumotori Dreams and Porrasturvat, shouldn't be neglected either, especially regarding that they are interactive works that have gained praise far beyond the demoscene, e.g. in the indie gaming community.

Do they have any critical potential?

When looking at the Mustekala articles which analyze the demoscene, it is possible to notice the abstraction-level problem I discussed earlier: there's a lot of text on the technical and esthetical aspects of demos, but the only article that considers the conceptual aspects is the one written by the non-demoscener (new media artist and researcher Kari Yli-Annala).

I find this article, titled "Demoscene as immanent critique of computer culture", quite interesting for various reasons. First, the use of demos as commentary is a rather "new" thing and not very popular at that. Second, in spite of this "newness", my own work on the demoscene has had a critical aspect from the very beginning. And third, Yli-Annala uses yours truly as
an example of the critical dimension of the demoscene.

Personally, I see that there are basically two separate approaches of making critical statements in demos: technical and conceptual. The technical approach stems from the choice of technology and restrictions (something that is at the very core of the artform), while the conceptual approach is based on the things which are actually seen and heard.

The use of very restricted or "obsolete" platforms or doing something with a very limited file size is often considered to require a certain attitude, and the statements inherent to such technological choices are related to this attitude. Personally, I like my 8-bit demos seen as having an inherent statement directed against the "wasteful" aspects of mainstream computing -- not only the wasteful use of computing resources but also to the ecological wastefulness of consumerism and high-tech snobbery.

The conceptual approach, on the other hand, can be used to deliver nearly any message (just like motion pictures). Since the early days, there have been demos containing political statements (such as Fairlight's anti-communist sentiments) as well as productions that comment aspects of the scene itself. My own work has had both of these among the multitude of
topics it has covered.

What Yli-Annala talks about the most is immanent critique. That is, critique coming from the within. In my opinion, this is not something that works very well within the usual demoscene context, especially these days, when demos are seldom actively watched by people outside the scene itself. However, whenever a demoscener dares to take effort of bringing something
into "other scenes", there may be a lot of critical potential.

The video game .kkrieger is a prime example of such an "inter-subcultural" intervention: instead of creating just another size-limited demo, the demoscene group .theprodukkt decided to make a size-limited video game instead. By simply choosing another format that is
more accessible to video gaming audience, .theprodukkt managed to critique aspects of the video game culture from inside the video game culture itself. The mere use of demoscene techniques and a tight size limitation served as a statement.

There are many possible ways for a demoscener to do interventions like this, however some of them don't have anything to do with the demoscene or even with skills relevant to demomaking. I, for example, have been doing on-line interventions (using things such as fake textfiles, trolling, fake websites, parodies, etc.) since the early 1990s, that is, longer than I have even been involved with demos. I've never regarded it as anything artistic, so, I found it quite amusing that Kari Yli-Annala, when discussing the critical potential of the demoscene, draws examples from some of my web projects.

What about avant-garde?

In his article, Yli-Annala has noticed that demos have a lot of recognizable cultural imagery that is used and combined in unusual ways. Similarly, "cultural technologies" (such as hardware platforms) are often used in novel means. This kind of recognition and recombination of cultural elements is considered typical of postmodernism.

While I find most points of the discussion relevant, there are some parts I disagree with. To begin with, here follows my translation of the final summary of the article: "The demoscene is underground and avant-garde of new media art, as it is based on cultural technologies and imagery by refining raw material and concretely biting into the code level. Its traditions of representation and making are, in the manner of artists' radical avant-garde movements, based on an introvert potential of renewal and on a collectivity created from this hermeneutics."

It is true that there is a lot of cultural imagery used even in mainstream demos. Even the most unimaginative mid-1990s demos tend to have graphical elements such as dragons, swords and half-naked warrior girls, which quite clearly stem from a pop-cultural background (i.e. film posters, graphic novels, book covers, musical record illustrations, etc.) However, in the traditional demo design, this material merely serves the technical and esthetical levels of abstraction. It does not really matter what the pictures depict or where they come from, as long as they look good (technically and esthetically) and cause the desired reaction in the
viewer.

It is also true that hardware platforms (such as 8-bit computers) are cultural artifacts, and thus, using them for novel purposes (such as new demo effects) could be regarded as "postmodern" reuse of pre-existing elements. In my opinion, however, this idea sounds quite far-fetched. To
me, technological devices, when used as demo platforms, get rid of their cultural and historical value altogether, and the only thing that matters is the plain technological structure and what possibilities and challenges it offers to the artist. I assume this is quite close to how most musicians relate to their instruments, for example.

What about the conclusion, then? I don't think there's much doubt that demoscene is "underground", but is it an avant-garde movement?

Avant-garde, in short, is about "pushing the boundaries", which is also an important principle on the demoscene. Although the mainstream demoscene only applies this idea to certain key areas, there are "rebel" movements, such as "joke" or "fake" groups, that supplement the mainstream by questioning the traditions and expanding the range where the boundary-pushing attitude can
be applied.

Quite often, a single demoscene artist has two "faces" -- one for "traditional" productions and another for ones that may clash against the tradition. The different faces usually manifest themselves via separate group labels; most of the members of HiRMU and Jumalauta, for example, are also members of "serious" groups and use different pseudonyms there.

Based on my personal experiences, I would say that there is an avant-garde branch within the demoscene, but when combining all the aspects of the demoscene and asking whether it is "avant-garde" as a whole, I'm not so sure anymore. I would perhaps rather see it as a bipolar system in this matter.

Conclusion

After all this discussion, it seems that doing generalizations about the demoscene and putting it in a single context is very difficult. There are all kinds of approaches and disciplines within the subculture: traditionalist and avantgarde, fame-seeking and underground, technical and
conceptual, crafty and artistic, competitive and self-expressive. Each artist is different, and choosing a single-minded definition doesn't really do justice to all the variety.

Why can't we just ignore the variety to make things easier, then? Because it is exactly this variety that has managed to keep the scene alive for so many years. On one hand, groups that embrace their own vision instead of looking for maximum appeal within the community have been able to extend the horizon every now and then, sometimes even recruiting some new blood in the
process. And on the other hand, without all the stubborn and conservative attitudes, the scene would have lost its distinctiveness -- the shell that protects it from being blended into the mainstream of digital subcultures.

Something about Alternative Party 2008

2008-11-02T20:00:00.000Z

It has now been a week since this year's Alternative Party, so I'm using it as an excuse for writing another journal entry.

For me, the party started with a participation in the demoscene seminar, an external event held at the premises of the Finnish Academy of Fine Arts.

The seminar was not exactly a crowd-gatherer. Most of the audience consisted of fellow sceners, a considerable percentage of which also had presentations of their own. So, instead of delivering our presentations to "art people" and having a healthy little clash of cultures, we mostly ended up giving speeches to our friends.

I held my presentation with Visy (of Trilobit, Wamma, PWP etc.), with whom I happen to share quite some similar ideas and visions about demomaking as well as some common history in working on some productions.

In this 90-minute presentation, titled "Retro is a swearword" (yes, the same title as in one of my older blog entries), we mostly talked about 8-bit demomaking from the viewpoints of esthetics, technical challenges, motivation, ways of self-expression, etc. and of course we also showed quite many 8-bit demos -- both ours and others'.

The presentations were videotaped by Kari Yli-Annala, a video artist and researcher who has shown some interest in the demoscene in recent years. I'm not sure if I really want people to see the video of our presentation as I somewhat struggled with picking up the right words and expressing myself coherently, but I guess it was still a very good idea to document it. And besides, I may want to participate in a similar presentation at some later opportunity as well, so consider youselves prepared.

As for the party itself, I have somewhat mixed feelings. It seems that the organizing team tried too hard to add all kinds of fancy features to the event so that it was eventually too difficult for them to keep all the strings in their hands. This eventually lead to some major blunders in some of the most important issues, i.e. the demo competitions, voting and results. As for today, a week after the prize-giving ceremony, the final results are still "coming soon".

Also, as the partyplace was so full of different booths and special areas as well as people I wasn't personally familiar with, the whole event started to feel like a "mini-assembly" of sorts. However, I don't necessarily consider this a bad thing, as I did enjoy things like the art gallery quite a lot. Besides, in my opinion, cross-subcultural events and bold outreach efforts are something we all need, and it is always a thousand times better idea to market a demoparty to a bunch of creative people and other "freaks" than to masses of consumer whores and generic mainstream teenager nerds.

I had personally participated in two demo competition entries. One of them was "Doctor", an Atari VCS/2600 demo by Trilobit. I think this demo is really worth watching especially because of some never-seen-before effects it presents.

I personally contributed a cube effect I had actually already "finished" a year ago. One of the Trilobit guys, Ilmarque, even managed to improve the cube by fixing some rendering glitches and adding a simple checkerboard-like texture.

As far as I know, "Doctor" got the highest votecount in the "alternative demo competition", but, for some reason, the organizers had completely forgotten it during the prizegiving ceremony. The Atari STe demo by DHS (which was also technically very good) was awarded in the ceremony despite having lower points. Despite some good entries, I was also somewhat disappointed by the low level of the competition.

The PWP contribution I had been working on was a VIC-20 demo called "Future 1999". I couldn't finish it in time, but I still wanted to show the unfinished version at this very event. The content in this demo was a little bit hurried and I actually had needed to cut my original design plans to some extent, as I had only five days for creating the actual graphics and other content. The only piece of new code was the audio streamer, and all the rest was pure Brickshop32 animation played back with the routines familiar from "The Next Level".

An unfortunate fact was that the fully-linked version had too tight loading schedules for real disk drives, so it really couldn't be run with the real thing; some debugging and improvement is still needed on the linker side. For this reason, the demo had to be shown with an emulator. However, the compo machine didn't have a version of VICE containing my recent sound patch, so I had to deny the presentation altogether.

Anyway, you'll see the final version (hopefully with much more content and perhaps even some effects) at some party in the year 2009. The party calendar for the beginning of the year seems to be quite open, however, so I'll probably have quite some time for other creative activity besides that. I may even have some time for writing down some coherent thoughts in this journal, so you may look forward to that one as well.

Past tense is evil

2008-08-21T20:00:00.000+01:00

When talking about old video games and mature technology, it is quite common to use the past tense rather than the present one. People are more likely to say, for instance, that Uridium WAS a Commodore 64 game, than to state that it IS one.

In most cases, of course, this supposed mistake can be explained by the subjectiveness of the point of view. The C-64 hardware and software have obviously disappeared from the speakers' subjective world and are now something that belong entirely to their past.

Objectively speaking, however, stating that "Uridium was a Commodore 64 game" is just as wrong as saying that "George W. Bush was an American man". The statement about Dubya will not become valid until he either dies or changes his gender or nationality, and likewise, the statement about Uridium will not become valid until it is no longer possible to reconstruct the binary sequence that constitutes the Commodore 64 version of the game.

Yes, yes, but isn't this whole topic just meaningless nitpicking? How is the choice of temporal form supposed to matter so much?

Well, it is a known fact that language shapes the world, and a different choice of words promotes a different set of ideas and values. In my personal opinion, referring to a still-existing cultural artifact in the past tense promotes some quite ugly ideas, such as cultural disposability, planned obscolescence, pre-dictated consumption patterns and a general narrow-mindedness.

So, unless you deliberately want to promote these despisable and dangerous values of the dirty imperialists, you should definitely avoid referring to Uridium in the past tense.

Finding the sinners

Now that we have declared the sin, we need to find some sinners to bash and/or evangelize.

The first place where I looked into for sinful use of the past tense was, of course, the good old Wikipedia, the supposed mecca of objective and neutral knowledge.

In Wikipedia, I expected to find a lot of inconsistent use of temporal forms as well as many articles completely written in the past tense. However, I was positively surprised that it actually seems to prefer the present tense, at least for the more popular titles. For example, the Commodore 64 and Spectrum articles discuss the actual hardware platforms nearly uniformly in the present tense. There are still some problems, however, such as the VIC-20 article which uses the temporal forms inconsistently, but the overall state of the articles isn't nearly as bad as I expected.

Much more of this "past tense sin" can be found, surprisingly, on sites operated by people who actually play the old games, sometimes even with the original hardware. These people, some of which are clueless enough to refer to disk and tape images as "ROMs", often use the past tense even when referring to their favorite platforms they still use. I call these people "retro-morons".

The retro-morons

As I have already mentioned in an earlier post, "retro" is a swearword. Reading an old book does not make me a "retrobooker", or watching an old movie doesn't make me a "retrofilmer". Still, playing an old video game is supposed to make me a "retrogamer". In my opinion, the mere existence of such a category just reflects how immature the computing culture still is compared to many other forms of culture.

By using the past tense, retro-morons not only admit that they consider themselves reliving the past, but also promote the kind of thinking where objects are bound to their respective "golden ages", that is, the periods of time when they have been commercially exploited. Whenever the commercial lifeline of a product ends (after the magical finger-snap of some dirty capitalist pig), it moves from the "present tense world" into some kind of a "past tense" or "retro" world. In this strange imaginary world, the time is frozen still. No new things are possible with the "obsolete" technology anymore, no more fresh aspects can be found in anyone's creations. There's no creativity left, only endless collection, recollection and preservation.

The optimist in me hopes to see the "retro-moron" phenomenon as a temporary intermediate stage, a step towards the maturization of computing and gaming culture. In the future, I hope, old games and hardware platforms will become an integral part of our cultural heritage without being exclusively associated to certain periods of history. Just like it is possible to read a book written in the fifties without being a "fifties freak" or something, it will be possible for ordinary people to play an "eighties game" or to use an "eighties computer" without dwelling in the eighties nostalgia at all.

There's still much work to do before this stage can be reached, however. So, fire up your Interweb browser and start the holy crusade!

The development process of a new VIC-20 demo

2008-08-09T16:56:00.001+01:00

Greetings to everyone, once again! As you can see, Countercomplex wasn't destined to become a one-post wonder, despite the six-month gap between the first post and the second.

What broke this wonderful silence was my urge to tell something about my latest creation, a Commodore VIC-20 demo called "The Next Level", released at the Assembly Summer 2008 demoparty a week ago. The demo ended up second in the oldskool demo competition, the winner of which (albeit with a relatively small margin) was Byterapers' 486 PC demo called "Renaissance". There were four demos in total in the competition, and mine was actually the only one for an 8-bit platform.

I'm not hyping "The Next Level" as the best thing the VIC-20 demoscene has seen since "Robotic Liberation", as it is just one step towards something greater. There's nothing in the final product that hasn't been witnessed before -- actually, there aren't any rasters or realtime effects at all. Instead, what makes this production important was the development of a set of development tools that will hopefully shorten the creation cycle of future VIC-20 demos.

First of all, the link to the video capture on YouTube. I'm also embedding it here in order to maximize the accessibility for the ADHD internet generation:

Of course, you can also go to the Pouet.net page of the production and download the actual VIC-20 binaries. A h264.mp4 video file (16 MB) prepared by the Assembly organizers is also available for download.

The five years in between

"The Next Level" is my first actual VIC-20 trackmo after Robotic Liberation, which won the oldskool demo competition at Assembly 2003. By "trackmo" I refer to a demo that does not consist of separate memory-resident "parts" but constantly loads new material from the disk. Just like Robotic Liberation, The Next Level uses a disk drive but runs without memory expansions. That is, we have the good old 5120 bytes and 1024 nybbles of RAM available.

After finishing Robotic Liberation five years ago, I decided that I'm never going to do certain things manually anymore. A large percentage of the development time was wasted in loader-linking, that is, making sure that all the required resources get loaded in the memory just in time. Finding small slots of free RAM, splitting chunks of code and data so that they fit in these slots, possibly reordering some previously allocated areas, etc. were clearly something where automation would be much more sensible.

I also felt that I had already reached everything I could on the VIC-20 platform. On one hand, I wanted to move on to a more extreme platform where technical exploration would still be possible (like Sinclair ZX81 or Atari VCS), and on the other hand, I wanted to move on to a slightly less
restricted environment where I could concentrate on the content instead of technical details. I released some small demos for the Commodore 64, but the platform didn't really respond to my needs at the time (as it proved to be more os less just as demanding as the VIC-20).

I was also thinking about trying some "PC" stuff for a chance ("PC" referring to all the (semi-)modern 32/64-bit platforms in general). There are some appealing aspects in "PC", like the virtually endless amount of processing resources (even with dumpster-dived hardware) and the possibility to slip away from the chosen set of restrictions if the art demands it. However, "PC" requires a larger amount of initial work, and using "PC" also always feels a little bit "lame" because of the unreachability of certain hard-core values as well as the absence of the strong statement of using an 8-bit platform.

The post-technical level

A kind of enlightenment arrived to me in 2007, as I was watching some demos from some Russian Spectrum groups I had already adored for a couple of years. Groups such as Cyberpunks Unity, Inward and Skrju have, in my perspective, evolved beyond the usual "technowanking" stage often associated with the harder-core branches of the demoscene. In the new "post-technical" level, the hardware platform is no longer primarily used for bragging but for self-expression, just like in "real art".

Perhaps the two most important realizations for me were the following ones:

"Post-technical" demos don't need to push the technology: the platform doesn't need to look or sound any better than what it is. The Spectrum may look just like the Spectrum traditionally looks, there's no need to hide the color-block clashes in the visuals or the square waves in the music.

Most "post-technical" demos seem to be technically based on an animation player. Inward's "Your Song is Quiet", for example, seems to be mostly doing primitive graphics operations (like pixel-plotting and line-drawing) in a pre-defined order. Of course, the platform dictates quite a lot about the graphical style and what kind of animation is feasible.

In August 2007, I released "Impossiblator 3", a ultimate "technowanking" piece revealing some previously unused hardware tricks. After this, opening the door to the post-technical level became an important goal in my VIC-20 work.

Development tools

Although I had done some initial planning already in 2007, the actual development work of "The Next Level" and the related custom tools didn't start until Summer 2008.

The most important tool that needed to be made, naturally, was the automatic linker-builder system that would liberate me from manual loader-linking.

"Bob20" is a Python script that gets a bunch of assembly source files that are divided in "chunks" using special directives. Inter-chunk dependencies and positioning constraints can be separately defined for each chunk. The linking process is based on a special chunk type called "SC" or "StreamChunk", which are executed in a chronological order by the VIC-20-based stream interpreter routine. Bob20 attempts to find an optimal position for each chunk so that it can be loaded as early as possible. In the final loader stream produced by Bob20, the loader is synchronized with flag commands that basically say things like "wait until we have reached
frame 123".

Another important part of the demo, of course, is the animation system, consisting of a couple of "PC"-based tools written in C (namely, an SDL-based graphics editor and a rawdata-to-sourcecode converter), and of course, a VIC-20-based decompressor/player routine. The editor was named "Brickshop32" after the native VIC-20 graphics editor I had created five years ago for drawing the still graphics for Robotic Liberation.

While the original Brickshop is a combination of a character mode editor and a pixel editor, BS32 is "only a pixel editor" and thus only stores the bitmap and color data. The character allocation task is left for the post-processing tools. In addition, BS32 supports a drawing mode I've dubbed "1bpcaa" (1 bit per character, anti-aliased), which is taken advantage of in the stream format.

I already used the "1bpcaa" concept in some of my 2002-2003 work ("Impossiblator 2", "Robotic Warrior"). The basic idea is to store pictures in a 1-bit-per-character fashion and to render them context-sensitively -- that is, the shape of a "zero" depends on its upper, lower, left and right neighbor.

The BS32 converter, while converting animation frames, basically first tries to represent the frame in the "1bpcaa" format and then uses bytes and nybbles to "patch" the result. It may also ignore the 1bpcaa phase completely if it is not suitable for rendering the frame. At least a dozen
different combinations of algoritmhs are attempted on each frame, and the method producing least data is chosen.

Much of the development work went to these development tools rather than the actual creation of content and native code. But I'm sure that the percentage of the tool development is going to diminish dramatically once the tools reach a certain level of maturity.

The Next Level

I decided quite early that the basic visual style of my demo would be similar to that of Robotic Warrior: a very limited number of effects, no raster tricks at all, simple silhouette-based graphics, cartoon-like characters and a shameless use of a "traditional early 1980s video game look". This was a kind of antithesis to the boundary-pussing effect demo I
had made a year before.

The speech synthesizer and the music player are mostly derived from those in Robotic Liberation. The synth may even sound worse to some ears because I decided to only assign a single melody channel and the volume register for it (instead of the two+volume in RL). I didn't want to cut out any of the drum and bass tracks this time, but I don't know whether this was a wise
choice or not.

The process of creating the actual content was quite rapid (apart from finding the voice parameters which was as tedious as always). Most of the content was actually made during the last week, and I also finished the demo unusually early (on Monday, while the compo deadline wasn't until Thursday).

As for the concept, I didn't want to get too far from the "winning PWP style" this time, despite having a totally new set of tools. The singing speech synthesis, the audiovisual style, the story and the humor are all there. Some have even argued that "The Next Level" is actually too close to Robotic Liberation in how it looks and sounds. However, there are also some things that I hadn't tried before, such as the brief "surrealist" parts. Also, I've deliberately put in far more hidden references and alternative ways of interpretation than ever before, but I'll leave them to the audience to find out.

The most entertaining part of the development process was creating the graphics. It seems that I managed to find a graphics-making concept that works for me better than anything anything I've tried prior to this. Sketching the silhouettes with "big living pixels"; using characters for finetuning the sketches; drawing backgrounds with big color blocks, almost like legos; importing some small bitmaps from the outside world, etc. etc. Not too much pixel-level work, but still enough room for perfectionist satisfaction. Overall, quite an enjoyable experience, and I hope someone (apart from myself) likes the resulting visual style.

The future

As it would be a pity to only use the development tools for a single demo, I've already decided to use them for something more. The tools will still improve a lot, as I've been planning to support a couple of general-purpose effect routines and new compression schemes.

Despite taking a step towards the "non-technical", I still have some technical ideas I'd like to try out. Audio streaming is one of them. I don't want to reveal much about it yet, I just mention that it is probably going to replace the five-year-old speech synthesis routine altogether.

I also need some actual audio tools because I don't want to hard-code all the sound in assembly language anymore. A flexible audio tool would also provide a much more satisfying means for musical experimentation, and that's something I think my musical output really needs at this time.

I have been planning to release a totally different VIC-20 demo on the next Alternative Party held in October, so look forward for it.

There are still so many things that haven't been tried out yet.

Welcome to Countercomplex!

2008-02-10T17:00:00.000Z

Ladies and gentlemen.

We are living in a pre-apocalyptic world.

It is already quite obvious that a massive global disaster is going to occur sooner or later. We cannot prevent it anymore; the most we can do is prepare for it and try to reduce its effects.

In the meantime, the average human way of life is becoming increasingly "virtual": computing-oriented, detached from real-world surroundings, dependent on the global infrastructures of communication and production.

I like to envision the upcoming apocalypse as the ultimate clash of realities -- that is, the clash of the various virtual realities against the real thing.

This journal is not about doomsday preaching, however. It is about bitwise creations.

Bitwise creations in a pre-apocalyptic world.

And what does that mean?

I was going to use the term "computer art" or some variant thereof, but noticed that the connotations would be misleading, so I picked "bitwise creations" instead.

My idea of computational creativity is rooted in the older subcultures of microcomputer hacking, where every single bit is important, and a good artist is able to choose every single bit wisely. Experimentation is also an important keyword. My primary reference group is the demoscene, where much of this idea is still alive.

This idea forms a viewpoint that is quite different from what you would expect when you hear the words "computer art" in a random context.

My position

I've always hated consumerism, bloat, wastefulness, planned obsolescence and "keeping up with the latest". The rebellion against these ideas in the context of hobbyist computing has brought me into a position that largely deviates from the "mainstream ways". I very seldom buy any electronics as new. Most of my computing hardware comes from other people's trash, and a great portion of my demoscene creations is targeted for old and "limited" platforms.

"Retro" is still a swearword, however. Living in the past does not help in building a better future.

Those unfamiliar with my activity may want to look at these Youtube videos of some of the demoscene productions I've been involved with:

Robotic Liberation (VIC-20, 2003)
Robotic Warrior (VIC-20, 2003)
Progress Without Progress (C-64, 2006)
Isi (PC 8088, 1997)

My upcoming rants

As I regard Countercomplex as the direct successor of my previous blog, "Viznut's Amazing Discoveries", quite many of the same topics will remain relevant:

I'll be writing about my own creations, creative processes and sources of inspiration. These topics may vary from dreams to algorithms, from video games to junk art, from philosophical theories to first-hand experience.
I'll also be writing about the demoscene and other "scenes" surrounding or overlapping my creative activity.
And of course, I'll be building crazy bridges between seemingly unrelated ideas and disciplines.

What differs from the first cycle is that the point of view is now more well-defined and consistent, hopefully allowing me to go somewhat deeper in the analysis.

You can also expect me to criticize all kinds of "enemy ideologies" every now and then -- whenever it is relevant to the scope of the journal, of course.

I'm going to aim at the eventual posting rate of once or twice per week.

Hope you like it.