Lars Wander and Mixing Paint With Code

Lars Wander is a computer artist and programmer, who creates all his art exclusively with code.

His process starts with a lot of thinking and contemplating around a single “idea” in the form of a program, then he will use that program to explore and play with that idea from various angles.

*excerpt from the ‘how you see me’ series*

When Lars was young, his father taught him a valuable lesson; "A computer always does exactly what you tell it to do." As someone who spends most of their time working with computers, this advice would provide a sense of comfort to him, as computers often do fascinating things. Any frustration with technology can be attributed to a communication error or misunderstanding.

Despite this, there are moments when the computer's actions still surprise Lars, almost as if by magic. As an artist, his goal is to capture those moments of unexpected beauty through algorithmic art. It’s truly a wonder how Wander is so versatile as an artist; one series will be focused on a plottable experience and another will introduce a relatively new idea such as creating abstract-like paintings.

One thing Lars says most of his projects all have in common is that a lot of time is spent thinking & doodling about systems that would be interesting to implement in software.

To gain insight into Lars' approach to computer art, we talked with him to learn more about his creative processes, the various tools he employs to create such fascinating artwork, the importance of ‘centering and scaling’, and what else contributes to the distinctive quality of his work.

Can you explain your process and the tools you’re using?

What’s common to my process in each project I’ve done so far is that it begins with a lot of time spent thinking & doodling about systems that would be interesting to implement in software. Usually, after a few weeks of thinking, I spend a few days writing code with little visual feedback until the core system is implemented.

During that process, I almost always encounter a series of questions that I don’t know the answer to (e.g. what should the average paint blob size be?, or how many light rays should be collected per pixel when tracing the scene?) which I encode as parameters to be fiddled with later.

*Samples from Bright Moments Tokyo Collection 2023*

Once the code is ready, I then spend weeks or months playing with the parameters I’ve exposed and making more code changes as I guide the system towards what I think will be both visually beautiful while still representing the core idea that inspired me in the first place with as few frills or distractions as possible.
Given that generative art really brings “process” to the foreground, it’s very important to me that my works are as conceptually simple and beautiful as they are visually appealing, so I try my hardest not to hide the core idea of a piece in visual decoration.
My process is always very centered around implementing a single “idea” in the form of a program, and then I use that program to explore and play with that idea from various angles. I find that once an idea is implemented as code, it’s possible to push and explore that idea in ways that can’t be done simply on paper.

However, more often than not, I find that once an idea is translated into code it actually isn’t quite as exciting as I hoped – I have a large graveyard of projects that simply didn’t capture the magic I was hoping for.

Do these systems/processes change with each project you create or do you stick to certain ones/rules?

When it comes to how my code is structured, I try to maintain “good” engineering practices for libraries and functionality that I share between projects – the idea is that these bits of code will stick around for a long time, and I want them to remain reliable and understandable above anything else.
The rest of the code and the code that’s unique to each project is usually far messier and more experimental. I find that if I allow myself to be messy and chase the behavior of the system I find it exciting knowing that the code I write isn’t meant to be reused, then the end result is almost always far better than if I tried to write “clean” code throughout.

What are your go-to tools when creating or does it vary per project?

I always try to use tools that are as simple as possible, and (when possible) are built by myself. I find that the tools we use have such a huge impact on the way we think about our process and in turn the actual works we produce, that I find it very important to produce and maintain my own tools. I also happen to really enjoy building tools, especially tools where I’m the only user (haha).
More concretely, all my recent work was generated with vanilla Javascript and WebGL2. For simplicity’s sake, I serve unbundled Javascript using a local HTTP server and symlink in some libraries that I share and develop upon, between projects. I do all my development on Linux as well, as I find it’s the most programmer-friendly environment to work in.

When it comes to my plotter projects, I started off doing everything in Python but eventually became frustrated with the performance. For the sake of speed, while keeping development easy, I switched to Julia, a high-performance language with nice ergonomics developed at MIT for scientific computing.

What is your background as a programmer?

I studied Computer Science at Carnegie Mellon and then worked as a Software Engineer at Google for 7.5 years across a range of teams spanning cloud deployments, AI-based speech-to-text transcription, storage systems, and visualization.

At what point did you transition to creating computer art - or has it always been something you’ve been creating on the side?

It wasn’t until I started work on visualization in 2020 that I realized the creative potential of code-based art. Seeing the visualizations created by my manager at the time, Wim De Pauw, was a huge part of that realization.
He captured the intrinsic behavior of these large, complicated, almost organic-seeming systems but the results were still beautiful to look at (and something I would gladly hang on my walls given the chance).

On your website, you write about the function, ‘Centering and Scaling’ saying, “It’s probably your most used piece of code when it comes to making generative art”.

Can you explain why this is so important to you and your process?

It’s important and fundamental but in a (probably) boring way: it’s simply a way to ensure that all of the elements that you want visible in your final composition are placed correctly on your canvas. It’s not something we would need to think about mathematically if we were drawing by hand, but generative artworks are rendered using rules and code, and as a result, we need rules and code to govern how and where the final composition is placed onto your screen.
There are several approaches to doing this, but the one I wrote about in that article is probably the most flexible and easiest to integrate into your process once you are aware of how it works.
I shared this idea and associated code because it’s something I see a lot of new artists struggle with, and is something I struggled with myself when first starting too.
I know all of the more established artists are doing this in some form or another, but I never see it get talked about or written about.

How significant is open-sourcing your codebase to you as a computer programmer?

That’s a great question and something that I’ve wrestled with quite a bit. My first inclination was to open-source everything as it felt right to share and foster community collaboration around the practice.
However, I realized that, unlike other forms of art, it’s possible to completely recreate another artist’s work, pixel-for-pixel, by knowing their process. Once I saw how common “copy-minting” was on fxhash (the act of copying and selling another’s code either through impersonation or deception), I knew that sharing all of my codebase would only result in people getting scammed.
Still, sharing what I learn for others to grow is important to me, so I try to share techniques like my “Centering and Scaling”, or my pigment mixing Kubelka Munk code (with proprietary data removed) for others to benefit from.

Could you describe the earliest piece of computer-generated art that had a significant emotional impact on you?

The first time I remember being seriously moved was when I found the artwork of Jonathan McCabe.

At this time I had just barely begun making my own computer artwork, but thanks to my programming background I generally had a pretty good sense of how most computer artworks I’d seen so far were created.
However, seeing McCabe’s work really opened my eyes to the depth of this field – it was like getting a peek decades into the future of computer artwork. His process and tools are still an absolute mystery to me, and the results are beautiful and mesmerizing.
What really moves me is the sense of exploration and curiosity I feel when looking at his works: they play with basic principles found in biology but push these concepts in a direction that’s completely alien yet stunningly beautiful. I hope to create such wonderful works myself someday.

What was your introduction to the plotter?

I was introduced to the plotter through a video on Reddit, which had a link to the AxiDraw webpage. Once I learned that it could be controlled by sending X/Y coordinates and up/down commands, I knew I had to have one to play with.
This was towards the start of the shelter-in-place period of the Covid-19 pandemic, and it turned out to be a great source of entertainment.
I made hundreds of pieces during this time and only shared a small fraction of them on my Instagram. I was later really fortunate to have Verse exhibit some of the other pieces in my first solo show, “Perry, Mary, and Lars”.

*Perry, Mary, and Lars exhibit at verse*

What was it like when you got your first plotter?

When I ordered the plotter I was incredibly excited for it to arrive, so rather than obsessively refresh the FedEx tracking page I spent my time writing a little Python library to generate plots, visualize them, and send them to the plotter using the AxiDraw’s interactive API.

What was the first thing you created?

To test the library, I wrote a little 3-body simulation, and then connected pairs of the bodies with lines, tracing out their trajectories over time.
When the plotter finally arrived, to my amazement, I was able to plug it in and get it plotting almost immediately, rendering one of these 3-body simulations:

This feedback loop of writing code, seeing it visualized on my screen, and then made physical with the plotter was immensely satisfying, and ultimately was what got me hooked.

Can you describe the various methods you've employed to create art with the plotter? Additionally, have you explored different materials, such as paint, markers, or watercolors, in your experimentation?

*Overlapping lines are filtered, removing any lines that are obscured by higher ribbons*

One of the most enjoyable parts of plotting for me was exploring all the different options for materials and processes. I started off with printer paper and a fountain pen that I had already collected, but quickly started running to the local art supply store on almost a weekly basis looking for more supplies and ways to take advantage of the plotter.
Early on I decided that I didn’t want to use the plotter to try and replicate the human hand, as it seemed like it was missing the point of the practice (if you want to replicate human drawing, why not just draw yourself?). So through the various materials and methods I tried, I was always cognizant of exposing some element of the machine that was involved in creating the piece.

For my own practice, I found this most interesting when using watercolor and graphite. Both of these materials impart a beautiful texture but can be very fickle and hard to control. This juxtaposition between the inhuman precision of the pen-plotter and the inherent difficulty of using these materials is one of the things that really appeals to me.

As an artist who primarily works with plotter machines, do you face difficulties when using tools that are native to digital platforms?

Live plotting of ‘Ribbons: Two Sheets in Blue’ [2022]

The transition from producing plotted works to purely digital ones is a very difficult one. Taking a piece intended for the plotter from its digital representation to its plotted, physical representation is really wonderful in how much it adds depth and beauty to a piece. The subtle physical imperfections that are inevitable in this translation add so much to a work that it really forces you to rethink your approach when creating digital-only works.
That said, I strongly believe that creating digital-only works which try to mimic physical imperfections is unimaginative, and is missing the point of the digital-only medium. After all, is something really “imperfect” when you’ve created it by describing it precisely in code? Telling a machine exactly how to reproduce an “imperfection” seems to go counter to the idea.
Instead, I try to find ways to explore a “digital” aesthetic when making works intended for digital platforms, like the flat colors of “how you see me”, or the noise visible in the sampling-based convergence of color in “Light Doesn’t Bend That Way”.

What was your ultimate goal when creating ‘Light Doesn't Bend That Way’?

*Light Doesn’t Bend That Way #1, #2, #6*

That’s an interesting question, I guess if I had to assign an “ultimate goal” it would be to explore the otherworldly. A sense of curiosity and desire to explore is what drives most of my work, and given my background, writing programs is the most natural way for me to do so. I strongly feel that sharing explorations like these needs to be grounded in reality somehow to be interesting and for them to connect with an audience.
It becomes an interesting question to decide where that connection to reality should be made. For “Light Doesn’t Bend That Way”, I chose to implement that connection at the level of human perception of light, by writing a ray tracer that converts Spectral Power Distributions to RGB colors.

What’s interesting to me, is that this conversion is carried out using data that is empirically collected by experimenting on human sensitivity to various frequencies of visible light. With that empirical data, it is possible to mathematically describe a relationship between wavelengths and the subjective experience of color.
This concept is almost magical to me, as it represents a bridge between a purely subjective experience and a mathematical framework. Using visual perception as the connection to reality, the series explores different ways of casting light through a scene with altered equations governing the path of the light as it disperses and refracts through the environment.
The results are images that are rendered with light and perceived as though they exist in our world but ultimately are impossible to recreate without this creative use of computation.

Your first long-form generative art project was Gossamer.

Can you go into a bit of detail about this project and how it was conceived?

Gossamer was based on a technique that I had developed while plotting and was one of my first attempts to make generative artwork that wasn’t rendered with a plotter. Its heavy use of overlapping lines to create texture was clearly born from my plotter practice, but the resulting images would be nearly impossible to recreate with a pen plotter due to the line density.

Creating Gossamer was an important departure from plotter artwork for me, and an important learning experience in how to create long-form generative art. While it was the first long-form project that I published, I was already working on “Lines Walking” before discovering fxhash after approaching plottables.io for an opportunity to publish on their platform.
I took a lot of what I learned from my early fxhash projects to refine and prepare for this plottables release.

Do you believe that generative art should be static in its resolution or have the capability to be responsive?

That’s a good question, but I’ll give you a lame answer: it depends. I think when an artwork can be rendered in a resolution-independent way, it absolutely should. There are really three categories here: artworks with a fixed resolution, artworks with a fixed aspect ratio but variable size, and finally artworks with a flexible aspect ratio.
The first category is sometimes the only one possible given the tools you are working with. For example, most machine-learning approaches require a fixed resolution, as the models generating the artwork are almost always resolution-dependent.
The second and third categories are almost always possible for the kinds of generative works we see today, but sometimes require careful programming to pull off. Making this simpler is the crux of my “Centering and Scaling” article you referenced above.
I think when making artworks that can render at multiple aspect ratios, it’s interesting to have the artwork respond to the aspect ratio it is being rendered at.

I do this in Geode, where if you render in the live view with the “&flex=1” URL parameter, the Geode will fill the shape of the window rather than the typical square:

What were your process and systems used when creating “how you see me”?

What made “how you see me” different was that far more time was spent in the initial ideation phase while I researched how digital color works. I think this really paid off as the colors in the series really stand out to me, and the research and understanding was what made “Light Doesn’t Bend That Way” possible several months later.
What’s always changing between projects are the underlying tools that I build for myself. They are constantly evolving as I better understand how I work best, and growing as I discover new techniques and methods.

Do you intend for all of your artwork to exist in a physical form or do you create some pieces that are meant to solely exist in a digital format?

As much as possible I’d like for all of my works to have a physical component – even if that physical component is just a digital screen showing the work. It’s sad to me if a work only exists in someones on-chain wallet and is never displayed anywhere.

*‘Evolving Pixels’ exhibit with @proof_xyz & @V_over_M - Photo by* *@HaiverArt*

At the same time, I don’t want to shy away from projects that can really only exist in the digital realm.
The discourse about the relationship between the physical and the digital is really interesting to me, and I want to find interesting ways to engage in that which may require making works which simply cannot have a physical representation.

What is your opinion on how digital art is currently being displayed?

While I believe that digital art should be resolution-independent wherever possible, I don’t believe that it should be entirely scale-independent. As a result, it’s frustrating when pieces are mostly seen and shown as thumbnails in a grid among many other pieces on some online marketplace.

I guess this is inevitable, but I would encourage folks to look at my pieces full-screen when possible. When it comes to displaying works on a screen, I also prefer that where possible, the code itself is run live to generate the piece.
There is something kind of special to me about the idea that code is running as a part of the performance of the piece.

Where do you see yourself in 10 years?

I’m glad you’re asking so that I can look back in 10 years! For myself, I know I’ll still be making art, but I can really only hope that I’m still able to make a living doing so.
Most likely I’ll keep playing with new tools and techniques, and will likely produce works across a range of mediums and styles. I have no clue what it will look like (or if it will even be visual), but I know I’ll be having fun making it!

How do you think generative art will evolve over the next 10 years?

As far as generative art at large goes, I imagine that there will be more and more crossover with physical media as artists continue to explore and push boundaries beyond the screen.
Companies like Artmatr are really interesting in this regard as they are helping bridge the digital-to-physical gap in all sorts of interesting ways with custom robotics.

For inquiries, please contact hello@artxcode.io.

Lars Wander is a computer artist and programmer, who creates all his art exclusively with code.

Ix Shells and the Future of Sound and Generative Art

Marcel Schwittlick and The Long Run