Additionally, I present series of generative audiovisual artworks making use of this technique.
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.
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.
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.
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.outThis 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.
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.
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.
While a series is minting, I may adjust minting price manually based on demand. I will communicate this per series.