alex nodeland

StatusBar: Is It Down, or Is It Me?

Sun, 13 Sep 2026 00:00:00 GMT

i depend on a lot of things i don't run. anthropic, github, cloudflare, whatever is underneath the thing i am shipping that afternoon. so when something misbehaves the first question is never "what's the bug". it is "is it me, or is it them", and answering it used to mean opening five status pages that each say "operational" a different way.

statusbar is my answer to that. it lives in the menu bar, watches the pages i care about, and shows me the worst one at a glance.

the thing that actually started it: no two providers agree on how to say "broken". atlassian statuspage says "degraded performance", incident.io has its own words, gatus just tells you an endpoint is down. i didn't want to keep five of these straight, so the app maps all of them onto four levels: operational, degraded, partial outage, major outage. the icon shows the worst one across everything i watch. green means i don't think about it. anything else means i open the popover. adding a source is pasting a url, and it detects the provider from that.

i wanted the status in the terminal too, where i already am, so there is a cli that caches it on every poll and reading it costs nothing:

statusbar wait npm && npm publish

wait blocks until a service comes back, so i can hang a deploy off it instead of refreshing a page. prompt prints a glyph i drop into starship or tmux, and a .statusbar file in a repo narrows both down to just that project's upstreams. there is a widget, webhooks into slack, discord and teams, shortcuts, and an applescript dictionary.

native swiftui, macos 26 and up. no electron, no dock icon, no telemetry. it talks to the status pages you add and nowhere else. free and open source.

incident detail is only as good as the provider hands over. statuspage gives full timelines; incident.io and instatus expose less through their apis; gatus has no incident history at all and reports per-endpoint health instead. and it is macos-only.

view on github · project site · support it · brew tap alexnodeland/tap && brew install --cask statusbar

The Chat Box Is a Language Model on Your Machine

Sun, 26 Jul 2026 00:00:00 GMT

there is a chat box on this site. when you open it, your browser downloads a 760mb language model and runs it on your gpu. nothing is sent anywhere, because there is no server to send it to. it answers questions about me from the pages you are already reading.

this is how it works, and what the numbers look like.

the shape of it

the first version put my entire cv, about 4,500 tokens, in front of every question. it also ran two throwaway yes/no generations before each answer, to decide whether the question was on-topic at all. three model calls per question, and it knew nothing about the blog or the projects page.

now the site is chunked into 95 passages at build time and embedded into a 111kb file that ships with the page. your browser embeds only your question, one forward pass over about fifteen tokens and roughly two milliseconds, then searches that index.

the search is hybrid, and it needs to be. this corpus is one person's life, so everything in it is semantically adjacent to everything else; a 384-dimension vector cannot reliably separate "musiio" from "influize". exact term matching carries the proper nouns, embeddings carry the paraphrases ("where did he go to school"), and reciprocal rank fusion combines them without needing the two score scales to be comparable, which they are not.

then there is a gate. if nothing in the index is close enough to the question, there is nothing to ground an answer in, so it says so, in about a tenth of a second and without running the model. that gate replaced both classifier calls and is more accurate than they were. three generations per turn became one.

what reaches the model is a short instruction block, the passages that came back, and your question. it cites what it used, and those citations become links under the answer.

what it costs


download, once	760mb, cached after
cold load	~21s
search	~26ms
reading the prompt	~830ms
writing the answer	~540ms
a refused question	~0.1s

prefill dominates decode here, about 2:1. tokens per second is the number usually quoted for these models, and for a grounded chat it is the smaller cost.

the cache

the instruction block is identical on every turn, so it is run through the model once at load and its key-value cache is reused. that is worth about 420ms a turn, a quarter of the total.

the cached part was 975 tokens and stayed 975 tokens no matter how long the conversation ran, so the share of each prompt it covered went down as you talked, from 55% to 51%. a cache that stops growing matters less the longer the conversation runs.

a cache can only skip a prefix that matches token for token, so what it can cover is decided by the order the prompt is assembled in. more of the prompt is fixed than it first appears: earlier questions have their retrieved passages stripped out, and earlier answers have their citation markers removed, and both of those edits happen exactly once, when a turn stops being the current one. after that the history is frozen, so it can all be carried forward, and the cached region grows by one exchange per turn instead of standing still. seven turns in it covers 1,290 tokens rather than 975, and the conversation is prefilling about a quarter fewer tokens than it was.

two other arrangements measure worse. keeping every turn's passages in the prompt caches the most, but spends the savings carrying stale context, which is what used to make it answer turn four out of turn one's passages. pinning the passages to a fixed position so a repeated search matches came out no better than doing nothing, because retrieval has to return the same set in the same order for that to pay, which is rare in practice.

model selection

smaller is not faster. a model with half the parameters ran two to four times slower, because it wrote several hundred words where the larger one writes forty. decoding cost is per token, so verbosity dominates parameter count.

the fast one fabricates. a 230m model loads in nine seconds instead of twenty-one and answers in under a second, but asked whether i know a language that appears nowhere in my skills list, with that list in its context, it says yes. asked whether i worked at a company i never worked at, it says yes to that too. few-shot examples showing it declining exactly that kind of question, two hundred tokens above the point of use, did not change the behavior. at this size the model accepts the premise of whatever it is asked.

the same examples degraded the larger model. one of them mentioned musiio, and that was enough for musiio to start appearing in unrelated answers.

reasoning does not help. the step-by-step variant of the same model scored worse in every category and took four times as long, spending 658 tokens reasoning before the visitor saw a word. reading four retrieved passages is not a reasoning problem. the answer is already in the context.

so the lineup is one model.

the evals

there is a graded battery of 68 questions covering grounded lookups, multi-passage synthesis, follow-ups that depend on the previous turn, questions built on false premises, things that must be refused, and things that must not be refused.

the first version of the battery had twelve cases and the model passed all of them, which made it useless for comparing versions. a saturated test can only show that something broke.

expanding it exposed a class of failure the small set never touched: false premises. asked where i got my mba (i don't have one), the model reported a doctorate i never finished. asked how old i am, it worked it out from my job dates and offered "early thirties." asked why i left a company, it invented a motive and hedged it with "probably."

it currently scores 55/68. the remaining failures are dates it gets wrong, gibberish it answers instead of refusing, and a couple of roleplay prompts that talk it out of its job. each case is scored on a scale rather than pass/fail, with a note on every lost point.

what it still gets wrong

ask it "archanan?", just the word, and it recites where that company sits in my timeline instead of telling you what it was. the answer is coming from the career summary that sits in every prompt, and suppressing it breaks the follow-up questions the summary is there to serve.

if your browser has no webgpu, it does not work at all, and it says so. it can't fall back to your cpu, and the reason is narrower than "too slow", though it is also too slow. every compressed version of this model stores its vocabulary in a format the cpu engine cannot read. the gpu engine can, which is why one works and the other does not. a faster cpu engine would not fix it either: the best one available runs a model this size at two to five words a second.

it also will not tell you anything that is not on this site, which is most things. that is by design. it can tell you where i worked and what i have built. it cannot tell you what i think about your architecture. for that, email me.

What Is Running Behind This Page

Sun, 28 Sep 2025 00:00:00 GMT

the backgrounds on this site are simulations, not video loops. every one is computed per frame in your browser. the landscape icon in the corner opens a panel with the parameters for whichever is on screen, and they cycle every twelve seconds unless you turn that off.

six of them, in cycle order:

background	what it is
cellular automaton	conway's life, plus five other b/s rules
simple waves	three summed sine waves
job scheduling	simulated annealing over a clustered graph
dual fm oscillator	a working fm synth, oscilloscope and spectrogram
shortest path	dijkstra, a*, and greedy search, side by side
pde solver	finite-difference heat and wave equations

cellular automaton

a grid of cells, a rule, and a state buffer stepped one generation at a time. each cell counts its eight neighbors on a wrapping torus, then lives, dies, or is born according to the rule, which is conway's b3/s23 by default, with highlife, maze, coral, day & night and seeds in the dropdown.

the shader only draws; the rule runs on a real buffer. newborn cells take the newborn color and shift toward the established color the longer they survive, and links are drawn between live neighbors, the same eight-cell neighborhood the rule is evaluated over.

random soup under conway settles into still lifes and period-two oscillators within a couple of hundred generations, which is too static for a background. perturbation rate flips a small fraction of cells each step to keep things moving. set it to zero to watch it stall.

simple waves

three sine waves summed in a shader. one runs along x, one along y at 0.8× the frequency, one diagonally at 0.6×, each drifting at a different rate. color maps amplitude: bright where they reinforce, dark where they cancel.

it is nothing but superposition. interference is the mechanism behind a great deal of signal processing, and it takes three lines of arithmetic. i spent a couple of years on wavelet bases for audio compression at stony brook, and what stayed with me is how little machinery the underlying physics needs.

turn wave frequency up and wave speed down to freeze the interference pattern in place.

job scheduling

the most interesting one, and the worst named.

it builds a clustered graph: nodes grouped into tight clusters with dense, high-bandwidth links inside each cluster and sparse, high-latency links between them. roughly the shape of a real datacenter. then it searches for the subgraph of size n with the highest total conductivity, the best-connected group of that size.

that search is simulated annealing with an exponential cooling schedule. it proposes a swap, accepts it outright if it scores better, and accepts it with a temperature-dependent probability if it scores worse. early on, while it is hot, it takes bad trades freely and wanders. as the temperature drops it stops accepting losses and settles. the two highlight colors are separate things: one is the candidate set it is considering right now, the other is the best set it has found so far. early on they diverge constantly. near the end they lock together.

the layout is force-directed and running at the same time, so the graph is still settling while the search runs over it.

set number of clusters to 2 and requested subgraph size to something close to one cluster's worth of nodes, then watch how long it takes to commit to one side.

dual fm oscillator

a working synthesizer. two oscillators, one modulating the other's phase. that is all fm synthesis is, and it is how a dx7 could make a bell out of two sine waves when a subtractive synth needed a filter bank. the signal then runs through filter, delay, distortion and reverb.

top display is an oscilloscope: amplitude against time. bottom is a spectrogram: frequency low-to-high, scrolling left-to-right, brightness as intensity. every bin is a hann-windowed discrete fourier transform of the same samples the oscilloscope is drawing, so the sidebands, the harmonic series of a square wave, and the sum and difference tones from the ring modulator are all measured rather than drawn. seeing one signal in both domains at once shows what fm does to a spectrum.

push vco 1 fm amount up slowly and watch the sidebands appear in pairs either side of the carrier, spaced at the modulator frequency.

it makes sound. hold the speaker button in the settings panel.

i built synthesizers as artist in residence at cewit for a year, mostly analog.

shortest path

seeded random graph, real priority frontier, and one slider that changes which algorithm you are running.

heuristic weight scales the heuristic term in f = g + w·h:

w = 0: the heuristic vanishes and it is dijkstra. explores outward in every direction equally. always finds the optimal path, looks at far more of the graph than it needed to.
w = 1: a*. the heuristic is admissible, so the path is still optimal, but exploration stretches toward the goal instead of spreading evenly.
w > 1: greedy. it over-trusts the heuristic, drives almost straight at the goal, and gives up the optimality guarantee to do it.

watch the shape of the explored region: a circle, then an ellipse, then a corridor. that is the optimality-versus-effort tradeoff drawn as a shape, and it is why i kept this one in the rotation.

turn steps per second down to about 5 to watch the frontier expand node by node.

pde solver

explicit finite differences on a grid, solving either the heat equation ∂u/∂t = α∇²u or the wave equation ∂²u/∂t² = c²∇²u. the laplacian is a five-point stencil; heat uses forward-time centered-space, wave uses a centered second difference in time. grid runs at 64², 128² or 256².

the parameters that change the physics rather than the look are boundary condition and initial condition. dirichlet fixes the edge value, so waves reflect inverted. neumann sets the edge derivative to zero, so they reflect upright. periodic wraps, so anything leaving the right edge arrives at the left. pick a gaussian pulse on the wave equation and switch between the three. the difference in reflection is immediate. it is the clearest demonstration of boundary conditions i know of.

you cannot make it explode. explicit schemes are only conditionally stable. heat needs α·dt·(1/dx² + 1/dy²) ≤ 0.5 and wave needs the cfl condition c·dt·√(1/dx² + 1/dy²) ≤ 1, so the timestep is clamped to the stable maximum before every step. push thermal diffusivity to its limit and the simulation slows down rather than diverging.

on the whole thing

they render to webgl or canvas depending on the background, pause when the tab is hidden, and cycle on a twelve-second timer with a 1.2-second crossfade. every parameter you change is live.

why they exist: a static background is a wasted surface, and i wanted somewhere to put the numerical methods i do not get to write at work.

Fugue: Monadic Probabilistic Programming for Rust

Tue, 19 Aug 2025 00:00:00 GMT

a probabilistic programming library for rust, built around a monad.

a model in fugue is a Model<T> value that you compose in direct style with bind and map. what that composition means is decided later, by the interpreter you hand it to: sample from the prior, replay a trace, score it, or run mcmc, hmc, smc, variational inference or abc over it. separating the model from the inference is the main idea. in most probabilistic languages the algorithm is entangled with how you declare the model, so trying a different sampler means rewriting the thing you were trying to hold constant.

the distributions are typed with their natural return types. bernoulli gives you a bool, poisson and binomial give you u64, categorical gives you a usize, rather than everything collapsing to f64 and being cast back at the point of use, which is where the off-by-one bugs come from. seventeen distributions, all with validated parameters, and log-space arithmetic throughout so that multiplying a few thousand small probabilities does not quietly become zero.

there are macros for do-notation (prob!) and vectorization (plate!), because monadic code in rust is unreadable without them.

it is 0.2.x: pre-1.0, no semver guarantees yet, one primary maintainer. extensively tested, including property-based tests and statistical regressions against closed-form posteriors, but that is not the same as production-ready. pin an exact version and read the changelog before upgrading.

view on github · learn it interactively at fugue.run

Finance Crew: AI-Powered Financial Analysis

Fri, 09 Aug 2024 00:00:00 GMT

a crewai system for market analysis: agents that pull financial data, work a strategy up against it, and assess the risk of running it.

the useful idea is the separation between the agent that proposes and the agent that assesses. a system that only proposes always sounds confident, because a fluent argument for a trade and a good trade come out of the same machinery. giving risk assessment its own step, with its own context and no stake in the proposal, is a cheap correction for that.

it is a study in multi-agent design, not financial advice, and i would treat any number it produces as a prompt for your own analysis rather than a conclusion.

view on github

Vanilla ReAct: Minimalist Agent Framework

Tue, 09 Jul 2024 00:00:00 GMT

a react agent in python with no framework underneath it, written when every agent library was adding abstraction faster than i could read it.

react is a small idea. the model reasons about what to do, takes an action, observes the result, and repeats until it decides it is finished. that is a loop, a prompt template, and a way to dispatch tool calls, and it fits on a page against the openai api.

the repository is that page, kept readable. it is not competing with the frameworks; it is meant to be read first, so that when you adopt one you can tell which parts solve your problem and which parts solve the framework's. a lot of what gets called an agent is this loop with retries and logging around it.

view on github

Crewlit: Multi-Agent AI Systems in Your Browser

Sat, 06 Jul 2024 00:00:00 GMT

crewai in a browser, so that building a multi-agent system does not have to start with a python file.

it is a streamlit app for defining agents, tasks and crews, wiring them together, and running them with the output streaming back as it happens. you can do all of it from a script. what the app removes is the hour of boilerplate between understanding what a multi-agent system is and having one running.

a crew is a graph of agents with dependencies, and most people's first instinct is to build it as a list. the ui mostly exists to make the graph visible before you run it.

view on github

Resume Crew: AI-Powered Career Tools

Sun, 30 Jun 2024 00:00:00 GMT

a crewai system that tailors a resume to a specific job posting, then prepares you for the interview that follows.

the agents split the work rather than sharing it. one reads the posting and separates the real requirements from the boilerplate. one rewrites the resume against that reading. one generates the questions you should expect given the gap between the two.

the separation is why it works better than one long prompt. critiquing a resume and rewriting it are different jobs, and a model asked to do both at once tends to soften the critique to fit the rewrite. splitting them means the criticism gets written down before anything acts on it.

view on github

Musiio Acquired by SoundCloud

Tue, 03 May 2022 00:00:00 GMT

on 3 may 2022 soundcloud acquired musiio. i was in the office the day the papers were signed.

musiio's ai listens to music, which is harder than it sounds: audio reference search, automated tagging, playlisting, aimed at catalogues holding more tracks than any person will ever get through. hazel savage and aron pettersson founded it in june 2018, out of entrepreneur first's third singapore cohort, the same cohort archanan came out of, pitching at the same investor day. i had been tech lead there for about a year when the deal closed.

hazel six months later, on the music notes stage at web summit, billed as vp of music intelligence at musiio by soundcloud. photo by ben mcshane / web summit via sportsfile, cc by 2.0.

hazel and aron went across as vp of music intelligence and vp of ai and machine learning, and soundcloud kept the team on. i went over to the soundcloud office in the states as incoming director of engineering for music intelligence. four years from a desk in a cohort room to this. congratulations to hazel, to aron, and to everyone who built it.

the team's next move was berlin. i decided not to go, and left in november.

soundcloud's announcement · soundcloud · musiio, while it was still musiio (the domain points at soundcloud now)

QCSim: Quantum Circuit Simulator in Python

Mon, 17 Aug 2020 00:00:00 GMT

a quantum circuit simulator in python, written to understand the subject rather than to be fast at it.

it implements the fundamental gates and lets you assemble and run circuits, which is enough to build up the standard algorithms and watch the state vector do what the textbook says it does. simulating a quantum circuit is linear algebra on a vector of 2^n amplitudes, where gates are unitary matrices and measurement is sampling from the squared magnitudes, and there is not much more to it than that.

the 2^n is also why simulation is no substitute for hardware: thirty qubits is a billion amplitudes.

view on github

Try Before You Buy? Test Driving a Supercomputer System

Mon, 07 Oct 2019 00:00:00 GMT

a follow-up piece for hpcwire, this one about procurement rather than development.

buying a supercomputer means committing tens of millions to a configuration chosen largely from benchmarks that are not your workload. get it wrong in one direction and you have paid for capability that sits idle; get it wrong in the other and the machine is saturated the month it arrives. the usual mitigations are vendor benchmarks, reference customers, a proof of concept on last generation's hardware, and none of them tell you how your own codes will behave on this machine.

emulating the system first turns that into an empirical question. run the real applications against a digital twin of the proposed configuration and find out whether you are short on interconnect bandwidth or on node count, before the purchase order rather than after. that helps the vendor as much as the buyer: most of the risk in a deal that size is a customer discovering eighteen months later that they bought the wrong shape of machine, and unhappy reference customers are expensive.

read the full article

Singapore Startup Hatches At-Scale HPC Dev Cloud

Fri, 26 Apr 2019 00:00:00 GMT

hpcwire covered our beta launch, the first detailed account of what archanan did.

the problem we were built around: most supercomputing centers allocate ten percent or less of the machine to development work. if your production run needs thirty thousand cores, you are writing and debugging that code somewhere much smaller and hoping. plenty of organizations have no on-premise cycles for development at all, and anyone evaluating an architecture they do not own yet has nowhere to try it.

what we sold was a functional replica. you develop against an emulation of your target machine's topology and interconnect, at the core count you will actually run on, through a web ide with a parallel debugger attached. it is explicitly not a performance model, since the layers of virtualization mean the timings are not the production timings, but it answers the question that burns allocation: does the code run at scale at all, and how does mpi behave when it does. at launch you could target emulated systems including nscc singapore's aspire-1, or specify a machine that did not exist yet.

lukasz orlowski and i founded it in february 2018, raised a seed round led by sginnovate, and had john gustafson, of gustafson's law, as lead scientific advisor.

read the full article

Supercomputing Shouldn't Be Rocket Science

Fri, 01 Mar 2019 00:00:00 GMT

a piece for asian scientist, written while running archanan, arguing that the hard part of supercomputing is not the computing.

picture a researcher with a simulation that works on their laptop and an allocation on a national machine. between those two things sits weeks of work that has nothing to do with their science: mpi topologies, schedulers, queue etiquette, and the first genuinely large run is usually also the first time anyone finds out whether the code scales. that run is expensive, and when it fails it usually fails for a reason that has nothing to do with the physics.

the argument is that this gap is an engineering problem, not a fact of nature, and that treating it as a rite of passage keeps the field closed to anyone who does not already know the folklore. domain scientists should be able to spend their allocation on science, not on discovering that their halo exchange deadlocks above four thousand ranks.

read the full article

Archanan in Ho Chi Minh City

Sat, 15 Dec 2018 00:00:00 GMT

archanan opened an office in ho chi minh city in december 2018, five months after the investor day, and after a few other spots settled at the hive in thảo điền.

we built the team out to five engineers. every month i flew down and worked from the office with them rather than managing it from singapore, and that held until covid closed the borders.

ho chi minh city from across the saigon river. photo by pimnl, cc0.

Archanan at EF Singapore Investor Day

Tue, 24 Jul 2018 00:00:00 GMT

entrepreneur first runs its singapore program in cohorts, and each one ends with an investor day. twenty-three companies pitched at the end of efsg3 on 17 july 2018, all of them built from scratch since the cohort opened in january. this is the three minutes archanan got.

backstage, waiting to go on. photo by entrepreneur first.

supercomputers solve problems that nothing else can, from aircraft design to the behavior of a single cell, and almost nobody can use them. what stops people is the development loop. you book a slot on the machine months ahead, write your code on a laptop while you wait, and find out on the day that it does not run at scale. the only place to develop code for a supercomputer is on a supercomputer, and leaving one switched on costs tens of thousands of dollars a day.

so we proposed a machine in the cloud that looks and behaves like the one you are targeting, at a tenth of the cost, with the tools built for it and nothing to install beyond a browser. by then that meant pilots with research groups in singapore, a deal in progress with a supercomputing center, and john gustafson advising.

watch the pitch · ef's photos from the day

Moving to Singapore

Fri, 12 Jan 2018 00:00:00 GMT

i moved to singapore on 12 january 2018, before entrepreneur first's third singapore cohort opened.

two people are why. łukasz orłowski, who i met at stony brook and worked with at scala, and who was joining the same cohort. and my friend martin sawtell, who had been through the second cohort himself, and before that spent a decade at lucasfilm doing visual effects, on the dynamics and rendering side. martin had done it himself before recommending it.

singapore was also where the machines were. i had been talking with people at nscc for a while by then, and moving there did not end that relationship so much as put it in the same time zone. one-north held a*star's institute of high performance computing and its computational resource centre too. research groups there gave letters of intent, and nscc's aspire 1 became a machine archanan modeled. six months later łukasz and i were pitching archanan.

fusionopolis, at one-north, where a*star's institute of high performance computing and computational resource centre were. photo by yeowatzup, cc by 2.0.

entrepreneur first · nscc singapore

Grand Central Tech

Tue, 01 Aug 2017 00:00:00 GMT

scala got into grand central tech in august 2017, and the company moved from the office at cewit to 335 madison avenue, third floor, across the street from grand central terminal.

we went from seven people to fifteen.

335 madison avenue, from across 42nd street. photo by jim henderson, cc by 3.0.

the product had moved as well. it started as spare office machines linked into a grid; by that summer the pitch was the job scheduler module, which used spectral graph theory to decide how work was distributed across a cluster, and it was being sold against public clouds, private clouds and bare metal.

we also did work for new york city's department of environmental protection.

grand central tech, as it looked then · scala computing, as it looked that summer

Leaving the PhD

Mon, 15 May 2017 00:00:00 GMT

i left the computational applied mathematics phd at stony brook in may 2017, a little over a year after starting a company out of it.

yuefan deng was my advisor. the research i was there for was optimal wavelet bases for audio compression, but he kept pointing me at a different problem: take what you know about graph theory and aim it at networks. resource allocation. task management in job scheduling.

the interconnect topology can be modeled as a graph. in a distributed system the connectivity and latency between nodes are not uniform, and job sizes and durations keep changing, so the scheduler is balancing fairness, dynamicity and utilization all at once, while trying to place jobs on high-conductance subgraphs of the network, which matters most when the workload is network-intensive.

yuefan deng advised arjun kapoor and me on starting it. scala computing, march 2016, in an office at cewit across the hall from the one i had as artist in residence. satya sharma was cewit's director and an advisor to the company as well. we grew to seven people in that room.

cewit, in stony brook's research and development park. photo by john feinberg, cc by 2.0.

what it sold at the start was grid-style clusters on commodity office hardware: the spare capacity already sitting in a building, linked into something that could take work no single machine there could. later it grew into clusters on any distributed set of machines, on-prem, in the cloud, or across the web.

i left before advancing to candidacy. i wanted to build it rather than publish about it.

leaving the program did not mean leaving the building. the residency and the research post both ran on through the year.

scala computing, as it looked in 2017 · cewit

Wavelet Talk at IACS

Wed, 07 Dec 2016 00:00:00 GMT

on 7 december 2016 the institute for advanced computational science at stony brook had me in to talk about the wavelet work, under the title the research already carried: optimal wavelet bases for audio compression.

iacs was where the search had been running.

the listing · the research behind it

InfiniCortex

Mon, 14 Nov 2016 00:00:00 GMT

infiniband is the interconnect inside a supercomputer: short range, one subnet, the fabric a machine uses to talk to itself. infinicortex was a*star's attempt to stretch it across oceans, using range extenders over optical fibre and routing separate subnets into one another, so that machines in singapore, australia, europe and north america could be driven as a single system. what circled the planet was a supercomputer's own internal network rather than a network between supercomputers.

an infiniband switch and the short copper that normally plugs into it. photo by chrisdag, cc by 2.0.

marek michalewicz, who ran a*star's computational resource centre, gave the talk on it at iacs on 27 august 2015. stony brook became one of the sites on the fabric.

that meant dealing with obsidian directly to get the longbow and crossbow units to us on loan. i took delivery myself and carried the package over to the iacs supercomputing center to be installed.

in november 2016 i went to sc16 in salt lake city on an iacs travel award, for the unveiling of stony brook's addition to the network. the fabric ran as four subnets that year and stony brook was one of them, with five longbow units tying the show floor back to a*crc in singapore at fifty gigabits.

infinicortex, from proof-of-concept to production · iacs

Optimal Wavelet Bases For Audio Compression

Tue, 01 Nov 2016 00:00:00 GMT

jpeg 2000 swapped the discrete cosine transform for wavelets and got visibly better images at the same bitrate, with none of the block artifacts that give away ordinary jpeg. the obvious question is why the same move is not standard for audio.

part of the answer is that nobody agrees on which wavelet to use. unlike the dct, which is one fixed transform, "wavelet" is a family, and the right member depends on the signal you are compressing. in practice people pick one that has worked before and tune around it.

this research was an attempt at a procedure for picking the basis for a given class of audio, instead of choosing by taste: define what optimal means for that class, then search the space of admissible bases against a real corpus. the search needed the iacs supercomputers. the criterion needed the mathematics.

read the full article, inside the november 2016 newsletter pdf.

All Shook Up at CK Productions

Sat, 25 Jun 2016 00:00:00 GMT

all shook up ran at town hall west in islip for two weeks in the summer of 2016, and i played guitar in a band led by zack aretakis.

it is a jukebox musical built on the elvis presley catalog, and the book underneath it, by joe dipietro, is twelfth night moved to a midwestern town in 1955, with a few of the other comedies borrowed from along the way. ck productions staged it together with the town of islip, and the run went from 25 june to 10 july.

ck productions · the listing · the promo video

Supercomputers For Audio Research and Development

Mon, 01 Feb 2016 00:00:00 GMT

cewit's newsletter ran a short piece on what i was doing with the university's supercomputing allocation: audio synthesis and modeling at a scale that does not fit on a desktop.

having that much compute changes which questions you can ask. a lot of audio engineering is choosing a filter design or a basis function on the strength of experience and then tuning it until it sounds right. with a cluster you can search the space instead, evaluating thousands of candidates against a real corpus to find out whether the conventional choice was ever the best one.

the same models apply outside music. forensic audio and medical imaging are both problems of pulling a signal out of noise when you have a decent prior for what the signal should look like.

read the full article, inside the february 2016 newsletter pdf.

The Future of Sound

Wed, 11 Nov 2015 00:00:00 GMT

the stony brook press came to talk to me about synthesizers that listen back. i was twenty and halfway through an applied maths degree, building pedals that tried to work out what a player was doing rather than waiting to be told.

two of them made the article. a bass synthesizer that tracks the pitch of whatever it hears and calculates the harmonically correct lower note in real time, so it stays in key and in time without being configured. and a convolution reverb, which takes an impulse response of a room and lets you play as though you were standing in it: carnegie hall, or the basement venue down the road, from a recording of the space.

i had been building audio hardware at pigtronix on long island for a few years by then, so the pedals were real hardware. the new part was putting a learning system in the loop: something that proposes a sound, watches which ones you keep, and gets better at proposing.

this was the motiff technologies era, my first company, run out of an undergraduate degree with pigtronix advising.

i told the reporter that music is data processing, just with an error metric of whether it sounds good. i still think that is right.

read the full article

Sweet Charity at New Haarlem Arts Theatre

Thu, 26 Jul 2012 00:00:00 GMT

new haarlem arts theatre staged sweet charity at aaron davis hall in the summer of 2012, and i played bass guitar and double bass in a band led by my friend brett pontecorvo. we were onstage in costume and worked with the cast through the show.

aaron davis hall, on the city college campus at 135th and convent. photo by HPPYCYCLNG, cc by-sa 4.0.

julio agustin directed it as a latino re-conception rather than a straight revival. the characters moved toward the cast, so charity became caridad, while cy coleman's music, dorothy fields's lyrics and neil simon's book were left as written. edlyn gonzález played caridad, and agustin, who had spent years on broadway in fosse, chicago and steel pier before he moved to directing, took an audelco nomination for this one.

previews began on 26 july, the show opened on the 28th, and it closed on 19 august. the new york times praised lainie munro's choreography and the "sure-footed accompaniment from brett pontecorvo's small band". the times filmed an excerpt too, which is the only footage i know of.

the times review · the times' excerpt · theatermania's review · backstage's review · playbill on the production · the casting announcement · new haarlem arts theatre

It Ain't Nothin' But the Blues at New Haarlem Arts Theatre

Wed, 27 Jul 2011 00:00:00 GMT

in the summer of 2011 i played bass guitar and double bass for it ain't nothin' but the blues, at new haarlem arts theatre in harlem, alongside my friend brett pontecorvo.

aaron davis hall, on the city college campus at 135th and convent. photo by HPPYCYCLNG, cc by-sa 4.0.

the company was new that year. city college's department of theatre and speech had just started it, and this was part of the opening season. alfred preisser directed, having founded the classical theatre of harlem and run it for its first decade, and jeffrey bolding was the musical director. the show is a revue rather than a book musical, so there is no plot to follow and no scene to underscore. as the times put it, the songs "remain front and center". we played from a side-stage pit rather than out of sight under one, in costume, with the cast coming over to work with us through the evening.

previews began on 27 july, the show opened on the 30th, and the run was held over a week past its announced close, to 28 august. the new york times was mixed on the evening but found "lots of standout moments" in it, from "a strong, nicely varied cast". that november the production tied for musical production of the year at the audelco awards, with tracy jack winning for choreography.

the times review · broadwayworld on the production · playbill on the company's launch · the audelco nominations · new haarlem arts theatre