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.
FAQ
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?
A detailed guide in progress. 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.
A more detailed guide will follow. 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.
Acknowledgements
A list of projects related to generative art and/or on-chain storage.
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.