Recently, this video of IBNIZ in action made its way around the electronic music blogosphere. IBNIZ is an extremely enigmatic art platform. It’s not necessarily easy, or pretty, or even broadly useful. IBNIZ is uniquely targeted at a small coterie of artists with specific aesthetic goals. I had the opportunity to ask Viznut, the creator of IBNIZ, about the language, and his views were so intriguing that I am publishing them unedited here.
Evan Merz: In your blog post, you say that IBNIZ is an old-school platform. How was it inspired by older technology? How do you feel that IBNIZ relates to old-school +software or old-school art practices?
Viznut: I don’t actually call it an oldschool platform — those words tend to have strict historical connotations to a lot of people — but a platform that has the kind of simplicity, concreteness and freedom that can also be found in old computers and makes them fun to hack with. You use a small instruction set to manipulate numerical values that consist of tangible bits. Nothing is arbitrary, undefined or illegal: every bit has a purpose, every combination of instructions has a specific, potentially useful outcome. These platform-level properties are what shaped a lot of the oldschool home computer culture, including the core artistic practices of the demoscene.
While IBNIZ shares these properties with actual “oldschool platforms”, however, it uses totally different design choices for achieving them. As IBNIZ also tries to break new ground by having code compactness as a leading design goal, I would rather call it “experimental” than “oldschool”.
The main artistic practice IBNIZ has been designed to serve is the “sub-256-byte” demo art that aims at producing increasingly impressive visual or even audiovisual programs under very tight program size limitations. The kind of attitude that gave birth to this practice has been a very prominent part of computer hacker subcultures since the very beginning — consider the display hacks of the 1950s and 1960s, for example — so I guess it could very well be called “oldschool”. However, I would avoid binding it to any specific time period, as it is always possible to approach any computing system in this way. The issue here is just that modern mainstream platforms that hide their bits and bytes under numerous abstraction layers do not encourage the kind of “bit-bending challenges” that IBNIZ or classic computers do.
When talking about the kind of computer art that is prominent on old platforms and small program/data sizes, I prefer to use the term “Computationally Minimal Art” as it eliminates the need for a timeline. IBNIZ concentrates on the program-size aspect of CMA while being considerably less minimal on the machine spec department, allowing a decent number of pixels, millions of simultaneous colors and a lot of processing
power.
EM: Do you think that growing up with personal computers in the 80s and the 90s has made you a different artist than you would be if you were born in 2000? Specifically, do the old methods give you a different perspective on computer art? Do you think that younger artists would benefit by exploring older methods and environments?
V: I believe that being influenced by eight-bit computers at a formative age has made be assign some kind of archetypal roles to bits, pixel patterns and
synthesized waveforms. These are the primitives that define computer art for me at the most fundamental level. If I had been born twenty years later, I would perhaps have ended up embracing polygons instead of pixels and formal lines of code instead of concrete bits and bytes.
Of course, it might also have been possible that if the computers of my childhood had been too complex and unpredictable, I might not have become interested in them at all, at least on a very deep level. The computer would have remained as a mere tool for me instead of material, a platform for fixed applications instead of a platform for code-level experimentation. This is what concerns me a lot at times. Many of the kind of minds that became computer virtuosos in the eighties would find themselves completely lost if they were introduced to computers today. This is why I find it important to create and advocate the kind of virtual toys and cultural forms that make the “oldschool path” more accessible and interesting.
How much a computer artist can benefit from experimenting with the kind of “bit-twiddling” typical to oldschool platforms depends a lot on his on her psychological characteristics, I guess. I would say that at least those people who show any symptoms of “hacker mentality”, including a kind of desire to completely understand and control a limited set of building blocks and to explore their potentials, should definitely try it out.
I have noticed that many of the younger demoscene artists have an interest in platforms that had already fallen out of fashion by the time they were born. I think this is very understandable: if you are able to grasp the fundamentals of a code-based artform that embraces technical excellence and experimentation, you also have the potential to appreciate any computing platform as artistic material by its unique inherent restrictions and characteristics, regardless of its age, cultural context or whether it is considered “oldschool” or “newschool”.
EM: You have a very interesting code aesthetic. Is IBNIZ designed, in part, to show how code can be beautiful? Do you think that beautiful code can be appreciated along with a beautiful work of art? Does showing the code change the perception of the art?
V: IBNIZ has been mainly designed to produce maximal results from a minimal number of characters. So, the only principle for what the code is supposed to look like is “small is beautiful”. When desigining the language with this principle in mind, however, I thought it might help a lot if I aimed at some level of implicit elegance. In order to attain this elegance, I’ve taken a lot of influence from FORTH which I regard as a particularly beautiful programming language as it combines a Lisp-like purity and simplicity with an Assembly-like concreteness and straightforwardness.
I’m not sure how showing the code could change the perception of an artwork, but as a demoscener I know that by knowing the size of the program and something about the platform it is written for, it is possible to appreciate the code even without actually seeing it. If a 64-byte-long program produces a 3D-rotating, phong-shaded torus, any demoscener will be ready to praise the quality, beauty and impressivity of the code just by knowing that such an achievement must necessarily involve very well-thought-out code and math. So, in extreme size-coding, it all boils down to code length: the most beautiful code for any given task is the shortest possible code for the task, period. However, I do believe that even when sticking to pure size-optimization, the process produces a kind of emergent beauty a lot like how simplified mathematical formulas tend to give more pleasing impressions than their non-simplified forms.
When trying to show off the inherent beauty of IBNIZ code, I don’t think the current “line-noise format” with one ASCII character per instruction serves this purpose very well. The beauty could perhaps be much better grasped by, for instance, a visualization of the abstract stack flow.
EM: What artists inspired you to build IBNIZ? Did any particular artist, whether part of the demoscene or not, spur this project? Are there any coders who inspired you?
V: The path that eventually lead to IBNIZ originally started from a technical idea inspired by the continuing progress of 4-kilobyte demoscene productions: once the maximum code density of X86 machine code has been reached in a 4-kilobyte demo, would it still possible to increase the code density even further by putting in a custom bytecode interpreter? This lead into a lot of experimentation with different virtual machine concepts that would allow for a maximum code density with a minimum overhead for simple effects. I don’t really know about any specific artists who had worked on anything similar but I would say that the general attitude and mindset that the demoscene culture in general had cultivated in me has influenced many of the design choices.
The IBNIZ project had been dormant for a couple of years before I finally finished the design and implementation. A major motivator for the revival was a 23-byte Commodore 64 demo, “Wallflower” by 4mat of Ate Bit, that was groundbreaking by producing several minutes of interesting structured glitches from a couple of simple bitshift operations. This inspired me to revive the project and to do some musical experiments with very short C programs. As this unexpectedly grew into a collective movement called “bytebeat” which also gave birth to several different interactive experimentation tools, I really had to finish IBNIZ. How IBNIZ eventually came out was somewhat affected by the bytebeat movement, especially the Flash-based on-line experimentation tool by Paul Hayes — I wouldn’t have emphasized the interactive editor so much without this contribution.
EM: For people who want to use IBNIZ, what tricks can you share? What little snippets of code are particularly effective or useful?
V: This would require a very long answer, as the relevant tricks depend quite a lot on whether the user is working on video or audio, the level of determinism involved and what kind of results are aimed at. I am working on a “full-scale” IBNIZ reference guide that describes every opcode with their intended purposes and also gives examples and useful “nonintended uses” for each of them.
Many people who experiment with IBNIZ just try out different combinations of opcodes without actually knowing what they are doing. For those who prefer this method, I would recommend combining basic arithmetic and stack manipulation with the stack-pick opcode ‘)’ that often produces interesting feedback effects. However, I think even random experienters can benefit from obtaining some level of understanding on how the VM actually works.
For those who want to experiment with audio, I would recommend looking into the material available on the “bytebeat” formulas, including a couple of blog posts and a technical paper by me. When translating these formulas into the RPN syntax used by IBNIZ, remember that ‘w’ yields the value of the ‘t’ variable in the audio context. IBNIZ also has a different sample rate and number format so the formulas will often need adjustments to their constants.
EM: Could you share your favorite program that you’ve written so far with IBNIZ?
V: We are still at a rather early stage in IBNIZ culture, and I’m sure that a lot of new “favorite programs” will pop up once the regular IBNIZ demo competitions start taking place. Right now, the most advanced programs available for IBNIZ are fractal renderers. Here’s a Mandelbrot zoomer by myself — very slow in the current public version of IBNIZ but a lot faster in the upcoming JIT-enabled version:
vArs1ldv*vv*0!1-1!0dFX4X1)Lv*vv*-vv2**0@+x1@+4X1)Lv*vv*+4x->?Lpp0:ppRpRE.5*;
There’s also the random-program approach. Sometimes just a couple of characters are enough for an interesting result. I have tested all the possible programs from zero to three characters in length in order to find some nice ones, and my favorite among them is probably d)r that produces a long and varying sequence of audiovisual gltiches.
EM: What are you plans for IBNIZ? Are you working on a new version? What
changes +are in the pipeline? Do you plan on compromising on some aspects of
it, or will +it stay hardcore and old-school?
V: IBNIZ is still in a somewhat moving state and that’s why a new version comes up from time to time. Right now I am concentrating on a JIT compiler in order to give the VM implementation a much needed performance boost. The abstract VM will not undergo any major changes, however. A couple of new opcodes will probably be added, but otherwise it is already pretty much fixed. Once we reach version 2.0, there will be no further changes to the VM definition.
A near-future plan is to start regular IBNIZ demo competitions in order to advocate the platform and to inspire the discovery of new tricks and techniques. I think IBNIZ has also potential as a livecoding platform, and this series of competitions will support the development of livecoding skills as well.
EM: Is there anything else people should know about IBNIZ or demo art in general? Where can we go to see more demo art by you or other people?
V: The demoscene is a multi-faceted subculture, so there is a lot of different demo art, from very technical to very non-technical and from very constrained to very non-constrained. The size classes of 256 bytes or less are among the most technical, constrained and hardcore genres of demo art, another example being the demos running on very old and limited platforms. I have created most of my most acclaimed work for the unexpanded VIC-20 but have recently started to expand my sphere of technical creativity into highly constrained “non-8-bit” works as well.
Currently, the leading community website and production database for the demoscene is Pouet.net, that allows for searching pieces of demo art by size class and platform. Although demos are executable programs by definition, many of them can also be watched as video captures that are available on Youtube and other video websites. My own work is released under the group label “PWP” and you can find it by doing a Pouet.net search for “pwp” or a Youtube search for “viznut” or “pwp”.
