Articles, Interviews, Podcasts

By Kevin Buist, published in Outland.art August 22, 2023
Running Out the Clock
Conversation with Tyler Hobbs, moderated by Elisabeth Sweet and Alex Estorick July 2023
When Tyler Hobbs met 0xDEAFBEEF
Interview with curator Lady Cactoid for LACMA's blockchain initiative May 2023
Remembrance of Things Future: A Conversation with 0xDEAFBEEF, Artist Experimenting on the Blockchain
In conversation with artist LIA, Outland.art Nov 2021
Interview with curator and JPG co-founder Sam Spike Jul 15, 2021
Fundamental Knowledge: An Interview with 0xDEAFBEEF
Digitally Rare podcast with Jonathan Mann and Matt Condon Jun 14, 2021
Thinking Outside the Glitchbox: 0xDEAFBEEF's On-Chain Generative Art


Here I describe the motivation, my opinions on art and technologies, personal ramblings and answer FAQs. Hit me up with questions or criticisms, this is a working document.


Motivated by the importance of maximum permanence for NFT art, I propose a new method for efficient on chain storage of media files expressable as the output of a model and parameters. Typical NFTs store media on IPFS with only a reference hash stored on the blockchain. Existing methods store model code and parameters onchain to be rendered in a browser, or with an external library. This introduces a dependency on browser technology(which is fast changing), and in some cases external libraries. I propose instead to store self contained code written in C language that directly outputs raw numerical data encodable to sound and visual media. As the Ethereum is already dependent on C compilers, writing model code in C does not introduce a new dependency, increasing the confidence the media will be well preserved for the life of the Ethereum network.

Additionally, I present series of generative audiovisual artworks making use of this technique.

Personal History

DEAFBEEF began an as art project in 2020 at the start of the COVID 19 pandemic. I emerged after 7 years living under a rock while my kids were young, to discover that modular synthesizers had come back into style. Having a background in electrical engineering, sound recording and music, I was excited the culture of synths had re-emerged. However, there was a certain amount of consumerism in the new culture, and I decided to take an alternative ascetic approach of using 'nothing' to make music, rather than sink time and money into expensive hardware that many seemed to view as magical "black boxes". Nor did I want to upgrade my 10 year old laptop to be able to run the latest DAWs. I opted instead to rebuild from scratch, using only a cheap laptop running Linux, emacs text editor and a C compiler. The intent is to work at a fundamental level, scrawling numbers directly into digital storage media later to be interpreted as sound and images.

As a developer, my favorite way to work is in the terminal, mouse free, using Emacs and command line tools. The muscle memory to me is akin to playing an instrument. I also love the aesthetic of ANSI terminals. I grew up in the 90s playing Nethack, which introduced me to programming and procedural generation. It was a formative experience. I write C programs that generate audio and visual outputs. As it turns out, this approach lends itself well to NFT blockchain technology, at least in the case of generative art.

On Chain storage of NFT media

Blockchain storage cost is expensive. Media files cannot efficiently be stored directly on chain. Many NFT's store the media file on IPFS, and store the hash of that file on-chain. Given a media file, this hash allows one to prove its authenticity. However, in the event the media file was lost, it cannot be reconstructed from the hash. Systems like IPFS make it unlikely the file would be lost, however, some NFT collectors place a very high value on permanance, and there may be cases where over designing for permanance is warranted.

Generative art is one such special case. Being art, permanance is highly valued. Being generative, the media files are outputs of model (computer program). The model(program) takes parameters as inputs, and outputs digital representations of sound, images or animation. If the model is deterministic, then the model and parameters alone are enough to perfectly reconstruct the output. Hence, one has only to store them on-chain to assure permanence of the output, without resorting to any other external storage mechanism.

Platform Dependance

There is one remaining assumption: that the code will always run. How likely is it that the model code can be interpreted and used, far into the future? Without knowing the future, one can still take measures to reduce that risk. In theory, what should be stored is an exact description of a mathematical model, one that could be interpreted (and computed manully, if required) to produce a list of numbers that can be digitized to reconstruct the media. In practice, this boils down to the expectation for the model to be self-contained, with no reliance on external libraries, interfaces or data files, except for those functions that are commonly understood and exactly defined in closed form such as sin() function. Ideally, a computer language and platform is chosen that is stable and is not expected to change.

With these requirements in mind, the language I choose is C language, conforming to the ISO c99 standard. C compilers exist for every platform. Higher level languages(Go, C++,Javascript) are dependent on C compilers. In fact, the Ethereum network itself is dependent on C compilers to build the programs that run Ethereum nodes. Hence we can be quite confident the C model code will be usable for the life of the Ethereum network. In my opinion, the same cannot yet be said for some on-chain code that depends on particular browser technology, especially in regards to multimedia.

These measures may seem extreme. Admittedly, IPFS is probably sufficient for most use cases. For art, when permanence is highly valued, such measures may be warranted.

In summary, if you value permanance of a multimedia file, then save the code/parameters that produced it on the blockchain, write it in a conservative way that is close to idealized mathematical model, and take best measures to ensure that code will still run in the future.


Where are the media files hosted?

For convenience they are cached on our server, but they can be reconstructed on your own, see next question. If Opensea and our server were to blow up, you can still fully reconstruct your media files with the data stored in the Ethereum blockchain.

How to I reconstruct media files from my NFT?

Click here for a more detailed guide.

In summary, use a web3 client or etherscan.io to read the Ethereum blockchain. Obtain the C code, editing the 'seed' value to correspond with the random hash unique to your NFT. Compile and run the program

# gcc main.c -m && ./a.out
This will generate a WAV file and/or animation frames in BMP format. Encode these using 'ffmpeg' to package to desired quality as MP4,MP3 etc. These instructions are also included in the C code header.

Questions welcome.

How can I get started making generative music?

Forthcoming. For now checkout well supported languages designed for music including Supercollider, TidalCycles, Csound, PureData.

Do you plan to release multiple series? How many?

Yes, my intent is to post select ongoing audiovisual work as "series". Synth poems is the first series, but there will be others. The style of my work can be seen on Instagram.

Some series, like Synth Poems, are designed to have enough distinct variation in the outcomes that they warrant multiple mints. Other series may have a much lower number, like 1-5, because the system is intentionally constrained to deliver a fairly specific result, or sometimes one specific result. All works would have the code that produces them completely on chain.

My personal thoughts on mint numbers: within this generative art paradigm, the number of mints should only be as many as is required to display the "range" of the generative system. The decision should be an artistic one. I intend to be both selective in the works I make available, and conservative in the number of mints.

Moving Forward: A General Model for On-chain Storage

Assuming the importance of on-chain storage, a good way to achieve compact representation for NFT media in a general sense would be to agree on standarized, self-contained shared code libraries for a particular application(music, animation, digital art) and store them once on the blockchain, available to be referenced from other NFTs, who in turn would need only store parameters or some compact DSL(domain specific language). This is analagous to SVG or MIDI. More generally, it is a form of data compression. Rendering would be done offline, and then cached.

Note that stored media also need not be 'generative'. In the generative art case, a random hash is chosen as a parameter, but parameters can also be any information: chosen by the user, a sequence of musical pitches, time/position curves for an animation, etc. The parameters together with a deterministic model completely describe a particular output.


A list of projects related to generative art and/or on-chain storage.

Pricing and Minting Quantity

I organize my artwork into multiple series. The maximum number of mints per series can change while a series is unlocked. Once locked, the upper limit is frozen and cannot be changed. Locked series cannot be unlocked. A series that is locked will be indicated.

While a series is minting, I may adjust minting price manually based on demand. I will communicate this per series.