paper: futures — add artistic history, 3D, and cessation sections

+48 -19

changelogs/2026-03-18-aesthetic-changes-in-march.md

··· 1 - # Aesthetic Changes in March So Far 1 + # Weekly News From @jeffrey 2 2 3 3 **status:** draft 4 4 **author:** @jeffrey 5 5 **for:** news.aesthetic.computer post 6 + **date:** week of march 13–20, 2026 6 7 **research:** reports/2026-03-18-changeloggin-4-all.md 7 8 8 9 --- 9 10 10 - chat feels different now. if you've been in there recently you probably noticed — scrolling has this bouncy inertia to it. you drag, let go, it coasts and settles. handles have colored shadows. multi-line messages stack properly. it's small stuff but it changes the texture of being in the room together. 18,000+ messages in chat now across 2,800 handles and the space needed to feel better than it did. 11 + this is the first weekly commit changelog for aesthetic computer. i'm going to try posting one of these every week — a digest of what actually shipped, with links to the commits so you can click through to the code. i'll keep experimenting with what kind of information to include and how to present it. thanks for reading and for using ac. 12 + 13 + 508 commits this week. here's what changed. 14 + 15 + ## the os boots for real now 16 + 17 + ac native os had its biggest week yet. boot time dropped 3.5 seconds from shared library deduplication alone ([bb63330](https://github.com/whistlegraph/aesthetic-computer/commit/bb63330c6), 84MB less in the initramfs — [d3ba789](https://github.com/whistlegraph/aesthetic-computer/commit/d3ba789ec)). there's a proper software volume control now — samples get multiplied in the audio thread, not through flaky ALSA mixer elements ([ede89eb](https://github.com/whistlegraph/aesthetic-computer/commit/ede89eb57)). the boot plays a little arpeggio when you power on without credentials ([005cf4f](https://github.com/whistlegraph/aesthetic-computer/commit/005cf4ffb)). light mode works — notepat's visualizer, recital view, and picture overlay all respect it ([2aed1e9](https://github.com/whistlegraph/aesthetic-computer/commit/2aed1e9dc), [4b75e7e](https://github.com/whistlegraph/aesthetic-computer/commit/4b75e7e3f)). 18 + 19 + the layout went responsive ([24a45d7](https://github.com/whistlegraph/aesthetic-computer/commit/24a45d7e9)). buttons center on small screens, text wraps, resize events don't break anything. there's a mobile-first left-aligned layout with colored section headers ([faf36c4](https://github.com/whistlegraph/aesthetic-computer/commit/faf36c4c7)). 20 + 21 + oven builds got heavier but more complete: cage, seatd, Mesa, Wayland ([c885381](https://github.com/whistlegraph/aesthetic-computer/commit/c8853811d)), all i915 GPU firmware, Intel SOF audio firmware for every platform we've tested ([1b5c3b7](https://github.com/whistlegraph/aesthetic-computer/commit/1b5c3b746), [e3b544e](https://github.com/whistlegraph/aesthetic-computer/commit/e3b544e95)). claude code ships as a native binary in the image now ([d5b25da](https://github.com/whistlegraph/aesthetic-computer/commit/d5b25dafa)). credentials get injected at flash time through ac-usb ([24d3f5e](https://github.com/whistlegraph/aesthetic-computer/commit/24d3f5eed)). 22 + 23 + OTA updates go through cloudflare now — there's an edge CDN at os.aesthetic.computer with named build URLs ([aedd4aa](https://github.com/whistlegraph/aesthetic-computer/commit/aedd4aaa5)) and a mirror selector ([6c538fe](https://github.com/whistlegraph/aesthetic-computer/commit/6c538fe9f)). the machine flushes its full boot-to-shutdown log to MongoDB on poweroff ([6c94411](https://github.com/whistlegraph/aesthetic-computer/commit/6c9441192)) so we can debug remotely. 24 + 25 + babypat exists: a bare-metal UEFI musical keyboard in 1,536 bytes ([2740d3c](https://github.com/whistlegraph/aesthetic-computer/commit/2740d3cf6)). colors on keypress, smooth fade. it has its own CLI (bb-os) and UEFI file logging for debug ([3020e36](https://github.com/whistlegraph/aesthetic-computer/commit/3020e36ff)). 26 + 27 + ## mic capture and recording 28 + 29 + spent most of the week fighting ALSA capture on Intel HDA. the problem: DMA transfers were failing with EIO on Kaby Lake because Intel IOMMU was enabled. fixed by disabling IOMMU in the kernel command line ([d2caf3e](https://github.com/whistlegraph/aesthetic-computer/commit/d2caf3e0f)). then the capture thread needed a ring buffer for reliable recording ([a061634](https://github.com/whistlegraph/aesthetic-computer/commit/a061634ef)) — quick key taps were missing data because the read loop was too slow to catch short bursts ([1e5caa5](https://github.com/whistlegraph/aesthetic-computer/commit/1e5caa52c)). there's a spin-wait on mic_stop now so the buffer actually fills before we stop reading ([6aa5f0f](https://github.com/whistlegraph/aesthetic-computer/commit/6aa5f0f84)). period size settled at 1024 frames, buffer at 4 periods ([2f722bd](https://github.com/whistlegraph/aesthetic-computer/commit/2f722bd30)). 30 + 31 + recording has a countdown timer ([a061634](https://github.com/whistlegraph/aesthetic-computer/commit/a061634ef)). there's a tap callback for triggering records from JS ([eb23e8f](https://github.com/whistlegraph/aesthetic-computer/commit/eb23e8fec)). 32 + 33 + ## papers 34 + 35 + the papers site got a real build pipeline. the oven auto-builds all papers on push ([3e215b0](https://github.com/whistlegraph/aesthetic-computer/commit/3e215b008)) — xelatex runs three passes, bibtex resolves, and the PDFs deploy to Netlify. incremental builds only rebuild papers whose sources changed ([1a999d4](https://github.com/whistlegraph/aesthetic-computer/commit/1a999d459)). 96 PDFs live on the site now ([e353e4a](https://github.com/whistlegraph/aesthetic-computer/commit/e353e4a00)). 36 + 37 + new paper: "CalArts, Callouts, and Papers" — first paper tagged PSYCHO ([fcf828f](https://github.com/whistlegraph/aesthetic-computer/commit/fcf828f66)). the PSYCHO label on the papers index blinks red/yellow/black/white ([4eb6ed0](https://github.com/whistlegraph/aesthetic-computer/commit/4eb6ed03b)) and the title characters color-cycle and wiggle ([cab9481](https://github.com/whistlegraph/aesthetic-computer/commit/cab9481dd)). 38 + 39 + tables in cards format no longer overflow the column ([e262808](https://github.com/whistlegraph/aesthetic-computer/commit/e26280854)). every tabular gets wrapped in an adjustbox that clamps to linewidth. 40 + 41 + the author line across all papers changed from "Jeffrey Alan Scudder" to "@jeffrey" ([b6ae995](https://github.com/whistlegraph/aesthetic-computer/commit/b6ae99586)). fact-checked the Sucking the Complex paper — TikTok founding date, Ulman, Blas, Saltz citations were wrong ([d5d36b3](https://github.com/whistlegraph/aesthetic-computer/commit/d5d36b343)). added critique-as-content references to the platter ([872766e](https://github.com/whistlegraph/aesthetic-computer/commit/872766e32)). papers now have PDF hit tracking and proper OG meta tags ([76e5f11](https://github.com/whistlegraph/aesthetic-computer/commit/76e5f11cf)). 11 42 12 - the prompt — the first thing you see when you open ac — is more alive. it cycles through three feeds now: chat, clock-chat (laer-klokken timestamps), and content (kidlisp pieces, paintings, tapes). there's a mood of the day from the community. media previews drift with a slow zoom. when your hand stops moving it auto-selects whatever's under it. the prompt used to be a command line. now it's more like a bulletin board that breathes. 43 + ## kidlisp and keeps 13 44 14 - profiles show what you're doing right now. your painting count, your pieces, your kidlisp programs, your moods, your chats — all live. if someone visits your profile they can see what piece you're currently in, whether you're online, your last ping. it refreshes every 30 seconds. presence is real on ac now. 45 + keeps.kidlisp.com → keep.kidlisp.com. singular ([4c349e8](https://github.com/whistlegraph/aesthetic-computer/commit/4c349e80c)). buy.kidlisp.com lost its card carousel ([7d02521](https://github.com/whistlegraph/aesthetic-computer/commit/7d0252127)) and got drop shadows on the Fresh/Sold tabs with auto-cycling cards instead ([e02fd1d](https://github.com/whistlegraph/aesthetic-computer/commit/e02fd1d36)). there's a `buy` command on the CLI now to fulfill objkt marketplace listings ([4469b4f](https://github.com/whistlegraph/aesthetic-computer/commit/4469b4f17)). 15 46 16 - notepat keeps growing. the big thing this month: if you have a nuphy air60 he keyboard, every key is pressure-sensitive. hold harder, play louder. the trails on screen get brighter with your finger pressure. there's an echo slider for room reverb. wave type selection (sine, triangle, saw, square, noise). waveform visualization above the pads. mic sampling with pitch-shifted playback. the status bar shows your clock in LA time, wave type, octave, sample rate, volume, battery, wifi. notepat isn't a demo anymore — people play it as an instrument. 47 + kidlisp.com got a dashboard: FPS gauge, interpreter state, memory usage, device info ([531b8cf](https://github.com/whistlegraph/aesthetic-computer/commit/531b8cf34)). GPU rendering toggle in preferences ([351dbb3](https://github.com/whistlegraph/aesthetic-computer/commit/351dbb3ef)). light mode theme ([de43b3f](https://github.com/whistlegraph/aesthetic-computer/commit/de43b3f2f)). settings modal is more compact ([de43b3f](https://github.com/whistlegraph/aesthetic-computer/commit/de43b3f2f)). all KidLisp effects force the CPU path now (FORCE_CPU flag) because Mali and Adreno GPUs were still glitching on some shaders ([f69c760](https://github.com/whistlegraph/aesthetic-computer/commit/f69c76052)). 17 48 18 - kidlisp keeps went live on tezos mainnet. 25 tokens minted so far, 8 owners, floor at 12 XTZ. the mint experience walks you through a timeline: fetch source, initialize, resolve dependencies, thumbnail, bundle, IPFS, metadata, review, sign, done. you watch your code become permanent. buy.kidlisp.com has a neon vegas thing going on — browse available keeps, see what's sold, preview the artifacts fullscreen. keep.kidlisp.com got a redesign with unkept/kept tabs, a market tab pulling from objkt, and a wallet leaderboard showing keepers vs buyers. 49 + ## the prompt and frontend 19 50 20 - squash is our first real multiplayer game. 2D platformer — you stomp on opponents to score. best of 3 rounds, first to 3 kills. it runs on a dual-channel setup: UDP for your position (fast, might drop a packet, doesn't matter), websocket for game events (joins, scores, round control — stuff that can't be lost). when you land a stomp, both screens burst particles at the same spot. you invite people from chat by typing 'squash. this pattern — UDP + websocket together — is documented now and ready for anyone building networked pieces. 51 + the login curtain has a spinning wireframe cube now, over a faster starfield ([f91b7fb](https://github.com/whistlegraph/aesthetic-computer/commit/f91b7fb1a)). the x86 OS button got its margins fixed three separate times ([b4eb33a](https://github.com/whistlegraph/aesthetic-computer/commit/b4eb33a2c), [cfe25b6](https://github.com/whistlegraph/aesthetic-computer/commit/cfe25b6a6), [2ddcb64](https://github.com/whistlegraph/aesthetic-computer/commit/2ddcb6490)) (it's right this time). commit button text is brighter ([ec973bd](https://github.com/whistlegraph/aesthetic-computer/commit/ec973bd32)). 21 52 22 - android rendering works properly. if you were on a phone with a mali or adreno GPU and blur/sharpen/contrast looked broken — that's fixed. there's a CPU fallback mode now (mobileSafeMode) and the shaders got rewritten for those chipsets. kidlisp pieces render correctly on mobile. 53 + email addresses in chat auto-link correctly instead of getting parsed as @handles ([49c9d92](https://github.com/whistlegraph/aesthetic-computer/commit/49c9d9287)). the profanity filter skips clock-chat (laer-klokken) because timestamps kept getting flagged ([cea3971](https://github.com/whistlegraph/aesthetic-computer/commit/cea397157)). TTS only fires in the prompt piece now, not everywhere ([60b98f5](https://github.com/whistlegraph/aesthetic-computer/commit/60b98f569)). 23 54 24 - the ac native os boots on real hardware now with wifi that auto-connects and remembers credentials, a terminal emulator, device login without needing a browser, and over-the-air updates through cloudflare. claude code runs natively on it. the status bar shows time, battery, wifi signal. background tint shifts with time of day. this is still early but it's a real computer you can hold. 55 + the Dual Kawase blur replaced the old Gaussian — it's the ARM SIGGRAPH 2015 technique ([3e24959](https://github.com/whistlegraph/aesthetic-computer/commit/3e249595b)). mobileSafeMode blocks all GPU effects on Mali/Adreno except Kawase ([00149953](https://github.com/whistlegraph/aesthetic-computer/commit/00149953a)). the vortex/spin shader got fixed twice ([af23b88](https://github.com/whistlegraph/aesthetic-computer/commit/af23b88e9), [82a8896](https://github.com/whistlegraph/aesthetic-computer/commit/82a8896d0)). 25 56 26 - we're heading to ars electronica 2026 with a piece called demoplay — an automated conductor that walks through ac's capabilities as a performance. the score has 6 movements: the prompt, the pieces (354 built-in), kidlisp ("a language a child can read"), the social layer, flow state, and a coda. 57 + ## infrastructure 27 58 28 - 16,779 kidlisp programs. 4,429 paintings. 265 user-published pieces. 2,812 handles. 20 physical prints mailed. the numbers are small and the community is real. 59 + the oven's papers builder auto-pushes built PDFs to git ([63f4ffa](https://github.com/whistlegraph/aesthetic-computer/commit/63f4ffa77)). the devcontainer cleaned up auto-installed extensions ([a83ba4d](https://github.com/whistlegraph/aesthetic-computer/commit/a83ba4d50)). a Lotus Notes opinion piece got written ([3475e48](https://github.com/whistlegraph/aesthetic-computer/commit/3475e48fa)) (unrelated but it happened this week). 29 60 30 - full technical breakdown lives on the platter at papers.aesthetic.computer/platter. 61 + --- 31 62 32 63 — @jeffrey 33 64 ··· 36 67 ## notes to self 37 68 38 69 - tone: conversational, first person, lowercase. not a press release. 39 - - focus: what people touch and feel, not internal tooling 40 - - the new generative pieces (splat, halley, morpho) are lab experiments — don't announce them as features 41 - - don't list 884 commits, nobody cares about commit counts 42 - - the papers/research stuff is for a different audience — mention ars but don't list paper titles 43 - - keep the keeps section grounded in what the experience is, not contract addresses 44 - - TODO: is the ars electronica framing right? check with actual submission 70 + - focus: what people touch and feel + enough technical detail to be honest 71 + - 508 commits is a lot — the structure helps people scan 72 + - every claim now has a clickable commit hash so readers can verify 73 + - TODO: is the ars electronica framing still relevant? removed for now since it's not this week's news 45 74 - TODO: should this link to specific pieces? (aesthetic.computer/squash, etc.) 46 - - TODO: do i want to mention the agent memory system? probably not, it's internal 47 75 - TODO: read it out loud — does it sound like me talking? 76 + - TODO: the ALSA capture section might be too deep — is that the right audience for news.aesthetic.computer?

+425

papers/arxiv-futures/futures.tex

··· 1 + % !TEX program = xelatex 2 + \documentclass[10pt,letterpaper,twocolumn]{article} 3 + 4 + % === GEOMETRY === 5 + \usepackage[top=0.75in, bottom=0.75in, left=0.75in, right=0.75in]{geometry} 6 + 7 + % === FONTS === 8 + \usepackage{fontspec} 9 + \usepackage{unicode-math} 10 + 11 + \setmainfont{Latin Modern Roman} 12 + \setsansfont{Latin Modern Sans} 13 + 14 + % Custom AC fonts 15 + \newfontfamily\acbold{ywft-processing-bold}[ 16 + Path=../../system/public/type/webfonts/, 17 + Extension=.ttf 18 + ] 19 + \newfontfamily\aclight{ywft-processing-light}[ 20 + Path=../../system/public/type/webfonts/, 21 + Extension=.ttf 22 + ] 23 + \setmonofont{Latin Modern Mono}[Scale=0.85] 24 + 25 + % === PACKAGES === 26 + \usepackage{xcolor} 27 + \usepackage{titlesec} 28 + \usepackage{enumitem} 29 + \usepackage{booktabs} 30 + \usepackage{tabularx} 31 + \usepackage{fancyhdr} 32 + \usepackage{hyperref} 33 + \usepackage{graphicx} 34 + \graphicspath{{figures/}{../../papers/arxiv-ac/figures/}} 35 + \usepackage{ragged2e} 36 + \usepackage{microtype} 37 + \usepackage{natbib} 38 + \usepackage[colorspec=0.92]{draftwatermark} 39 + 40 + % === COLORS (AC palette) === 41 + \definecolor{acpink}{RGB}{180,72,135} 42 + \definecolor{acpurple}{RGB}{120,80,180} 43 + \definecolor{acdark}{RGB}{64,56,74} 44 + \definecolor{acgray}{RGB}{119,119,119} 45 + \definecolor{draftcolor}{RGB}{180,72,135} 46 + 47 + % === DRAFT WATERMARK === 48 + \DraftwatermarkOptions{ 49 + text=WORKING DRAFT, 50 + fontsize=3cm, 51 + color=draftcolor!18, 52 + angle=45, 53 + pos={0.5\paperwidth, 0.5\paperheight} 54 + } 55 + 56 + % === HYPERREF === 57 + \hypersetup{ 58 + colorlinks=true, 59 + linkcolor=acpurple, 60 + urlcolor=acpurple, 61 + citecolor=acpurple, 62 + pdfauthor={@jeffrey}, 63 + pdftitle={Five Years from Now: What Aesthetic Computer Probably Becomes}, 64 + } 65 + 66 + % === SECTION FORMATTING === 67 + \titleformat{\section} 68 + {\normalfont\bfseries\normalsize\uppercase} 69 + {\thesection.} 70 + {0.5em} 71 + {} 72 + \titlespacing{\section}{0pt}{1.2em}{0.3em} 73 + 74 + \titleformat{\subsection} 75 + {\normalfont\bfseries\small} 76 + {\thesubsection} 77 + {0.5em} 78 + {} 79 + \titlespacing{\subsection}{0pt}{0.8em}{0.2em} 80 + 81 + % === HEADER/FOOTER === 82 + \pagestyle{fancy} 83 + \fancyhf{} 84 + \renewcommand{\headrulewidth}{0pt} 85 + \fancyhead[C]{\footnotesize\color{acpink}\textit{Working Draft --- not for citation}} 86 + \fancyfoot[C]{\footnotesize\thepage} 87 + 88 + % === CUSTOM COMMANDS === 89 + \newcommand{\ac}{\textsc{Aesthetic Computer}} 90 + \newcommand{\acos}{\textsc{AC Native OS}} 91 + \newcommand{\np}{\textsc{notepat}} 92 + 93 + % === LIST SETTINGS === 94 + \setlist[itemize]{nosep, leftmargin=1.2em, itemsep=0.1em} 95 + \setlist[enumerate]{nosep, leftmargin=1.2em} 96 + 97 + % === COLUMN SEPARATION === 98 + \setlength{\columnsep}{1.8em} 99 + 100 + % === PARAGRAPH SETTINGS === 101 + \setlength{\parindent}{1em} 102 + \setlength{\parskip}{0.3em} 103 + 104 + % Hyphenation for narrow two-column layout 105 + \tolerance=800 106 + \emergencystretch=1em 107 + \hyphenpenalty=50 108 + 109 + \begin{document} 110 + 111 + % ============ TITLE BLOCK ============ 112 + 113 + \twocolumn[{% 114 + \begin{center} 115 + \includegraphics[height=4em]{pals}\par\vspace{0.5em} 116 + {\acbold\fontsize{22pt}{26pt}\selectfont\color{acdark} Five Years from Now}\par 117 + \vspace{0.2em} 118 + {\aclight\fontsize{11pt}{13pt}\selectfont\color{acpink} What Aesthetic Computer Probably Becomes}\par 119 + \vspace{0.3em} 120 + {\aclight\fontsize{9pt}{11pt}\selectfont\color{acgray} Surplus Hardware, Spatial Instruments, and the Long Game of a Personal Tool}\par 121 + \vspace{0.6em} 122 + {\normalsize @jeffrey}\par 123 + {\small\color{acgray} Aesthetic.Computer}\par 124 + {\small\color{acgray} ORCID: \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913}}\par 125 + \vspace{0.3em} 126 + {\small\color{acpurple} \url{https://aesthetic.computer}}\par 127 + \vspace{0.6em} 128 + \rule{\textwidth}{1.5pt} 129 + \vspace{0.5em} 130 + \end{center} 131 + 132 + \begin{center} 133 + {\small\color{acpink}\textbf{[ working draft --- not for citation ]}} 134 + \end{center} 135 + \vspace{0.3em} 136 + 137 + \begin{quote} 138 + \small\noindent\textbf{Abstract.} 139 + This paper extrapolates the next five years (2026--2031) of \ac{} based on the project's current trajectory, existing infrastructure, stated ambitions, and the forces---economic, cultural, and material---acting on it. We argue that the project is likely to evolve along seven convergent axes: (1)~the continuity of a 94-project creative lineage that constrains the space of likely futures, (2)~the maturation of \acos{} into a deployable instrument for surplus hardware at scale, (3)~the emergence of distributed laptop ensembles as a musical and pedagogical form, (4)~the expansion of 3D from software rasterizer to spatial creative medium, (5)~the deepening of a scholarly identity through sustained paper production, (6)~the growth of KidLisp into a self-sustaining creative language community, and (7)~a reckoning with sustainability---including the possibility of the project's deliberate or involuntary cessation---that will determine whether it survives its own ambitions. This is not a roadmap. It is a reading of momentum---an attempt to ask what a project \emph{wants to become} based on what it has already chosen to do. 140 + \end{quote} 141 + \vspace{0.5em} 142 + }] 143 + 144 + % ============ 1. INTRODUCTION ============ 145 + 146 + \section{Introduction} 147 + 148 + \ac{} is a mobile-first runtime and social network for creative computing, comprising 359 built-in interactive programs (``pieces''), a bare-metal Linux operating system that boots any x86\_64 machine into a creative instrument, a minimal Lisp dialect for generative art, and a growing community of 2,812 registered users~\citep{scudder2026ac}. The project is authored and maintained primarily by a single developer, @jeffrey, with AI-assisted maintenance (``AestheticAnts'') handling routine upkeep. 149 + 150 + As of March 2026, the project has produced 19 research papers across four languages, a bare-metal OS that boots in 7.3 seconds~\citep{scudder2026os}, a blockchain integration for minting generative artworks, and a 7,912-line musical instrument (\np{}) that has become the system's front door~\citep{scudder2026notepat}. The codebase traces its lineage through 94 predecessor projects spanning more than a decade of tool-making. 151 + 152 + This paper does not propose what \ac{} \emph{should} do. It attempts to read what it \emph{probably will} do, based on the momentum already visible in the code, the papers, the infrastructure decisions, and the philosophical commitments that have shaped the project to date. 153 + 154 + % ============ 2. NINETY-FOUR PROJECTS ============ 155 + 156 + \section{Ninety-Four Projects and Counting} 157 + \label{sec:history} 158 + 159 + Any projection of \ac{}'s future must reckon with the depth of its past. The project is not a startup pivoting toward product-market fit. It is the 95th iteration of a single sustained inquiry: \emph{what should a personal creative computing instrument be?} 160 + 161 + \subsection{The Drawing Software Lineage (2011--2020)} 162 + 163 + The archaeology paper~\citep{scudder2026archaeology} traces \ac{} through 94 predecessor projects spanning two GitHub accounts (50+ repositories), a 109\,GB legacy server archive, and a Dropbox corpus. The trajectory begins with \textbf{thePRBAT} (Polygon Replicating Bitmap Authoring Tool, 2011), a Flash-based digital imaging tool built as a BFA thesis at Ringling College, and arrives at \ac{} through a decade of drawing software variants: \textbf{JeffreyPaint} (2014, JavaScript + Unity), \textbf{Finger Quilt} (2016, iOS/Swift), \textbf{Dot} (2017, a plotting application that prefigures AC's \texttt{plot} disk), and most importantly \textbf{No Paint} (2014--2020), which went through five incarnations---Rails, JavaScript shim, WebGL prototype, iOS/Cordova, Vercel site---before being absorbed into \ac{}. 164 + 165 + This is not a history of abandoned projects. It is a history of \emph{restarts}: the same person, asking the same question, choosing to start over rather than accumulate features. The pattern is visible in \ac{} itself: the piece model (single file, lifecycle functions, immediate-mode graphics) is a constraint-first design that \emph{prevents} the feature accumulation that killed earlier iterations. 166 + 167 + \subsection{The Performance Turn (2016--2018)} 168 + 169 + Between 2016 and 2018, @jeffrey toured with Goodiepal \& Pals across 65+ venues in Europe, building real-time performance tools: audience participation interfaces, music notation renderers, subtitle displays for live lectures. These tools---built fast, used once, thrown away---established a design principle that persists in \ac{}: software as instrument, not as product. The tools were played, not shipped. 170 + 171 + The Goodiepal influence runs deeper than collaboration. The goodiepal paper~\citep{scudder2026goodiepal} identifies five threads that carry through to \ac{}: instrument-first design, community organized through affinity rather than institution, works designed to resist digital reproduction, and radical pedagogy through direct engagement rather than curriculum. 172 + 173 + \subsection{Why History Matters for Projection} 174 + 175 + The 94-project history constrains our projection in two ways. First, it makes sudden pivots unlikely. @jeffrey has been circling the same problems---personal tools, creative instruments, constraint-based design---for 15 years. The next 5 years will almost certainly stay within this orbit. Second, it makes abandonment unlikely for the reasons people usually abandon projects (boredom, loss of interest, attraction to something shinier). The risk is not distraction; it is exhaustion. We return to this in \S\ref{sec:giveup}. 176 + 177 + % ============ 3. THE SURPLUS HARDWARE WAVE ============ 178 + 179 + \section{The Surplus Hardware Wave} 180 + \label{sec:surplus} 181 + 182 + The single largest force acting on \ac{}'s future is external: in October 2025, Microsoft ended support for Windows 10, rendering an estimated 240 million PCs obsolete by institutional standards~\citep{ewaste2024monitor}. These machines are not broken. They are ThinkPads, EliteBooks, and Latitudes with 8--16\,GB RAM, 1080p screens, WiFi, and 6--10 hour batteries. They cost \$30--80 on the surplus market. They are the raw material for everything that follows. 183 + 184 + \subsection{From Prototype to Fleet (2026--2027)} 185 + 186 + \acos{} already boots on surplus hardware~\citep{scudder2026os}. The gap between ``boots on two ThinkPads in @jeffrey's apartment'' and ``boots on 30 machines in a classroom'' is not primarily technical. It is operational: WiFi credential management, per-device identity provisioning, hardware compatibility testing across dozens of laptop models, and a flashing workflow that a non-technical person can execute. 187 + 188 + The likely near-term work is mundane but critical: 189 + 190 + \begin{itemize} 191 + \item \textbf{Per-user WiFi storage}: moving hardcoded SSIDs out of JavaScript pieces into persistent per-device config files that survive OTA updates 192 + \item \textbf{Hardware compatibility matrix}: systematic testing across ThinkPad X1/T/L series, HP EliteBook 800 series, Dell Latitude 5000/7000 series 193 + \item \textbf{One-command flashing}: a USB image builder that takes a handle, colors, and WiFi credentials and produces a bootable drive 194 + \item \textbf{A/B kernel slots}: dual-partition boot with automatic rollback if the new kernel fails health checks 195 + \end{itemize} 196 + 197 + These are not glamorous features. They are the difference between an art project and an infrastructure project. The trajectory of the codebase---OTA updates already working, build names already generated, device identity already inscribed in the boot partition---suggests that @jeffrey understands this distinction and is moving toward the infrastructure side. 198 + 199 + \subsection{The 50-Dollar Instrument (2027--2028)} 200 + 201 + If the operational work lands, the economic argument becomes very loud: a complete creative computing instrument---personalized, self-updating, requiring zero IT infrastructure---for the price of a surplus laptop and a USB drive. No Chromebook enrollment. No Apple ID. No subscription. 202 + 203 + The OLPC project~\citep{kraemer2009olpc} demonstrated that hardware-first approaches to computing access fail on cost and logistics. The Raspberry Pi addressed cost (\$35) but requires \$150 in accessories. \ac{}'s proposition is different: the hardware already exists, already has a screen, keyboard, battery, and WiFi, and is being discarded by the millions. The software is 89\,MB. 204 + 205 + The likely outcome by 2028 is not mass adoption but \emph{proof points}: a handful of classrooms, community centers, or workshop contexts where fleets of 10--30 surplus machines run \acos{} and the results are documented. These proof points become the evidence base for grant applications, institutional partnerships, and the sustainability arguments described in \S\ref{sec:sustainability}. 206 + 207 + % ============ 3. PLANETARY ENSEMBLES ============ 208 + 209 + \section{Planetary Ensembles} 210 + \label{sec:ensembles} 211 + 212 + The PLOrk paper~\citep{scudder2026plork} makes an argument that the existing codebase already supports: laptop orchestras have been musically legitimate since Princeton's PLOrk proved the concept in 2006~\citep{trueman2006plork}, but the model is trapped in universities at \$1,500+ per seat. \acos{} on surplus hardware reduces the cost to \$50/seat. The question is whether anyone will play. 213 + 214 + \subsection{notepat as Ensemble Instrument (2026--2027)} 215 + 216 + \np{} is already a polyphonic keyboard instrument with 32-voice synthesis, room reverb, and wave-type selection~\citep{scudder2026notepat}. It runs on bare metal at 192\,kHz. The missing ingredient for ensemble performance is not audio quality but \emph{coordination}: synchronized tempo, shared harmonic space, and a conductor interface. 217 + 218 + The likely development path: 219 + 220 + \begin{itemize} 221 + \item \textbf{UDP ensemble sync}: extending the existing dual-channel networking (WebSocket + UDP) to synchronize beat clocks across devices on a local network 222 + \item \textbf{Conductor piece}: a new piece that displays the ensemble state and allows a conductor to set tempo, key, and dynamics 223 + \item \textbf{Spatialization}: using the physical positions of surplus laptops as distributed speakers---the ensemble \emph{is} the sound system, following Turino's participatory music model~\citep{turino2008music} 224 + \end{itemize} 225 + 226 + This thread has obvious conference appeal. A live demonstration of 10 surplus ThinkPads playing a coordinated musical piece---each showing the player's handle in rainbow text, each contributing a voice to a distributed sound field---is the kind of demo that wins Ars Electronica mentions and NIME submissions. 227 + 228 + \subsection{Beyond Music (2028--2031)} 229 + 230 + The ensemble model generalizes beyond music. A network of surplus machines running coordinated pieces could be: 231 + 232 + \begin{itemize} 233 + \item A \textbf{distributed drawing wall}: each screen shows a section of a larger canvas, participants draw locally, and the network composites the result 234 + \item A \textbf{collaborative KidLisp environment}: students write generative programs that feed into a shared visual space 235 + \item A \textbf{performance score}: the machines execute a graphic score~\citep{scudder2026pieces}, each interpreting the same notation through different pieces 236 + \end{itemize} 237 + 238 + The infrastructure for all of these already exists: WebSocket relay, UDP broadcast, per-device identity, and a piece model that supports any combination of graphics, audio, and input. What's missing is the \emph{choreography}---the pieces themselves and the social forms around them. 239 + 240 + % ============ THE THIRD DIMENSION ============ 241 + 242 + \section{The Third Dimension} 243 + \label{sec:3d} 244 + 245 + \ac{} is widely perceived as a 2D system. The immediate-mode graphics API---\texttt{wipe}, \texttt{ink}, \texttt{line}, \texttt{box}---and the pixel-art aesthetic of most pieces reinforce this impression. But the infrastructure tells a different story. A full software 3D rasterizer already exists, a multiplayer FPS already ships, and the architectural choices made in the bare-metal OS position 3D as the next major expressive frontier. 246 + 247 + \subsection{What Already Works} 248 + 249 + The bare-metal OS includes \texttt{graph3d.c}, a ~600-line CPU software rasterizer with perspective projection, frustum clipping (Sutherland-Hodgman against 6 clip planes), depth buffering, per-vertex color interpolation, and texture mapping with perspective-correct barycentric coordinates. The JavaScript API exposes this through a \texttt{Form} constructor: pieces create meshes with vertex positions, colors, and texture coordinates, then render them with \texttt{ink(r,g,b).form(mesh)}. 250 + 251 + Two production pieces demonstrate the system. \texttt{fps.mjs} provides a first-person camera with pointer lock, WASD movement, textured ground planes, and rotating cubes. \texttt{1v1.mjs} extends this into a multiplayer FPS with hitscan weapons, bot AI (patrol/chase/flee states), kill tracking, and the dual-channel networking pattern (WebSocket for reliable game events, UDP for low-latency position sync). The browser path uses Three.js (r0.182) with WebGL rendering and includes VR/XR session support~\citep{sutherland1968head}. 252 + 253 + The system thus has two parallel 3D paths: a software rasterizer on bare metal (CPU-only, no GPU) and a hardware-accelerated path in the browser (WebGL/Three.js, with WebGPU infrastructure in place). The API surface is identical from the piece author's perspective. 254 + 255 + \subsection{The GPU Question on Bare Metal (2026--2028)} 256 + 257 + The software rasterizer is elegant but fundamentally limited. Every surplus ThinkPad and EliteBook in the target fleet has an Intel integrated GPU capable of OpenGL 4.x or Vulkan 1.x, sitting idle. The kernel's DRM subsystem already manages the display via KMS modesetting; extending it to expose a render node for GPU-accelerated rasterization is a known engineering path (EGL on DRM, or Vulkan via \texttt{/dev/dri/renderD128}). 258 + 259 + The likely trajectory is cautious. @jeffrey's design instinct favors software control over hardware delegation---the entire bare-metal OS philosophy is ``know every instruction between power-on and pixel.'' GPU drivers introduce opacity: firmware blobs, driver bugs, vendor-specific behavior. The software rasterizer's virtue is that it is \emph{legible}: the pipeline from vertex to pixel is 600 lines of C that a student can read. 260 + 261 + The probable compromise: GPU acceleration as an opt-in path for pieces that need it, with the software rasterizer remaining the default and the reference implementation. This mirrors the browser architecture, where WebGPU exists alongside the 2D canvas but doesn't replace it. 262 + 263 + \subsection{3D as Creative Medium (2028--2031)} 264 + 265 + The more interesting question is not technical but expressive. What does 3D mean in a system designed around constraint, immediacy, and single-file pieces? 266 + 267 + The predecessor projects offer a clue. @jeffrey's work has always been about \emph{painting}: No Paint, JeffreyPaint, thePRBAT, the Radical Digital Painting lecture tour. The 3D infrastructure is not building toward a game engine or a CAD tool. It is building toward \emph{spatial painting}---the ability to place marks, colors, and forms in three-dimensional space with the same immediacy that \texttt{ink(255,0,0).line(0,0,100,100)} provides in two dimensions. 268 + 269 + The pieces that will matter are not the ones that look like Unity demos. They are the ones where 3D is used the way @jeffrey uses 2D: as raw material for instruments, for performances, for things that are played rather than consumed. A 3D \np{} where notes have spatial position and the room reverb is literal---sound emanating from forms distributed in virtual space. A 3D KidLisp where \texttt{(box 0 0 0 50 50 50)} places a cube the way \texttt{(rect 0 0 50 50)} places a rectangle. A fleet of surplus laptops each rendering a different camera angle of the same distributed 3D scene. 270 + 271 + The convergence with ensembles (\S\ref{sec:ensembles}) is where 3D becomes genuinely new. Synchronized 3D scenes across networked surplus machines---each screen a window into a shared virtual space, each player's input affecting the scene for all participants---is a form that neither game engines nor creative coding tools have explored at the \$50/seat price point. The networking is already proven (\texttt{1v1.mjs}). The hardware is already available (\S\ref{sec:surplus}). The missing piece is the artistic vision for what a distributed spatial instrument should feel like, and that is precisely the kind of question @jeffrey has spent 94 projects learning how to answer. 272 + 273 + % ============ 5. THE SCHOLARLY TURN ============ 274 + 275 + \section{The Scholarly Turn} 276 + \label{sec:scholarly} 277 + 278 + Between March 3 and March 20, 2026, @jeffrey produced 19 research papers in four languages. This is not normal behavior for a solo developer. It signals a deliberate turn toward scholarly legitimacy---an attempt to build what the RESEARCH-DIRECTION.md file calls a ``research moat'' around the project. 279 + 280 + \subsection{The Paper Mill (2026--2027)} 281 + 282 + The paper infrastructure is already industrial: a custom \LaTeX{} template with AC fonts, automated PDF building via a server (``the oven''), a cards format for single-sheet printouts, and a translation pipeline producing Danish, Spanish, and Chinese editions of every paper. The 40+ readings library provides the citation base. The pipeline is designed to produce, not to prototype. 283 + 284 + The near-term trajectory is submission: ACM C\&C Demos (April 16), ICCC Short Papers (April 24), JOSS software papers (rolling). If any of these land, the project gains a scholarly foothold that most creative coding tools never achieve. Processing~\citep{reas2007processing} and Scratch~\citep{resnick2009scratch} built their academic legitimacy over years; @jeffrey is attempting to compress that timeline by producing volume and targeting multiple venues simultaneously. 285 + 286 + \subsection{Artist-Scholar Identity (2028--2031)} 287 + 288 + The CalArts paper argues that an art school is an operating system---that the structures of proximity, critique, and disciplinary contamination that characterize institutions like CalArts can be ported into software. If @jeffrey continues to publish at this rate, the papers themselves become a body of work: not documentation of a software project, but a sustained argument about what creative computing is and who it is for. 289 + 290 + The likely 5-year outcome is one of two scenarios: 291 + 292 + \begin{enumerate} 293 + \item \textbf{The moat holds}: 6--10 papers are published across peer-reviewed venues, @jeffrey is invited to speak at conferences, and \ac{} enters the canon alongside Processing, Scratch, and Sonic Pi~\citep{aaron2016sonic} as a recognized creative computing environment. The papers create a feedback loop: scholarly attention brings users, users create pieces, pieces generate new papers. 294 + \item \textbf{The moat doesn't hold}: submissions are rejected, the solo-author pattern raises reviewer eyebrows, and the paper infrastructure goes dormant. The code survives; the scholarly identity does not. This is the more common outcome for artist-programmers. 295 + \end{enumerate} 296 + 297 + The honest bet is somewhere between: a few publications land, enough to establish credibility in niche venues (NIME, xCoAx, ICLC), but the mainstream HCI and PL conferences remain out of reach without collaborators and user studies. 298 + 299 + % ============ 5. KIDLISP'S OWN LIFE ============ 300 + 301 + \section{KidLisp's Own Life} 302 + \label{sec:kidlisp} 303 + 304 + KidLisp is a 118-function Lisp dialect for generative art~\citep{scudder2026kidlisp}. It is sandboxed (no file I/O, no networking), runs in the browser, and has already accumulated 16,779 stored programs and a blockchain minting integration via Tezos. The language is small enough to fit on an index card. 305 + 306 + \subsection{Language Community (2026--2028)} 307 + 308 + The Tezos ``keeps'' system---where KidLisp programs are minted as on-chain artworks for 2.5 XTZ---creates an economic incentive to write KidLisp. The keeps contract (v11) is live, the minting UI exists at keeps.kidlisp.com, and 5 tokens have already been minted and migrated. If the generative art market remains active, this thread sustains itself. 309 + 310 + The more interesting possibility is pedagogical. KidLisp's constraints---no state mutation, no side effects beyond drawing, 118 functions, runs in a browser---make it a candidate for teaching environments. A KidLisp curriculum built around the cards format (single-sheet programs that students can hold in their hands) aligns with Papert's constructionism~\citep{papert1980mindstorms} and the project's existing infrastructure. 311 + 312 + \subsection{Language Evolution (2028--2031)} 313 + 314 + KidLisp will face pressure to grow. Users will want state, animation, interactivity, sound. The design question is whether the language absorbs these features (becoming a general-purpose creative language) or remains deliberately minimal (a ``haiku language'' for static generative art, with JavaScript handling everything else). 315 + 316 + The project's history suggests the latter. @jeffrey's design instinct, visible across 94 predecessor projects, favors sharp constraints over feature accumulation. The piece model itself---single file, lifecycle functions, immediate-mode graphics~\citep{scudder2026pieces}---is a constraint-first design. KidLisp will probably stay small. The interesting growth will be in what people make with it, not what the language adds. 317 + 318 + % ============ 6. SUSTAINABILITY ============ 319 + 320 + \section{The Sustainability Question} 321 + \label{sec:sustainability} 322 + 323 + Every thread described above depends on a single person continuing to work. \ac{} has no venture funding, no institutional backing, and no employees beyond @jeffrey. The AestheticAnts maintenance system automates routine tasks, but architectural decisions, paper writing, hardware testing, and community cultivation require human attention. 324 + 325 + \subsection{The Funding Landscape (2026--2028)} 326 + 327 + The project has identified funding sources: Creative Capital (\$50,000 project grants), Prix Ars Electronica (\texteuro10,000), Gary Marsden Travel Awards, and GitHub Sponsors. The paper mill is partly a grant-writing strategy: a project with 19 papers, conference demos, and a documented user base is a stronger applicant than one with only code. 328 + 329 + The Tezos keeps provide a small revenue stream. Prints (20 ordered as of March 2026) provide another. Neither is sufficient to sustain full-time development. 330 + 331 + The honest projection: by 2028, the project either secures a grant or institutional affiliation (a residency, a teaching position, a research fellowship) or it slows to maintenance-mode development. This is not a failure scenario---many important creative tools are maintained part-time by their creators for decades. But the ambitious threads (planetary ensembles, surplus hardware fleets, scholarly moat) require full-time attention. 332 + 333 + \subsection{The Solo-Author Risk (2028--2031)} 334 + 335 + Illich's ``tools for conviviality''~\citep{illich1973tools} argues that good tools should be operable without specialized expertise. \ac{} aspires to this for its users, but the project itself is not convivial in Illich's sense: it requires @jeffrey's expertise to maintain. The bus factor is one. 336 + 337 + The mitigation is already partially in place: the codebase is open source, the architecture is documented in 19 papers, the piece API is designed for single-file simplicity, and the AestheticAnts system handles routine maintenance autonomously. But the difference between ``the code is open'' and ``someone else can lead the project'' is vast. 338 + 339 + The likely 5-year trajectory: @jeffrey remains the sole architect. A small community of piece authors contributes content (265 published pieces and growing). One or two contributors submit pull requests for specific features. The project does not achieve the ``thousand contributors'' model of Processing or p5.js, but it doesn't need to---its value proposition is not breadth but depth: a single vision, rigorously maintained, that takes creative computing to places committee-designed tools cannot go. 340 + 341 + % ============ 7. THE CONVERGENCE ============ 342 + 343 + \section{The Convergence} 344 + \label{sec:convergence} 345 + 346 + The seven threads described above are not parallel tracks. They converge. 347 + 348 + The 94-project history (\S\ref{sec:history}) establishes the trajectory that makes the other threads legible. Surplus hardware (\S\ref{sec:surplus}) provides the material base for planetary ensembles (\S\ref{sec:ensembles}). The 3D infrastructure (\S\ref{sec:3d}) extends the ensemble model into spatial performance. The papers (\S\ref{sec:scholarly}) document and legitimize all of it. KidLisp (\S\ref{sec:kidlisp}) provides a safe entry point for new users who arrive through any of these channels. Sustainability (\S\ref{sec:sustainability}) determines whether the convergence happens at all---and \S\ref{sec:giveup} examines what happens if it doesn't. 349 + 350 + The most likely 5-year scenario is this: by 2031, \ac{} is a recognized but niche creative computing environment with: 351 + 352 + \begin{itemize} 353 + \item \textbf{5,000--10,000 registered users}, up from 2,812, driven by notepat virality, conference demos, and classroom deployments 354 + \item \textbf{A bare-metal OS} deployed on 100--500 surplus machines across 5--15 sites (schools, community centers, artist residencies, workshops) 355 + \item \textbf{3--5 published papers} in peer-reviewed venues, establishing a minimal scholarly footprint 356 + \item \textbf{50,000+ KidLisp programs}, with a small but active generative art community minting keeps on Tezos 357 + \item \textbf{Ensemble performances} at 2--3 festivals or conferences, using fleets of surplus laptops as distributed instruments 358 + \item \textbf{A single maintainer} still writing most of the code, with AI-assisted maintenance handling an increasing share of routine work 359 + \end{itemize} 360 + 361 + This is not the most ambitious outcome, nor the most conservative. It is the outcome consistent with a project that has made specific, deliberate choices about what it cares about---depth over breadth, instruments over IDEs, maintenance over disruption---and that has the infrastructure to follow through on those choices at the pace a solo developer can sustain. 362 + 363 + % ============ 8. WHAT COULD CHANGE EVERYTHING ============ 364 + 365 + \section{What Could Change Everything} 366 + \label{sec:wildcards} 367 + 368 + Projections based on momentum are reliable precisely because they ignore discontinuities. Four wildcards could alter the trajectory entirely: 369 + 370 + \subsection{An Institutional Home} 371 + 372 + If @jeffrey takes a teaching position at an art school or research university, \ac{} gains something it currently lacks: students. A cohort of 15--30 students using \ac{} as their primary creative computing environment for a semester would produce more pieces, more bug reports, more use cases, and more scholarship than a decade of solo development. The CalArts paper's argument---that art school is an operating system---works in reverse: the operating system could become a school. 373 + 374 + \subsection{A Viral Moment} 375 + 376 + \np{} was posted to Hacker News and received attention. A second viral moment---a TikTok of a classroom full of surplus laptops playing music together, a tweet thread about the \$50 creative instrument, a conference demo that gets filmed and shared---could bring thousands of users in a week. The infrastructure (URL-addressable pieces, instant registration, social features) is designed to absorb this. Whether @jeffrey \emph{wants} to absorb it is a separate question. The project's anti-platform stance~\citep{fisher2009capitalist} suggests ambivalence about growth-for-growth's-sake. 377 + 378 + \subsection{AI as Collaborator} 379 + 380 + The AestheticAnts system already uses AI for routine maintenance. The agent memory system logs interactions and maintains continuity across conversations. If AI capabilities continue to advance, a future version of this system could do more than maintenance: it could write pieces, generate KidLisp programs, compose ensemble scores, and draft papers. The solo-author risk (\S\ref{sec:sustainability}) diminishes if the ``solo author'' is augmented by an AI collaborator that understands the project's history, philosophy, and codebase. 381 + 382 + This is not speculative in the way the other scenarios are. It is already happening. The question is one of degree: by 2031, does AI handle 10\% of the creative work, or 50\%? The answer will depend on choices @jeffrey makes about what he delegates and what he insists on doing himself. The project's emphasis on personal voice, on the ``PSYCHO'' papers that bear the author's temperature, suggests that the most important work will remain human. The infrastructure around it may not. 383 + 384 + \subsection{What If He Stops} 385 + \label{sec:giveup} 386 + 387 + The projections above assume continued effort. But the 94-project history (\S\ref{sec:history}) contains a pattern that must be named: @jeffrey has walked away from things before. No Paint had five incarnations. Each one was abandoned, not because the idea failed, but because the implementation calcified---because the gap between what the tool \emph{was} and what it \emph{should be} grew intolerable. The restarts were not failures of commitment. They were expressions of it. 388 + 389 + The risk for \ac{} is not that @jeffrey loses interest. Fifteen years of circling the same problems rules out casual abandonment. The risk is \emph{structural exhaustion}: the accumulation of operational weight---server bills, user support, hardware testing, paper submissions, grant applications, dependency updates---until the maintenance load crowds out the creative work that makes the project worth maintaining. Ukeles~\citep{ukeles1969manifesto} argued that maintenance is art, but even Ukeles acknowledged that maintenance without recognition becomes invisible labor. 390 + 391 + Three scenarios for cessation deserve consideration: 392 + 393 + \begin{enumerate} 394 + \item \textbf{The quiet fade}: development slows to sporadic commits, the servers stay up but the community drifts, and \ac{} joins the long list of ambitious personal tools that exist as archives rather than living systems. This is the most common outcome for solo-authored creative computing projects. It is not dramatic. It is the default. 395 + 396 + \item \textbf{The deliberate stop}: @jeffrey declares the project complete at some natural boundary---perhaps when the OS boots reliably on a dozen laptop models, or when the paper count reaches a round number, or when the 100th piece is published by someone other than him. He returns to painting on canvas (the Venice Family Clinic exhibition in May 2026 suggests this thread is already active). The code remains open. Someone may fork it. Most likely, no one does. 397 + 398 + \item \textbf{The 95th restart}: @jeffrey walks away from \ac{} to build its successor. This is the pattern the history predicts most strongly. No Paint became \ac{}. \ac{} could become something else---something that absorbs the lessons of the OS, the piece model, the ensemble networking, and the 3D rasterizer, but sheds the accumulated infrastructure weight. The new project starts clean, in a single file, and the cycle begins again. From the outside, this looks like failure. From inside the 94-project lineage, it looks like the process working exactly as designed. 399 + \end{enumerate} 400 + 401 + The honest assessment: scenario 3 is unlikely within 5 years because \ac{} has achieved escape velocity in ways No Paint never did---a registered user base, a bare-metal OS, a blockchain integration, 19 papers, a language with 16,000+ programs. The sunk cost is too high for a clean restart. But scenario 1 is entirely possible if the sustainability question (\S\ref{sec:sustainability}) goes unanswered. A project this ambitious, maintained by one person without stable funding, is always one bad year away from the quiet fade. 402 + 403 + The mitigation is the same one that has sustained the project so far: making the work itself rewarding enough that the operational burden is tolerable. The papers, the performances, the 3D rasterizer written from scratch, the bare-metal boot that takes 7 seconds---these are not features on a roadmap. They are the creative practice. If the practice stops being interesting, the project stops. If it stays interesting, the project survives anything short of the lights going out. 404 + 405 + % ============ 10. CONCLUSION ============ 406 + 407 + \section{Conclusion} 408 + 409 + Aesthetic Computer is a project that knows what it is. It is not searching for product-market fit, pivoting toward enterprise, or optimizing for growth metrics. It is a personal creative computing instrument being built in public by a single person who has been making versions of it for more than a decade across 94 predecessor projects. 410 + 411 + The next five years will be shaped by forces both internal (the pace @jeffrey can sustain, the funding he can secure) and external (240 million surplus PCs, the generative art economy, the academic conference cycle). The project's infrastructure---bare-metal OS, paper mill, piece model, social network, blockchain minting---is built to absorb these forces. Whether it will is a question of stamina, luck, and the willingness of the world to care about creative computing tools that are not owned by a platform. 412 + 413 + Nelson wrote in 1974 that ``you can and must understand computers NOW''~\citep{nelson1974computerlib}. Illich wrote in 1973 that tools should expand personal autonomy, not require institutional mediation~\citep{illich1973tools}. Ukeles wrote in 1969 that maintenance is art~\citep{ukeles1969manifesto}. \ac{} is the synthesis: a tool that is personal, convivial, and maintained as a creative practice. The bet is that this synthesis, applied to surplus hardware and sustained over time, creates something that lasts. 414 + 415 + Whether it does is the only interesting question. This paper offers no answer, only a reading of the forces in play. The code will decide. 416 + 417 + \vspace{0.5em} 418 + \noindent\textbf{ORCID:} \href{https://orcid.org/0009-0007-4460-4913}{0009-0007-4460-4913} 419 + 420 + % ============ REFERENCES ============ 421 + 422 + \bibliographystyle{plainnat} 423 + \bibliography{references} 424 + 425 + \end{document}

+266

papers/arxiv-futures/references.bib

··· 1 + @book{reas2007processing, 2 + title={Processing: A Programming Handbook for Visual Designers and Artists}, 3 + author={Reas, Casey and Fry, Ben}, 4 + year={2007}, 5 + publisher={MIT Press}, 6 + address={Cambridge, MA} 7 + } 8 + 9 + @misc{scudder2026ac, 10 + title={Aesthetic Computer '26: A Mobile-First Runtime for Creative Computing}, 11 + author={{@jeffrey}}, 12 + year={2026}, 13 + note={Companion paper describing the AC platform} 14 + } 15 + 16 + @misc{scudder2026os, 17 + title={AC Native OS '26: A Bare-Metal Creative Computing Operating System}, 18 + author={{@jeffrey}}, 19 + year={2026}, 20 + note={Companion paper describing the bare-metal OS} 21 + } 22 + 23 + @misc{scudder2026kidlisp, 24 + title={KidLisp '26: A Minimal Lisp for Generative Art}, 25 + author={{@jeffrey}}, 26 + year={2026}, 27 + note={Companion paper describing the KidLisp language} 28 + } 29 + 30 + @misc{scudder2026plork, 31 + title={PLORKing the Planet: From Laptop Orchestra to Planetary Organ}, 32 + author={{@jeffrey}}, 33 + year={2026}, 34 + note={Companion paper on laptop orchestras at planetary scale} 35 + } 36 + 37 + @misc{scudder2026notepat, 38 + title={notepat.com: From Keyboard Toy to System Front Door}, 39 + author={{@jeffrey}}, 40 + year={2026}, 41 + note={Companion paper on the political economy of a single piece} 42 + } 43 + 44 + @misc{scudder2026pieces, 45 + title={Pieces Not Programs: The Piece as a Unit of Creative Cognition}, 46 + author={{@jeffrey}}, 47 + year={2026}, 48 + note={Companion paper on the piece model} 49 + } 50 + 51 + @article{resnick2009scratch, 52 + title={Scratch: Programming for All}, 53 + author={Resnick, Mitchel and Maloney, John and Monroy-Hern{\'a}ndez, Andr{\'e}s and Rusk, Natalie and Eastmond, Evelyn and Brennan, Karen and Millner, Amon and Rosenbaum, Eric and Silver, Jay and Silverman, Brian and Kafai, Yasmin}, 54 + journal={Communications of the ACM}, 55 + volume={52}, 56 + number={11}, 57 + pages={60--67}, 58 + year={2009}, 59 + publisher={ACM} 60 + } 61 + 62 + @inproceedings{kraemer2009olpc, 63 + title={One Laptop per Child: Vision vs. Reality}, 64 + author={Kraemer, Kenneth L. and Dedrick, Jason and Sharma, Prakul}, 65 + booktitle={Communications of the ACM}, 66 + volume={52}, 67 + number={6}, 68 + pages={66--73}, 69 + year={2009}, 70 + publisher={ACM} 71 + } 72 + 73 + @book{kittler1999gramophone, 74 + title={Gramophone, Film, Typewriter}, 75 + author={Kittler, Friedrich A.}, 76 + year={1999}, 77 + publisher={Stanford University Press}, 78 + address={Stanford, CA} 79 + } 80 + 81 + @article{kittler1995no, 82 + title={There is No Software}, 83 + author={Kittler, Friedrich A.}, 84 + year={1995}, 85 + journal={CTheory}, 86 + note={Article a032} 87 + } 88 + 89 + @book{mcluhan1964understanding, 90 + title={Understanding Media: The Extensions of Man}, 91 + author={McLuhan, Marshall}, 92 + year={1964}, 93 + publisher={McGraw-Hill}, 94 + address={New York} 95 + } 96 + 97 + @book{nelson1974computerlib, 98 + title={Computer Lib / Dream Machines}, 99 + author={Nelson, Theodor H.}, 100 + year={1974}, 101 + publisher={Self-published}, 102 + note={Revised edition, Microsoft Press, 1987} 103 + } 104 + 105 + @book{illich1973tools, 106 + title={Tools for Conviviality}, 107 + author={Illich, Ivan}, 108 + year={1973}, 109 + publisher={Harper \& Row}, 110 + address={New York} 111 + } 112 + 113 + @book{papert1980mindstorms, 114 + title={Mindstorms: Children, Computers, and Powerful Ideas}, 115 + author={Papert, Seymour}, 116 + year={1980}, 117 + publisher={Basic Books}, 118 + address={New York} 119 + } 120 + 121 + @article{ukeles1969manifesto, 122 + title={Manifesto for Maintenance Art 1969!}, 123 + author={Ukeles, Mierle Laderman}, 124 + year={1969}, 125 + note={Proposal for an exhibition ``Care''} 126 + } 127 + 128 + @book{negroponte1995being, 129 + title={Being Digital}, 130 + author={Negroponte, Nicholas}, 131 + year={1995}, 132 + publisher={Alfred A. Knopf}, 133 + address={New York} 134 + } 135 + 136 + @book{attali1985noise, 137 + title={Noise: The Political Economy of Music}, 138 + author={Attali, Jacques}, 139 + year={1985}, 140 + publisher={University of Minnesota Press}, 141 + address={Minneapolis}, 142 + note={Originally published in French, 1977} 143 + } 144 + 145 + @book{brand1994long, 146 + title={How Buildings Learn: What Happens After They're Built}, 147 + author={Brand, Stewart}, 148 + year={1994}, 149 + publisher={Viking Press}, 150 + address={New York} 151 + } 152 + 153 + @book{sennett2008craftsman, 154 + title={The Craftsman}, 155 + author={Sennett, Richard}, 156 + year={2008}, 157 + publisher={Yale University Press}, 158 + address={New Haven} 159 + } 160 + 161 + @book{ingold2013making, 162 + title={Making: Anthropology, Archaeology, Art and Architecture}, 163 + author={Ingold, Tim}, 164 + year={2013}, 165 + publisher={Routledge}, 166 + address={London} 167 + } 168 + 169 + @article{trueman2006plork, 170 + title={PLOrk: The Princeton Laptop Orchestra, Year 1}, 171 + author={Trueman, Dan and Cook, Perry and Smallwood, Scott and Wang, Ge}, 172 + booktitle={Proceedings of the International Computer Music Conference}, 173 + year={2006} 174 + } 175 + 176 + @book{turino2008music, 177 + title={Music as Social Life: The Politics of Participation}, 178 + author={Turino, Thomas}, 179 + year={2008}, 180 + publisher={University of Chicago Press}, 181 + address={Chicago} 182 + } 183 + 184 + @book{winner1986whale, 185 + title={The Whale and the Reactor: A Search for Limits in an Age of High Technology}, 186 + author={Winner, Langdon}, 187 + year={1986}, 188 + publisher={University of Chicago Press}, 189 + address={Chicago} 190 + } 191 + 192 + @article{fisher2009capitalist, 193 + title={Capitalist Realism: Is There No Alternative?}, 194 + author={Fisher, Mark}, 195 + year={2009}, 196 + publisher={Zero Books}, 197 + address={Winchester} 198 + } 199 + 200 + @book{langer1953feeling, 201 + title={Feeling and Form: A Theory of Art}, 202 + author={Langer, Susanne K.}, 203 + year={1953}, 204 + publisher={Charles Scribner's Sons}, 205 + address={New York} 206 + } 207 + 208 + @book{shklovsky1917art, 209 + title={Art as Technique}, 210 + author={Shklovsky, Viktor}, 211 + year={1917}, 212 + note={In \emph{Russian Formalist Criticism: Four Essays}, trans. Lee T. Lemon and Marion J. Reis, University of Nebraska Press, 1965} 213 + } 214 + 215 + @misc{bellard2019quickjs, 216 + title={QuickJS JavaScript Engine}, 217 + author={Bellard, Fabrice}, 218 + year={2019}, 219 + url={https://bellard.org/quickjs/}, 220 + note={A small and embeddable JavaScript engine} 221 + } 222 + 223 + @inproceedings{aaron2016sonic, 224 + title={Sonic Pi -- Performance in Education, Technology and Art}, 225 + author={Aaron, Samuel}, 226 + booktitle={Proceedings of the International Conference on Live Coding}, 227 + year={2016} 228 + } 229 + 230 + @book{haraway2016staying, 231 + title={Staying with the Trouble: Making Kin in the Chthulucene}, 232 + author={Haraway, Donna J.}, 233 + year={2016}, 234 + publisher={Duke University Press}, 235 + address={Durham} 236 + } 237 + 238 + @misc{ewaste2024monitor, 239 + title={The Global E-waste Monitor 2024}, 240 + author={{United Nations Institute for Training and Research (UNITAR)}}, 241 + year={2024}, 242 + url={https://ewastemonitor.info/} 243 + } 244 + 245 + @misc{scudder2026archaeology, 246 + title={Repository Archaeology: Tracing Aesthetic Computer Through 94 Predecessor Projects}, 247 + author={{@jeffrey}}, 248 + year={2026}, 249 + note={Companion paper on the project's software lineage} 250 + } 251 + 252 + @misc{scudder2026goodiepal, 253 + title={Five Goodiepalian Threads Through Aesthetic Computer}, 254 + author={{@jeffrey}}, 255 + year={2026}, 256 + note={Companion paper on Goodiepal's influence on AC's design philosophy} 257 + } 258 + 259 + @article{sutherland1968head, 260 + title={A Head-Mounted Three Dimensional Display}, 261 + author={Sutherland, Ivan E.}, 262 + journal={Proceedings of the AFIPS Fall Joint Computer Conference}, 263 + volume={33}, 264 + pages={757--764}, 265 + year={1968} 266 + }

+100

reports/2026-03-20-hda-capture-eio-investigation.md

··· 1 + # HDA Capture EIO Investigation — 2026-03-20 2 + 3 + ## Summary 4 + 5 + Mic sampling in ac-native (notepat sampler) stopped working after kernel config 6 + changes made between March 10-18. Capture device `hw:0,0` opens and configures 7 + but `snd_pcm_readi` returns EIO (Input/output error) on the first read. No audio 8 + data is ever captured. 9 + 10 + ## Machine 11 + 12 + - ThinkPad X13 Gen 1 (Kaby Lake, `0x8086:0x9d71` HDA controller) 13 + - Realtek codec on HDA Intel PCH (card 0) 14 + - ALSA devices: `pcmC0D0p` (playback), `pcmC0D0c` (capture), `pcmC0D3p` (HDMI) 15 + - Playback works fine throughout — only capture is broken 16 + 17 + ## Timeline 18 + 19 + | Date | Commit | What happened | 20 + |------|--------|---------------| 21 + | Mar 10 | `3c083a1f9` | Mic sampling introduced — **working** | 22 + | Mar 10-13 | various | Sampling refined, looping added — **working** | 23 + | Mar 17 | `8e8894f17` | `CONFIG_INTEL_IOMMU=y` added | 24 + | Mar 18 | `de64cf00c` | `CONFIG_SND_HDA_I915` disabled | 25 + | Mar 18 | `a046beabd` | `CONFIG_SND_SOC_SOF_*` added | 26 + | Mar 19-20 | various | Capture broken — EIO on `snd_pcm_readi` | 27 + 28 + ## What was tried (and failed) 29 + 30 + 1. **Device order** — switched from `plughw:0,0` back to `hw:0,0` first. No effect (EIO persists). 31 + 2. **Period/buffer tuning** — tried period=128/buf=512 (hung forever), ALSA defaults period=32768/buf=1M (hung forever), period=1024/buf=8192 (EIO). 32 + 3. **ALSA mixer setup** — enabled Capture Switch, set Capture Volume to 90%, enabled Internal Mic Boost. Mixer reports success but EIO persists. 33 + 4. **`intel_iommu=off`** on CMDLINE — no effect. 34 + 5. **Removed `CONFIG_SND_SOC_SOF_*`** — no effect. 35 + 6. **Removed `CONFIG_SND_SOC_SOF_*` AND restored `CONFIG_SND_HDA_I915=y`** — not tested in isolation. 36 + 37 + ## Root cause (probable) 38 + 39 + Unknown which specific config change causes the EIO. Multiple kernel config 40 + additions between March 10-18 changed the HDA driver environment: 41 + 42 + - `CONFIG_INTEL_IOMMU=y` — changes DMA mapping for all PCI devices 43 + - `CONFIG_SND_HDA_I915` disabled — changes HDA power domain management 44 + - `CONFIG_SND_SOC_SOF_HDA=y` — registers alternative HDA driver 45 + - `CONFIG_ZRAM=y`, `CONFIG_BPF_SYSCALL=y`, `CONFIG_NAMESPACES=y`, etc. — general kernel bloat 46 + 47 + These interact in complex ways with the HDA controller. Rather than bisecting 48 + individual options, the fix restores the exact working kernel config from 49 + `3c083a1f9` with minimal CMDLINE additions preserved. 50 + 51 + ## Fix applied 52 + 53 + Commit `2233325de` restores the kernel config from `3c083a1f9` (last known 54 + working state for capture). Preserved from the current config: 55 + 56 + - `snd_hda_intel.power_save=0` — prevents codec suspend between uses 57 + - `i8042.reset i8042.nomux` — keyboard reliability 58 + - `loglevel=4` — debug visibility (was `quiet loglevel=0`) 59 + - `CONFIG_CMDLINE_OVERRIDE` disabled — allows bootloader param overrides 60 + 61 + ## Features lost by reverting 62 + 63 + The following were added post-March-10 and are now removed: 64 + 65 + | Feature | Config | Impact | 66 + |---------|--------|--------| 67 + | Intel IOMMU | `INTEL_IOMMU=y` | DMA isolation — not needed on single-user bare metal | 68 + | SOF audio | `SND_SOC_SOF_*` | Needed for Alder/Meteor Lake, not Kaby Lake | 69 + | SATA/AHCI | `ATA=y, SATA_AHCI=y` | Internal disk access — only needed for install-to-disk | 70 + | Camera/UVC | `USB_VIDEO_CLASS=y` | Webcam support | 71 + | Intel Xe GPU | `DRM_XE=y` | Meteor Lake GPU — not needed on Kaby Lake | 72 + | Dell drivers | `DELL_LAPTOP=y` etc. | Dell keyboard/WMI support | 73 + | Realtek WiFi | `RTW88=y, RTW89=y` | WiFi on Realtek-based laptops | 74 + | MediaTek WiFi | `MT76=y` etc. | WiFi on MediaTek-based laptops | 75 + | USB-C TypeC | `TYPEC=y, UCSI=y` | USB-C power role swap | 76 + | zram swap | `ZRAM=y` | Compressed swap | 77 + | BPF | `BPF_SYSCALL=y` | eBPF programs | 78 + | Namespaces | `NAMESPACES=y` | Container isolation | 79 + | debugfs | `DEBUG_FS=y` | Kernel debug filesystem | 80 + | Touchscreen | `HID_MULTITOUCH=y` | Multi-touch input | 81 + | USB printer | `USB_PRINTER=y` | Thermal printer support | 82 + | SD card | `MMC=y` | SD/MMC card reader | 83 + 84 + ## Follow-up needed 85 + 86 + 1. **Test the reverted kernel** — confirm capture works again 87 + 2. **Bisect the configs** — re-add features one at a time to find the exact 88 + culprit. Priority suspects: `INTEL_IOMMU`, `SND_HDA_I915` disable, `SOF_HDA` 89 + 3. **Re-add needed features** — SATA (install-to-disk), zram, Realtek/MediaTek 90 + WiFi should be restored once the capture-breaking option is identified 91 + 4. **Consider per-machine kernel configs** — Kaby Lake ThinkPad vs Meteor Lake 92 + laptop have different driver needs 93 + 94 + ## Related crashes fixed in this session 95 + 96 + 1. **Division by zero** (`3568275b5`) — `sample_len=0` caused SIGFPE in audio 97 + thread modulo operations. Fixed with `if (slen <= 0)` guard. 98 + 2. **Batched event race** (`6aa5f0f84`) — all key events processed in single 99 + frame, recording start/stop had zero time between them. Fixed with spin-wait 100 + in `audio_mic_stop` for ring buffer data.

Configure Feed

Configure Feed