generateMelodicSeed = slow 4
$ linger 0.5
$ repeatCycles 3
-- $ palindrome \n
$ (+ (slow (irand (4)+1) (sometimes (inversion) (run (irand (4)+1)))))
$ slow ((irand 3) + 1)
$ e ("x"<~>(irand 8)) 8
$ "x*16"<~>(irand 5)
hush
d2
$ note
((scaleP scalePattern
$ (rotR 3.5)
-- $ inversion \n
$ (+ slow 8 "x" <~> ((0.5 ~>) generateMelodicSeed))
-- $ slow 2 \n
$ generateMelodicSeed
) - 12)#s "[pe-gtr:9,midi]" #gain 1.2 #orbit 1 #midichan 2
generateMelodicSeed = slow 4
$ linger 0.5
$ repeatCycles 3
-- $ palindrome \n
$ (+ (slow (irand (4)+1) (sometimes (inversion) (run (irand (4)+1)))))
$ slow ((irand 3) + 1)
$ e ("x"<~>(irand 8)) 8
$ "x*16"<~>(irand 5)
Sustainable Computing
Given how the supply chain for computers is creating massive ecological harm, is there any way to create a more sustainable way of computing.
The most sustainable computer is the one you already own. Therefore, sustainable computing must include software specifically designed to be performant on a wide variety of older hardware.
portability
Software written against particular hardware is difficult to make portable. The abstraction offered by a virtual machine can insulate software logic from the specifics of a given piece of computer hardware. The most ecologically sound computer hardware will be scavenged or upcycled making the number of devices that need unique support is potentially very large. Therefore, this virtual machine must remain small enough to be easy to implement by a single person within a few weeks of effort. This need for simplicity is in conflict with the features that would be most useful for such a machine. Given hardware variability, system interaction should degrade gracefully when hardware features are not present. End-user facing software should take into account a large number of alternate input and interaction methods.
Software may also need to consider the possibility that the hardware may prefer 8, 16, 32, or 64 bit numbers. Systems like hundredrabbit's UXN circumvent this problem by only including 8bit numbers. This limitation makes it incredibly difficult to compute real-time audio, however. I think a different balance between these trade-offs would need to be struck to create a sustainable computer music environment.
The system I am imagining may need to present numerical types and sizes in a way that allows the use of larger types, if available. It should also provide the capacity to fail over gracefully to smaller types. Small number sizes should be preferred where practical. Numerical types may need to be templated and alternate code written for each size.
dependency
Software dependencies should be carefully vetted for resource use, hardware assumptions, and platform restrictions.
resource utilization
Resource utilization should be as minimal as possible. Software should potentially be written to adapt to different resource profiles, providing different feature implementations for each level.
aesthetics
Life-like replication of sensory experiences using computers have been enabled by increasing filesizes, bitdepths, and samplerates. Advertising resource use of media became a kind of shorthand to signify its quality. This isn't to say that it is pointless to operate on 32bit float, 96k sampled audio, for example. There are manipulations that you can make using these specs that you cannot make without degrading the quality of the output in a noticeable way. However, the aesthetic quality of the degradation is sometimes interesting in of itself. Who is to say which version is better? Does a sustainable version of computing require different aesthetics for media - one that appreciates the sound of these distortions? Its not as if these distortions are universally despised, or even that they are unpleasant. There are event plugins that spend extra CPU resources to emulate them on systems where they will not be produced naturally.
In an essay on Permacomputing, viznut speculates about this aesthetic: "For extreme realism, perfection, detail and sharpness, people would prefer to look at nature."