POST
momo is a browser app where a four-year-old, an eight-year-old and a parent can play real instruments and see the sound together. It runs on a laptop, a tablet or a phone, needs nothing installed, and is open source (AGPL-3.0). You can try it at momo.mojari.de.
This page documents it as research. The app is the research vehicle. The contribution is the set of design rules behind it and the evidence for each rule, with an honest account of what is built, what is only designed, and what nobody has shown yet.
The question
Which design rules for an open-source, child-adequate, real-time audiovisual instrument allow children of different ages and their parents to play and learn together, and how can their effect be observed?
In plain words: can one screen be fun for a small child, an older child and an adult at the same moment, so that all three learn something, without making it too easy for one or too hard for another? And what must the software do, and refuse to do, to make that work?
The question breaks into six parts, each answered further down:
Shared play. What makes one instrument fun across ages at once? (section 1)
Adults as learners. How can a parent learn beside the child instead of teaching at the child? (sections 1 and 2)
Learning order. Which order of skills and which kind of feedback fit ages 4 to 8? (section 2)
Sound to picture. Which mappings help a child understand what they hear without overload? (section 3)
Timing. Which timing windows keep real-time play satisfying on small hands and slow devices? (section 3)
Safety and openness. Which privacy, safety and open-source choices keep the setting safe and reusable? (section 4)
What is in this page
1 Games and play: the challenges, the make-and-explore tools, Hear & Play, Jazz Jam, two-player modes, age lanes
2 How momo teaches: the lesson ladder, retrieval and spacing, feedback and praise, the difficulty nudge, coding for kids
3 Band, sound and picture, instruments: band play, accompaniment, the front-page world, song shelf, instruments and input
4 Safety, privacy and platform: child-safety rules and their state, old devices, light mode, open source, a dated build history
5 How it is tested, and what is not known: family sessions, informal feedback, evidence levels, limits
Every feature carries a status: Built, Partly built (with the part named) or Designed, not built.
1. Games and play
Nothing in this section has been shown to improve learning. "Tested" or "measured" here means checked by reading the code or by a headless run (the page driven by a script, with a fake microphone where needed). No child has tested these features in a study. Where a design comes from the music-learning literature, I say so.
One engine, five games, one number on screen
What you see and do: Every game looks and behaves alike at the edges. Each shows one meaningful number, not a pile of score, streak and multiplier.
How it works: Every game uses the same four parts: a chart (notes with times and lanes), a judge (was the hit on time), a clock and a lane drawer. A new game is a new set of rules. The notes say typically under 100 lines, though real game files run from about 125 to 1,500. I capped the true games at five; anything not scored or failable (Make a Loop, Write Code, Bouncy Lanes, Tree Strum) is a toy or tool.
Why it is built this way: One engine is how one person keeps many games consistent.
Status: Built for the engine. The one-number rule is a principle I did not audit game by game. The cap of five is historic, since the app now lists many more tiles.
Falling Lanes
What you see and do: Notes fall and you hit the matching pad or key as each lands on the hit line. Drums get one lane per pad, keyboards one lane per key.
How it works: It uses the shared chart, judge and clock, with difficulty derived by rule (see the difficulty section).
Why it is built this way: It is the flagship, so the timing rules apply hardest here.
Status: Built.
Echo, Groove Keeper and Groove Snake
What you see and do: In Echo the app plays a one-bar phrase and you play it back; nothing falls. In Groove Keeper you play against a click and one shape stays centred while you are steady and drifts when you rush or drag. Groove Snake is a longer cousin: a snake grows one segment per beat and turns every four.
How it works: Echo phrases are generated and grow longer. Groove Keeper can be played by two: one holds the groove, the other plays over it. Groove Snake has no timer. Three good chapters in a row raise the level and three weak ones lower it. Its timing windows are wide on purpose (the notes give plus or minus 90 ms and 180 ms). How smooth the snake's path looks is cosmetic only.
Why it is built this way: Call and response is how drummers learn. A strict window in Groove Snake "felt bad", and I cite another rhythm game's published account for that. The research found no precedent for a path as a mechanic, so the path sits on top of a proven leveling method.
Status: Built.
Not known yet: The notes do not explain which of the two Groove Snake windows is which.
Song Play and the demo song shelf
What you see and do: Load a song, mute its drums and you are the drummer, or mute the keys and you play keys. Words show over the lanes if the song has them.
How it works: The shelf holds about 20 whole pieces that are public domain or traditional. Each has keys, guitar, drums and a band part that plays underneath. One piece runs 5.5 minutes. Songs owned by living makers appear only as "bring your own" cards, filled by a file you own that stays on your device.
Why it is built this way: No pop songs ship, because their melodies are protected and the site is public. The test is EU law (the site is hosted in Germany) plus a composer dead over 70 years or a traditional tune.
Status: Built.
Not known yet: Melodies were written from memory or read from scans by a model. Bar lengths are machine-checked, pitches are not. The notes say to listen before trusting one. I did not inspect the song data.
Sound Painter
What you see and do: Pads and keys paint on a canvas. No goal, no timer, no failure. Two players share one canvas.
How it works: An older child can open the file and change what each pad paints, so it bridges to coding. It is meant as the default landing screen for the youngest.
Why it is built this way: It is the default first screen for the youngest. The notes give no further reason.
Status: Built.
Make a Loop and the circle view
What you see and do: Eight slots across, one row per drum. Tap to place a sound, press play and it loops; change a slot and it changes next pass. The circle view shows rings, one per drum, with active steps joined into a polygon, so four even hits make a square.
How it works: The app makes this sound itself from oscillators and a noise burst, with no sample files. Tapping a ring spreads its hits as evenly as possible (a Euclidean rhythm). I checked every count from 1 to 7 and every start position: the count is kept and gaps differ by at most one.
Why it is built this way: It teaches sequence, repetition and edit-and-rerun with no reading, in the spirit of floor robots for young children.
Status: Built.
Not known yet: One note says to drag an animal into each slot, another says to tap a sound. A target-matching mode appears only in code comments.
Write Code
What you see and do: A text box, a canvas and a tiny vocabulary. The sketch reacts to your drum hits.
How it works: The words cover hits, drawing, shapes, a random number, sounds, screen size, time and a memory that survives between frames. Errors are one plain sentence, never a stack trace, and drawing switches off after the first error. Browsers phrase an unclosed bracket three different ways, which I measured.
Why it is built this way: I did not use two well-known creative-coding tools. Both load from an outside server, which breaks the offline promise, and both need a newer browser than the old tablet I support. A child can read all of this vocabulary.
Status: Built.
Not known yet: The notes say "nine words", but counted one by one there are more.
Bouncy Lanes and Tree Strum
What you see and do: In Bouncy Lanes the floor is the instrument: one block per lane. Tap to drop a ball, or hit a drum and a ball drops over that lane, higher the harder you hit. Ramps send balls to other lanes, and Keep re-drops stopped balls. In Tree Strum a tree grows and every branch is a plucked string: drag to strum, tap to pluck.
How it works: A ball keeps 80 % of its speed per bounce. Measured headless with jittery frames, the ratio of consecutive bounce gaps was 0.791 to 0.798 against the physics value of 0.8. In the tree, longer branches sound lower, spread over C3 to A5 of the C major pentatonic, and the string pitch measured within 5 cents at four test pitches.
Why it is built this way: Bouncy Lanes follows Dillon Bastan's "Bouncy Notes" and Tree Strum his "Tree Tone", works in which rhythm and pitch come from physics. "Big means low" matches a cross-modal rule used across the app.
Status: Built.
Hear & Play: the round
What you see and do: The app plays a short jazz phrase and the instrument lights as it sounds. Two clicks later you play it back. A miss gets the right note played softly and the same call again. Nothing says "wrong". Instruments are a drum kit, a piano, or a tree harp (Baumharfe), where strands hang like harp strings, low and long on the left. A "hide indicators" option keeps the sound and hides the lights.
How it works: A match moves to the next call; one miss repeats it; two misses give a new call. The judge checks notes in order and in time. The window is 0.32 minus 0.14 times complexity, in seconds. A round passes at 0.60 plus 0.15 times complexity of the notes. More than twice as many hits as notes ("hammering") scales the score down. Drum voices unlock by family as complexity grows. Two players answer alternate rounds.
Why it is built this way: It draws on listening before playing (Gordon), echo playing, the right answer shown at once after an error, a steady beat with a partner, and flow, all from my learning notes. The lights are a scaffold to fade.
Status: Built.
Not known yet: Tempo is quoted as "76 to 120 bpm" in one place and as 80, 98 and 116 in a table.
The complexity ladder and the jazz phrase generator
What you see and do: Phrases grow "a tiny bit more complex, going up very slowly" as you succeed and ease back if you struggle, never below where the song started.
How it works: Level moves 0.02 per matched round. At complexity 0.1, 0.5 and 0.9 phrases have 3, 5 and 7 notes and a round passes at 62, 68 and 74 %. A script run showed 30 misses from 0.3 stay at 0.3. No melody is stored. Each phrase is built by rule from five keys, common chord progressions, rhythm cells and drum figures. Up to 8 candidates are made and the least repetitive wins. The same seed gives the same phrase.
Why it is built this way: Copyright protects a specific melody, not a chord progression, scale or rhythmic cell, so generated phrases avoid existing tunes. This is my own reasoning, not legal advice.
Status: Built.
Not known yet: On 50 phrases per row, drums at the lowest complexity had a distinct-phrase share of only 0.44 (independent) and 0.68 (chained). That is by design a small space.
The growing song
What you see and do: Every matched Hear & Play round adds to one song per person. The card offers Keep building, Listen, Save and a star. Titles are a picture word plus a style, such as "Moonlight Swing".
How it works: A round of an instrument not yet in the newest part layers over it (at most three layers). Otherwise it appends. A matched round keeps the call; an unmatched one keeps what the child played, pulled 70 % toward the nearest eighth or triplet; a silent one adds nothing.
Why it is built this way: My brief was to connect rounds of the challenges to a longer track, so one adds little by little to something that evolves.
Status: Built.
Jazz Jam
What you see and do: Two to four players, each with their instrument drawn full size. A generated jazz band plays and thin lines fall onto the exact drum or key where a note fits. Every hit sounds good, a hit on a line sparkles and grows a shared picture, and a miss does nothing. There is no fail state and no score during play.
How it works: Keys snap to the major pentatonic. Five chapters of about a minute each run without stops (swing, bossa, call and answer, a 12-bar blues solo spot, a finale), at 84 to 108 bpm. A long jam is about 305 s, a short one about 151 s. Hard mode ("Profi") removes help: no snapping, no band help, and only the exact drum or key counts within 0.12 s.
Why it is built this way: Early feedback was that children were interested but quickly frustrated when the interaction was unclear, and that it needed more time to reach the groove. I shortened chapters for that reason.
Status: Built.
Not known yet: The jam lengths are computed totals, not measured sessions.
Deja-vu dial
What you see and do: A dial next to every dice button in the pattern tool and in Write Code. At one end every roll is new, at the other the same line returns, and between them a roll is a variation of the last.
How it works: Each random draw repeats the same draw of the last roll with the dial's probability. On the bass role, similarity to the previous roll measured 0.51, 0.60, 0.74 and 1.00 at dial settings 0, 0.5, 0.8 and 1, with 0 malformed lines in 500 rolls.
Why it is built this way: A dice button alone cannot make variations, and varying a loop is what a musician does. It follows a hardware module's design.
Status: Built.
Difficulty ladder, lanes and drum families
What you see and do: One chart is written once at full detail and easier versions are made by rule, so a young child and an older child can play the same song. Lanes mirror the instrument.
How it works: The code has ten rungs. Windows go from 0.420 s down to 0.050 s and ghost (very soft) notes appear from level 9. Each level keeps the notes of the one below. The first rung is one target, one note per bar. A keyboard gets one lane per key (37 keys). A drum part grows by family (kick, snare, hi-hat, toms, cymbals) to all nine pads.
Why it is built this way: One authored chart makes a song library tractable for one person. My first rung was an adult's idea of a beginner level, so I added easier rungs.
Status: Built.
Timing, scoring and two players
What you see and do: Before first play you tap along to eight clicks. The lowest levels show no score. Higher levels show accuracy and, at the top, drift: how early or late you tend to be. In two-player play score is the percentage of what was on your own screen, never raw points.
How it works: The mean tap offset is subtracted from then on, per player. The app uses the audio clock, never frame counts. Each hit is judged against the nearest unjudged note in its lane, keeping the signed difference. Two-player shapes are split screen, pass the phrase, cooperative steadiness, one drums and one keys, and one shared canvas.
Why it is built this way: Every setup has latency, and without calibration every game feels slightly wrong. "24 ms early on the snare, consistently" can be acted on; a percentage cannot. A young child against an older one is not a fair game, and an all-versus set produces one crying child per session.
Status: Partly built. Calibration, the audio clock, signed differences and two-player shapes are built. The scoring-by-age text was written for five levels, and the code has ten.
Not known yet: I did not verify the eight-click detail, or what the "allow miss" setting means per rung. The notes say two modes are competitive without naming them.
Notes: hear it, find it, see it written
What you see and do: Three modes: Hear it (a C, then the note; find it on the keys; the staff shows only afterwards), Read it, and Name it.
How it works: Note sets grow from C D E to wide and black keys, and the next opens when every note was found first try on two different days. A miss plays your note and the right one and says "go higher" or "go lower"; after three tries the note is shown.
Why it is built this way: It follows a review of music-learning research from September 2026, ordered as the evidence suggests. No sad sounds and no "wrong".
Status: Built.
Not known yet: The notes cite no specific papers for this section.
Band Play and Karaoke
What you see and do: In Band Play each player picks keys, drums, guitar or sing, with 0 to 2 singers; the app plays unheld parts. Singers see a pitch ribbon. Karaoke is for singers, with a queue, duo turns and an evening board. Words come from a paste, a file you own, or bundled words for public-domain songs.
How it works: Speed steps are 100, 85 and 70 %. A singer's score is the share of time within a semitone of the melody, in any octave. Karaoke key moves by semitone and is saved per song. Below level 3 a singer sees no percentage. Words stay in the browser and are never uploaded.
Why it is built this way: Lyrics are licensed separately and no free lawful source exists, so users bring their own. A ribbon is a shape, not a verdict.
Status: Built.
Not known yet: Evening features were measured in headless Chrome with a fake microphone only. Scarborough Fair has no words yet.
The singer's voice chain and the howl guard
What you see and do: If the microphone howls, the app mutes it for 30 seconds with a calm gold message while the song keeps playing.
How it works: The voice goes into a small reverb of its own, so the kit never enters the voice's echo. The monitor volume is capped, which a software loop test supported. The guard looks for a loud, narrow peak that stays at the same frequency for most of a second, places up to three notch filters, then mutes.
Why it is built this way: A shared reverb send is wrong in a living room. The guard follows a published review of acoustic feedback control.
Status: Built.
Not known yet: The numbers come from a simulated loop and synthetic tones, not real rooms. A nearly pure tone held over a second in front of an open monitored microphone is notched, and that is intended.
Camera in Music Visuals
What you see and do: A Camera button feeds the webcam into the visual scenes. Only scenes that suit a picture show while it is on, and a red sign stays at full strength.
How it works: First use shows a grown-up card, then the browser asks. Fifteen scenes plus "My code" can use it, each its own way. A flash guard dims the video on sudden jumps. Nothing is recorded or sent.
Why it is built this way: I asked for all scenes, then limited it to those where the picture has a place in the idea.
Status: Built.
Beat Pong
What you see and do: Pong where the paddle is earned, not steered. The ball crosses in a fixed number of beats. You choose which pad to hit and how close to the beat. A miss is never a fail state. Each return plays the next note of a generated jazz phrase. The one number shown is rally length.
How it works: The pad picks the zone and timing sets how far the paddle snaps toward the ball. There are five rungs, from 2 to 5 zones and from 2 down to 1 beat per crossing; the code maps ten levels onto them. Two players can play co-op or versus; versus shows accuracy in words and declares no winner.
Why it is built this way: "A length, not a score" cites work on informational feedback over controlling reward. Two-player cites work that children synchronise better with a live partner than a machine.
Status: Partly built. The notes call it unbuilt, but code exists and the game is registered. I did not run it.
Not known yet: The notes ask whether the pitch-band variant is its own mode and whether versus should exist for the youngest.
Animal Band, crossover play and text modes
What you see and do: Animal Band is meant for a 4-year-old: each pad is an animal that appears when hit, with no score or failure. Crossover play pairs a younger child's loop with an older child's solo, or a sketch driven by the younger child's hits. Text can be off, English, or English with German underneath.
How it works: Every screen must work with zero words. The older child's trainer shows drift in milliseconds.
Why it is built this way: One app with a difficulty setting was rejected, since the older child "will smell a baby app immediately". Two app sets share instruments and one runtime.
Status: Partly built. A related animal feature may exist, not confirmed. Crossover apps are Designed, not built as dedicated apps.
Where the notes and the code disagree
Beat Pong is documented as unbuilt, but the code exists, so its status is Partly built.
Difficulty has 10 rungs in the code, not the 5 of the older table, and the scoring text is out of date.
The notes say no song ships with words, and also list bundled words. The second is later and more specific.
A Jazz Jam code comment says ten minutes, while the interface says about 3 or 5.
An older plan for Write Code named an outside library, which later notes replace.
Pong's tonic pause and idle behaviour appear only in code comments.
Language modes are described differently in the notes and in the change log.
2. How momo teaches
momo teaches music through short lessons placed in front of free play. There are 39 lessons in six stages, in a fixed order: Pulse, Rhythm, High and low, Keys, Reading, and Band skills. Each lesson takes one to three minutes: one demo, a few tries, one result.
The order follows one idea: sound before symbol, body before instrument. The child hears and plays a thing first. Only later does it get a name, and later still a written sign. Letter names for notes do not appear before stage 4. Within each topic the lessons run in four steps: echo it, name it, read it, invent it. The two invention lessons close the rhythm stage and the pitch stage.
One point first, so it is not lost further down. I designed these rules from published research and teaching practice. I have not measured whether momo improves anyone's learning, and neither design document reports a test with real children. Every threshold below is a design value, not a result. Where the literature itself is contested, I say so under "Not known yet".
Status words: Built means the feature exists in the live app. Partly built means some part exists, and I say which. Designed, not built means it is a written rule only.
The lesson ladder and the unlock order
What you see and do. The home screen shows a lesson path above the game tiles. Each lesson is a round node: done lessons show their best stars, the next one pulses, locked ones are dimmed. A lesson opens with a short demo where the avatar plays with sound. Then a big start button and a speaker button that repeats the demo as often as asked. The child tries, then sees a result card. Every lesson also has a text-free pre-reader form (targets of at least 56 px, one tap) and a review form, and runs on on-screen pads alone.
How it works. Stage sizes: 6 lessons in Pulse, 7 in Rhythm, 7 in High and low, 7 in Keys, 6 in Reading, 6 in Band skills. Lessons open by what they build on (a prerequisite tree), never by points. For example, 6.6 needs 6.1 and 3.4. All ages get the same 39 lessons in the same order. The age bands (3 to 10) are a design target, never a lock.
Separate from lessons, game modes open when the child's points pass a line and, where the music needs it, one named lesson is done. Echo opens at 15 points with lesson 1.1; Band Play at 450 with lesson 6.1; the code screen at 680 with lesson 5.2. An unlock is permanent. The free sound painter, the music player and all lessons are always open, so a child who skips lessons still has somewhere to make sound. A grown-up can switch lesson gating off.
The lessons, grouped by stage:
Stage 1, Pulse (steady beat, felt with the body, at the child's own tempo; no misses shown). Tap four times to set a tempo; march to slow and fast music; tortoise or rabbit; play one hit loud or soft; echo a one-bar call; hit the first beat of each bar.
Stage 2, Rhythm (speech first, then syllables, then cards, then your own). Play a spoken picture word; four "ta" cards (one beat each); "ta" with "ti-ti" (two half beats); stay quiet on a rest; hear a rhythm and pick its cards; build a repeating pattern; invent a rhythm.
Stage 3, High and low (voice first, every singing step has a pad fallback, nothing is recorded). Bird (high) or bear (low); second note up or down; echo two notes (so-mi), then three (la); follow a rising and falling line with the voice, judged on direction only; tunes on five notes where nothing clashes; invent a four-note tune.
Stage 4, Keys. Find the groups of two and three black keys; find C; hear C and find a note; thumb on C, one finger per key; pick a key's name from three; first two lines of a children's song with the band; tunes on the five black keys.
Stage 5, Reading (only after sound; the answer is played back afterwards). Long and short bars; stick notation; note heads above or below a line; read C D E, then C to G; hear a rhythm and write it with cards.
Stage 6, Band skills. Backbeat (kick on 1 and 3, snare on 2 and 4); hi-hat; a drum fill; quiet verse and loud chorus; switch groove when the song changes section; play a part in a song with the app playing the rest.
Why. The order follows the Kodaly, Orff and Gordon traditions. Sources as written: A Kodaly Sequence (Wichita State University); Kodaly method explained (Flat) and OAKE; AOSA, Orff Schulwerk approach; GIML (Gordon: aural/oral, verbal association, symbolic association; discrimination learning before inference learning). Movement before counting: Institut Jaques-Dalcroze. Keyboard and drum order: practitioner sources only (see table).
Status: Built, with differences. Partly built: the pre-reader form of lesson 4.5 is missing. Some lessons differ from their design row. In 1.4 the top half of the canvas means loud. In 2.6 the play-along condition is not measured. 6.6 has no singer seat. Lesson 1.2 asks for movement but judges pad taps.
Not known yet: The keyboard and drum sequences rest on teaching practice, not controlled studies. Microphone timing for clap lessons on old iPads: latency not measured. I did not check all 39 lessons against their design rows.
Retrieval and spacing (the Leitner boxes)
What you see and do. Every finished lesson comes back later as a short review. Missing a day costs nothing and nothing expires.
How it works. The Leitner method sorts items into numbered boxes; the higher the box, the longer the wait. Each lesson has a box from 1 to 5. A pass moves it up one box. A result below the pass line, or a pass tipped by the near-miss bonus, keeps it in box 1. A lesson is due this long after it was last played: box 1 next session, box 2 after 1 day, box 3 after 3 days, box 4 after 7, box 5 after 14. "Due" only means eligible. There is no streak and no day counter.
The Notes challenge has its own boxes: box 1 comes six times as often as box 5, and a new note set opens only after every note was found first try on two different days.
The first gated mode of a session starts with one warm-up review of about a minute. A session is new after 30 minutes idle. After a window ends the child gets one new lesson and one old review, never a shuffled mix. This is gentle interleaving (mixing skills).
Why. Retrieval practice improved primary-school children's recall at one and five weeks, and spacing with retrieval works best (PMC 2013 and 2016 reviews; Fazio & Marsh 2019; Nature Reviews Psychology review). Interleaving helped children's category learning, less in younger children (an interleaving study, PMC 2025).
Status: Built for lesson reviews and Notes. Rhythm challenges outside lessons do not bring back earlier patterns.
Not known yet: Strong for school-age, moderate for ages 3 to 5; evidence under six is thinner. The interleaving study used ages 10 to 14 and adults, so the benefit for under-10s in music is unverified.
Feedback and praise rules
What you see and do. A correct hit makes the target bounce and a small note fly to the flower, with a soft marimba tone. A near miss makes the avatar wobble and tilt its head, and the right note plays quietly after the child's own. No sound plays before the first tap.
How it works. Feedback names what the child did ("4 of 5 echoes"), not what the child is. Ordinary success gets no stacked superlatives. Safety rules: each animation lasts at most 1.5 seconds; no area changes brightness more than 3 times per second; full-screen colour never follows the beat; reduced-motion settings show a still end state; feedback sounds are at least 12 dB quieter than the music; never sad (no falling fail figure, no red, no crying character).
Why. Mueller & Dweck 1998 (fifth graders); Kamins & Dweck 1999 (5 to 6-year-olds); Gunderson et al. 2013; Brummelman et al. 2014 (inflated praise lowered challenge seeking in children with low self-esteem).
Status: Partly built. Wording rules and safety rules are built. The top timing category is still shown as "perfect" with the biggest animation. I have not decided whether to change it to "right on the beat".
Not known yet: The mindset claim is contested. Li & Bates 2019 reported little support and a re-analysis argued it did replicate; effects are small (about 0.08, Sisk et al. 2018); study-quality concerns (Macnamara & Burgoyne 2022); benefits concentrated in lower-achieving students in supportive schools (Yeager et al. 2019). Evidence is moderate for process-over-person praise and contested for mindset interventions. The inflated-praise result is one set of studies, ages 8 to 12.
Errors, and the right answer shown at once
What you see and do. There is no failing and nothing is taken away. The first stages show no misses. A miss plays the right answer. In the Notes challenge a miss plays both notes, says higher or lower, and after three tries shows the note.
How it works. Pass lines are lenient, about 60 to 70 percent. A lesson that falls short comes back sooner as a review. It still reopens the play window: play is never withheld for a poor lesson. Errorless steps are used only for the first contact with a skill.
Why. Corrective feedback after errors helps (Metcalfe 2017). Instruction first was favoured over struggle first for grades 2 to 5 (Sinha & Kapur 2021).
Status: Built.
Not known yet: Moderate: strong for corrective feedback, contested for struggle-first designs with young children.
Choices
What you see and do. When a play window ends, the child sees two lessons: the next new one and one due review, with the length drawn as a bar, not a clock. The map lets a child pick any open lesson.
How it works. Play time is counted in finished rounds, never minutes. The grown-up setting is short 3 rounds, medium 5 (default), long 8. The child sees no clock, countdown or warning. The window closes only on a result card, never mid-song; a song over 4 minutes counts as two rounds. From stage 3 on the pair is at most two minutes each: the first reopens half the window, the second the rest. In stages 1 and 2 one lesson reopens the full window. Endless toys are never interrupted; the card waits for a 5 second pause.
Why. Autonomy, competence and relatedness (Ryan & Deci 2000). A two-minute warning made transitions worse in a diary study of families with children 1 to 5 (Hiniker et al. 2016, "Screen Time Tantrums").
Status: Partly built. The planned two-second sound fade before the card for endless toys is not built. Toys with a text panel are never parked.
Not known yet: Strong as a framework. The Hiniker study is a diary study of ages 1 to 5. Offering play as a reward for lessons carries an open tension, see the motivation rules.
The difficulty nudge
What you see and do. After a challenge round a quiet check can move the difficulty one rung. The result card says so both ways: "Nicely played, next round steps up to level N" or "Let's stay at level N for a bit." A grown-up can switch it off.
How it works. The app keeps the last three accuracies. Three in a row at 92 percent or more move the level up one. Three in a row at 55 percent or less move it down one. Anything between leaves it. The window empties after every move. The level never goes below 1 or above the top, never changes mid-round, and applies to single players only.
Two things are in the code but not in the design text, found by reading the code. First, a minimum gap of 3 rounds after a move before the next move. Second, the unlock table contains two video modes (karaoke at 450 points, band at 520) that the design document does not list. I do not yet know if they are meant to be public.
Why. Small, visible steps that can go back down, with challenge matched to skill: Fong, Zaleski & Leach 2015, a meta-analysis of 28 studies.
Status: Built.
Not known yet: The 92 and 55 percent thresholds and the window of 3 are a first cut, not measured against real play. The flow link is moderate and weaker in education settings. The longer 25-level ladder raises tempo in the teen chapters, which sits in tension with the earlier rule "more notes, not faster"; the documents do not reconcile this.
The result card
What you see and do. After a lesson: the avatar bows, stars pop in, one number says what was played, points fly to the flower, a bonus box appears only when the bonus rule fires, then three equal buttons: again, next, home. When a mode opens, its tile rises, a short fanfare plays once, and "try it" and "later" are the same size, so there is no nudge. After a plain challenge round a separate card shows accuracy, stars and the difficulty line; a grown-up can turn it off without changing scoring.
How it works. Points ("seeds") only go up, are never spent, and are not a currency. First pass: 10 plus 5 per star. Invention lessons: 20 flat, no stars. A better best-star later: 5 per new star. Review finished: 5. A replay that is not due, or a try below the pass line: 2. All first passes at one star give 595 points; the last unlock line (680) needs about 17 reviews more (my own arithmetic). A music flower beside the path grows from seed to sunflower in six stages (the last at 680 points) and never shrinks.
The near-miss bonus: a result just short of a star or unlock can get a bonus star or the missing points (at most 10). "Near" means one item short, or at most 10 percent of the line short. It is given on every odd near result, capped at one per profile per session; the pass line wins if both kinds are near. It never changes the measured number and never teases beforehand. Free play outside lessons adds 0.5 or 1 seed per minute, capped at 10 per session.
Why. Near misses in chance games raise desire to keep playing (Clark et al. 2009, Neuron). The bonus is meant to differ: skill-based, predictable, capped.
Status: Built.
Not known yet: I argue the bonus differs from the chance-game effect but have not tested that. The free-play weights are a first cut; nothing has been measured.
Scaffolding that fades
What you see and do. Early on the child gets extra help: note names on keys, coloured note heads, a glowing step in the loop lesson. As the child succeeds these are removed.
How it works. Five derived levels reduce notes and lanes and widen timing windows. Band Play runs at 100, 85 or 70 percent speed. A longer ladder of 25 levels in seven chapters (Flea to Stag Beetle) lets one app serve ages 3 to adult. The guide fades from chapter 5 and is gone at chapter 7. The timing window narrows from plus or minus 0.420 s at level 1 to about 0.030 s at the top. From chapter 3 lessons grow longer.
Why. Wood, Bruner & Ross 1976; Vygotsky's zone of proximal development, with Chaiklin 2003 warning the two ideas are conflated. Tempo stops climbing because spontaneous tempo slows across life: about 200 bpm at ages 4 to 7, about 95 for adults (McAuley et al. 2006, n=305).
Status: Partly built. The fade and the ladder are built. Levels are chosen, not adapted, except through the difficulty nudge for single-player challenges.
Not known yet: Strong as practice; the zone of proximal development is a framework, not a measured quantity. The claims about two-hand movement at age 7 and the adolescent singing dip have no named source. Game timing windows come from game documentation, not child studies. I did not verify the ladder's in-code values.
Motivation rules
What you see and do. No streaks, no daily pressure, no countdowns, no timers on answers. Profiles that existed before the lessons keep every mode open, because taking back something a child had is a loss.
How it works. Fourteen design principles sit behind this, among them: earned progress is never lost, never punishing, level per child and not per age (no age is stored), and local only. All progress lives in browser storage on the device. A grown-up panel behind a gate holds the switches, including an "unlock everything" test switch that defaults to on for now and is not a security boundary.
Why. Promised rewards for what children already love can reduce interest (Lepper, Greene & Nisbett 1973, preschoolers drawing; Deci, Koestner & Ryan 1999, 128 experiments). So points are few and never spent, the bonus is small, and the painter, player and lessons stay free.
Status: Partly built. Accessories are a small choice of two and nothing is taken away, but stars scale with accuracy and appear on every result card, which makes them expected.
Not known yet: Strong for expected tangible rewards, contested for verbal and unexpected rewards; some researchers dispute how general the effect is. Playing as a reward for lessons is a named tension I softened, not removed. Whether the music player stops after each song, as required, is not stated.
Coding for kids
What you see and do. The youngest build a loop: eight slots, one row per drum, tap to fill, it repeats; their own playing can become an editable pattern. Older children use a code screen with nine words plus a few variables and four starter sketches to load and change. Errors are one plain sentence. Projects are not shared online, by design. Invention lessons are never graded.
How it works. The rules: learn by making things, a low floor and a high ceiling, quick feedback, and sequencing you can touch for the youngest. A working example comes before new work.
Why. Papert and Ackermann; Resnick, with Flannery et al. 2013 (ScratchJr), Resnick & Rosenbaum 2013, Resnick et al. 2009, Resnick 2017; Bers; Bell & Vahrenhold 2018 (unplugged); the worked-example effect.
Status: Partly built. Making, small vocabulary and sequencing are built. The step from the loop to the code screen is steep for ages 6 to 7, with no block or icon stage between. Code needs a keyboard shortcut to run, and after an error drawing stops until the next run. Unplugged activities are designed, not built.
Not known yet: Moderate for the making rules; worked examples strong for novices, mostly school-age and older. Unplugged activities are contested: evaluations show mixed results.
Time and attention rules
What you see and do. Lessons are short and complete. Echo phrases are one bar. A screen shows only what the task needs: one number, no trivia, no moving decoration during play.
How it works. A round ends on a result card. Windows count rounds and never end mid-song.
Why. Sweller 1988; Sundararajan & Adesope 2020 (small-to-medium negative effects of seductive details).
Status: Partly built. Short units and one job per screen are built. Full-length songs remain in some modes, against the short-unit rule for the youngest.
Not known yet: Strong for cognitive load in general, moderate for children. The rule of "minutes of attention per year of age" lacks a clear research source (unverified) and is contested; I do not use it.
Sources and how strong they are
Strength words are copied from my working inventory and not upgraded. "Checked" means I opened the source in the design pass. "Practitioner level" means teaching practice with no controlled study found. None of these sources shows that momo itself improves learning.
Kodaly order and voice first: Source as written: Wichita State University; Flat; OAKE; Strength flag: checked; controlled evidence limited
Aural, verbal, symbolic; discrimination before inference: Source as written: GIML; theimprovingmusician.com; Strength flag: checked; limited controlled trials
Movement before counting: Source as written: Institut Jaques-Dalcroze; Strength flag: limited controlled evidence
Keyboard and drum order: Source as written: Piano Finders; The Middle C; Drumeo; Musora; Strength flag: checked; practitioner level
Daily singing improved kindergarten pitch matching: Source as written: Demorest, Nichols & Pfordresher 2018; Strength flag: checked; small effects
Falling minor third as natural first interval; fewer errors against a woman's voice than a piano: Source as written: practice wisdom; a search summary; Strength flag: unverified
Invented notation, pictures before staff: Source as written: Barrett 1997; Verschaffel et al. 2010; Bamberger; Strength flag: checked
Retrieval and spacing for children: Source as written: PMC 2013, 2016; Fazio & Marsh 2019; Strength flag: checked; thinner under six
Gentle interleaving: Source as written: PMC 2025; Strength flag: checked; music-specific benefit unverified
Two-minute warning worsens transitions: Source as written: Hiniker et al. 2016; Strength flag: checked (diary study)
Near misses raise desire to play: Source as written: Clark et al. 2009; Strength flag: checked
Scaffolding; ZPD: Source as written: Wood, Bruner & Ross 1976; Chaiklin 2003; Strength flag: ZPD not measured
Errors with feedback; productive failure: Source as written: Metcalfe 2017; Sinha & Kapur 2021; Strength flag: contested for young children
Autonomy, competence, relatedness: Source as written: Ryan & Deci 2000; Strength flag: strong as a framework
Overjustification: Source as written: Lepper et al. 1973; Deci et al. 1999; Strength flag: contested for verbal and unexpected rewards
Flow: Source as written: Fong, Zaleski & Leach 2015; Strength flag: moderate; weaker in education
Process praise; mindset: Source as written: Mueller & Dweck 1998; Kamins & Dweck 1999; Li & Bates 2019; Sisk et al. 2018; Yeager et al. 2019; Strength flag: contested for interventions
Inflated praise: Source as written: Brummelman et al. 2014; Strength flag: moderate; ages 8 to 12
Children's tempo; human partner helps: Source as written: Provasi & Bobin-Begue 2003; McAuley et al. 2006; Kirschner & Tomasello 2009; Strength flag: literacy link contested; replication unverified
Coding rules: Source as written: Papert; Resnick; Flannery et al. 2013; Bers; Bell & Vahrenhold 2018; Strength flag: moderate; unplugged contested
Timing windows of rhythm games: Source as written: osu!, StepMania documentation; Strength flag: game documentation, not child studies
Two-hand movement at 7; adolescent singing dip: Source as written: no source named; Strength flag: none stated
3. Band, sound and picture, instruments
This section records how momo lets several people play one piece of music, how it builds sound from everyday things, how the front page turns the real sky into a scene, and how instruments, microphones and phones reach the app. It is a feature record, not a result. Nothing here has been shown to improve learning. Where a design follows the literature I say "designed from the literature". I did not run the app while writing this section; the last subsection explains what that means.
3.1 Band Play
What you see and do. You pick a song and fill the seats: Keys, Drums, Voice 1 and optionally Voice 2. Whatever nobody holds, the app plays: bass and a band part, or the song's own recording if one was imported. Instrument players see falling lanes. The words run across the top, each syllable lighting on its note. Singers get a pitch ribbon and a score for staying on pitch and on time. At the end there is one band card with everyone.
How it works. The plain mode offers slower speeds of 85 % and 70 %. Band Play unlocks at 450 seeds (the app's progress points), the video version at 520. The full band runs on Mac or Windows with Chrome or Edge. An old iPad has no MIDI in its browser.
Why. The brief of 2026-09-14 asked for "a karaoke part that plays on top of the piano and drum parts".
Status: Built. Browser-tested without a microphone.
Not known yet: Anything with a real microphone, the pitch score by ear, and a real bought karaoke file with German umlauts or words stored as text instead of lyric events.
3.2 Karaoke and Duo
What you see and do. Karaoke is for singers only, with full backing and big words. Several singers take turns from a queue, each scored on pitch, on time and kept singing, with a soft target band of plus or minus one semitone. In Duo, every line is marked A, B or both, in two colours, and a child taps a line to cycle through them. A round such as Bruder Jakob is a duo by construction: voice B starts two bars later.
How it works. With two microphones each singer scores separately; with one, the two share a score.
Why. The brief asked for a singers-only mode with several players and a karaoke duo.
Status: Built. One test: Bruder Jakob with two generated voices. Voice A on its notes scored 87 %, a wrong note 0 %.
Not known yet: The test used generated voices, not people. The list in 3.1 applies.
3.3 Microphones and autotune
What you see and do. Each voice has a panel for input device, channel, level meter, noise gate and a latency check. Hearing yourself works only through headphones and is off by default, because on speakers the loop howls within seconds. Autotune nudges a singer onto the right note, gently or hard for a "robot" effect. It has seven controls: on/off; follow (the song's melody note or the nearest scale note); key and scale; speed (natural, about 80 ms, to robot, 0 ms); strength 0 to 100 %; keep vibrato; voice level 0 to 150 %.
How it works. Echo cancellation is off in plain play because it eats singing. Under a video it is on, while noise suppression and automatic gain stay off because both flatten what the pitch detector reads. Pitch is found with the YIN method; generated 220 Hz and 440 Hz tones read as notes 57.00 and 69.00. Autotune measured plus or minus 0.5 cents on test tones, about 20 ms of delay and about 4 % of one Mac core. It is off in browsers without audio worklets and in light mode. Nothing is recorded or leaves the device.
Why. I chose to build for every microphone setup. The brief asked for "an autotune option with a small set of the most important controls".
Status: Built.
Not known yet: Autotune by ear and echo cancellation with a real singer and speakers are unverified. The delay is "about 20 ms" in one note and "20 to 30 ms" in another.
3.4 Words timed to the melody, and the singer lane
What you see and do. For songs whose words are free to publish, each syllable is matched to a melody note, so words light up with no tapping. A strip above the pads shows the current line, the next line smaller and a level bar per singer with that child's animal, so a young child sees the microphone hears them. With no words, no strip appears.
How it works. Words are written per section as hyphenated syllables, matched note by note; a mismatch fails the build like a wrong bar length. The words must be public domain. On the shelf with free words: Auld Lang Syne, Scarborough Fair, When the Saints, Drunken Sailor, La Paloma, Alle meine Entchen, Bruder Jakob, La Cucaracha. Four German folk songs are planned.
Why. The shelf had melody, chords, bass and groove; singers lacked words timed to notes. On 2026-09-16 I decided to "only show any field for singer if there is actually text to show".
Status: Partly built. The syllable stage and the word-writing tool are built; the words were still being written at the status date. The strip is Built (checked in the code, not yet tested end to end).
Not known yet: Which shelf songs have finished words today.
3.5 Karaoke Pro, a layer for adults
What you see and do. Transpose a song to fit a voice (remembered per song), set a monitor level, choose a room effect (off, small, room, hall), search, see recent songs and queue songs for an evening. Words go full screen and controls fade after stillness.
How it works. Key range is minus 6 to plus 6 semitones; the recent list holds 8; controls fade after 3000 ms. Speed stays 100 % under a video or recording, because slowing sound without changing pitch needs a method the app lacks. By design there is no recording, uploading, sharing, online leaderboard or lyrics fetch.
Why. On 2026-09-16 I asked for karaoke that also suits adults.
Status: Built (checked in the code, not yet tested end to end).
Not known yet: Only the code header was read.
3.6 Video Band and Video Karaoke
What you see and do. Play or sing along to a video: a file the family owns, or a YouTube link, behind a grown-up gate. A link alone brings no notes or words, because YouTube's terms forbid taking the sound apart and the words belong to their writers. Notes come from a stored match, a shelf song, a file the family owns, or a "quick set" where the family taps the beat and picks key and style. With YouTube, the player is never covered: it sits centred with lanes left and right and words beneath.
How it works. The video is the clock. The song waits until the video starts, then follows its time plus an offset. An error over 0.25 s re-anchors at once; a smaller one closes at 10 % per frame. Pause, buffering or an ad pauses the clock. YouTube time is polled every 250 ms. The offset slider spans plus or minus 2 s. Speed is fixed at 100 %. In a stand-in test the clock minus video time was minus 1 ms and 0 ms after 30 s. The YouTube box is never under 200 by 200 pixels. Own videos stay on the device, never uploaded; on an old iPad one above 150 MB gets a warning.
Why. YouTube's policies forbid hiding, covering or shrinking the player and set a 200 by 200 minimum (cited as III.F and III.I). A video cannot be slowed, so a child meets a song first where it can be slowed.
Status: Built. Browser-tested end to end with YouTube at 1280 by 800 and in portrait.
Not known yet: Sync was tested with a stand-in clock, not a real YouTube video. No curated video has measured sync data. Drift over a four-minute song, ad state reporting and Safari 12.1 embeds are unverified. The YouTube script loads on first use only, a deliberate exception to the offline rule.
3.7 Syncing a chart to a video, and the grown-up gate
What you see and do. A Sync panel lets a grown-up tap the first sung word, tap the beat, tap a line start, nudge the key or sing the first note, then save for this video. The gate asks a grown-up to hold a button for 3 s, then tap the number matching a spelled-out number word among four.
How it works. Stored per video: offset, tempo, form and transpose (minus 6 to plus 6). The first-word tap subtracts 0.15 s for reaction time. "Sing the first note" only offers a hint. A child's taps never overwrite a grown-up's sync. Passing the gate holds for the page session only.
Why. On 2026-09-15 one video was in sync and another was not. A kids-appropriateness audit marked the pasted-link player as must-fix. The gate is a speed bump, not security.
Status: Built.
Not known yet: Tested with a stand-in clock only. The 0.15 s reaction time was not measured here. For When the Saints, three curated videos exist and which matches the chart cannot be known without watching them.
3.8 One laptop, no instrument
What you see and do. On a first evening, one player gets two parts: laptop keys play the piano lanes and on-screen pads the drum lanes.
How it works. A "one key, one sound" rule stops a piano key also sounding a drum. In a test, key presses scored only on piano lanes and pad presses only on drum lanes.
Why. It is the first-evening case, with nothing connected.
Status: Built.
3.9 Getting songs in, and what I will not build
What you see and do. A karaoke file the family owns can be imported, giving keys, drums, bass and melody as separate parts with words timed per syllable. An audio file can be kept as backing. A child's search is designed to reach three places only: the family library, a vetted offline catalogue fetched by an adult, and a "wish", a star tap that becomes a request an adult approves.
How it works. The in-app import reads MIDI exactly; audio is an estimate from the loudness curve, with no stem separation. A separate pipeline outside the app finds the beat, optionally splits stems and derives five difficulty levels; its optional tools were not installed on the development machine. There is no downloader for streaming sites and no lyrics scraping.
Why. Ripping breaks terms and, for commercial music, copyright. A child who wants a chart song gets it when a grown-up buys the track. "Safely" is met by architecture, not by a filter that will eventually fail.
Status: Partly built. Karaoke-file import and the basic audio estimate are built. The tempo line-up step, the three-place search and the catalogue are Designed, not built, apart from one wish card for a commercial 2017 track that cannot be published on the site.
Not known yet: Audio import does poorly on dense or quiet material. Whether a general wish queue exists in code is unknown.
3.10 The front-page world: sky, seasons, time of day
What you see and do. The front page is the scene: horizon at 60 %, the full star map above, colours for night, dawn, day and dusk from the real Sun. A tortoise stands somewhere new on every visit. Rare fireflies drift at dusk and night. Every star to magnitude 5.0 (1,630 stars), the 88 constellations, the Milky Way, the Moon in its phase, the planets and the Sun by day are shown, with hover cards.
How it works. The sky is computed for now, with a default observer in Bremen. Planets are good to roughly an arcminute (inner) or a few arcminutes (outer) within a few decades of the year 2000, ignoring refraction. By day stars stay faint at 0.15. The sky redraws when the part of the day changes and every ten minutes. Star data are the Yale Bright Star Catalogue (public domain) and constellation lines under a BSD-3-Clause licence, credited in the app. Trees show their seasonal state, from bare to snow, with hover cards in English and German; 28 species, 16 biomes. Backgrounds come from nine ordered layers, in flat fills with no gradients.
Why. On 2026-09-12 I asked for "an epic sky scenario that is very soothing", correct for the current date. For scenery, the brief of 2026-09-14 asked for a modular ruleset and scenes rich in nature.
Status: Built.
Not known yet: Accuracy is approximate. Worlds without species (Moon, void) keep older simple trees.
3.11 Sound-to-picture: the sky answers when pointed at
What you see and do. Hovering a star, tree, planet, the Moon, an animal or the tortoise plays a soft sound. A second effect, the sky song, sends notes drifting across the sky. Clicking one plays the next note of a fixed melody, never the clicked pitch, so no note is wrong. Playing it in time changes the scene once, then the effect pauses.
How it works. One key per visit keeps any order consonant. Voices differ by object: plucked string for stars, singing bowl for planets. Swing is 0.6 to 0.68, tempo 84 to 100. Cooldowns run from 0 s (star) to 30 s (tortoise). Nothing starts without a tap. The sky song melody has 8 notes in D major pentatonic, a pass needs a mean timing error within 0.14 s, then a 120 s pause. Nothing is stored or scored.
Why. On 2026-09-25 I asked for "very soothing and meditative", with some jazziness.
Status: Built (checked in the code, not yet tested end to end).
Not known yet: The sky song's host scene was removed from the front page, so where it now runs is unconfirmed.
3.12 Band Build: a stage of looping things
What you see and do. A stage with a palette of funny, familiar sounds. Tapping a tile puts it on stage, looping at once, in time and in key, so six random things still sound like a band. Nothing is scored or failed. Each element has mute, two to four knobs, a map button and a remove button. Pressing the map button, then any key, MIDI note or pad, binds that input to the element. A wand button invents a new sound with a name and picture, and a word field seeds the next tile from a typed word.
How it works. Sixty sounds in four tabs of 15: instruments, daily life (ticking clock, dripping tap), funny machines (hamster wheel) and nature (frog pond, rain). Pitch moves in scale steps, so nothing is wrong. At most 2 pulse, 2 offbeat, 2 melody, 2 pad and 3 fill sounds play together, in C major pentatonic by default. Up to 8 elements play at once (6 in light mode). Boards can be starred and exported as text code in the Strudel live-coding language. Invented sounds come from a fixed vocabulary of material, mechanism, size and mood, with German-first names such as "Glasregenrad".
Why. A ticking clock and a dripping tap can be a rhythm section. Cited: Toussaint 2005 (Euclidean rhythms), Hirsh-Pasek et al. 2015, Orff-Schulwerk, Resnick's "Designing for Wide Walls". Designed from the literature.
Status: Built (checked in the code, not yet tested end to end). The design note still says "not yet built".
Not known yet: The 8-element cap is not measured on the old iPad. The word list is "200+" in the note and roughly 270 by a rough count, unverified. How many names to pre-curate is open. Boards do not yet feed the growing song.
3.13 Sound machines (Klangmaschinen)
What you see and do. A pegboard of gears, hammers, bells and marbles that plays itself, opening on a running machine. A child places parts, rotates them and draws belts. Every edit can be undone. Each rotating part has a timer ring; hitting the right pad when it flashes makes the part evolve for a few cycles. Missing shows nothing.
How it works. 32 elements in five families on a 16 by 10 peg board. Gears mesh by tooth count; falling objects bounce at 80 to 88 %. Every sound is scheduled to the next grid step, by default an eighth note, so a busy machine grooves. Limits in code: 16 objects (12 in light mode), 12 links, 24 marbles. A good hit raises a stage for 4 cycles. The one score is the highest stage held, shown as a badge, not points.
Why. The brief of 2026-09-15 asked for "rotating generative objects that generate sound when colliding". The notes cite the Wintergatan Marble Machine, Newton's cradle, Chladni plates, Patatap and Toussaint 2005. The stage rule follows rules against streaks, random rewards and nagging. Designed from the literature.
Status: Built (checked in the code, not yet tested end to end). The design note still says "not yet built".
Not known yet: The object cap is not measured on the oldest iPad; the note's 20 was by analogy. Open: a visible line for proximity links, and whether saved machines restore their stage. Starter machines are planned.
3.14 Jazz generators, Jazz Jam and the growing song
What you see and do. A rule-based generator writes new jazz-flavoured phrases, so melodies feel fresh and cannot be somebody's tune. In Jazz Jam, two or more players each get a drawn instrument. Thin falling lines are invitations, never orders. Keys snap to the key's pentatonic scale, so every hit sounds good. A miss does nothing. After two quiet bars the band plays that player's lines, so the music never stalls. The growing song adds each playthrough to one long-running song, a little more complex each time.
How it works. The generator stores grammar, not tunes, with one seeded random stream, so a seed gives the same phrase in every browser. Complexity runs 0 to 1 (2 to 8 notes, 76 to 120 bpm); it rises 0.02 per success and falls 0.01 after two misses. The jam has five chapters (three in the short jam) at 84, 92, 92, 96 and 108 bpm, about 305 s long and 151 s short. A silent round adds nothing to the growing song.
Why. On 2026-09-15 I asked for jazz-inspired melodies so there are no boundaries to copyright, and for every playthrough to build the song. My early trial notes record children as "interested but quickly frustrated when the interaction was not completely clear".
Status: Built (checked in the code, not yet tested end to end). Feeding the growing song from Band Build is Designed, not built.
Not known yet: One header says ten minutes, the generator about 5 and 3.
3.15 Profiles, family lock and instruments that remember you
What you see and do. A profile is an animal avatar plus a name, stored on the device. To pick a name without typing, a child taps an animal, then one of five generated names. A grown-up PIN is a family lock; the page says it is a lock, not a safe. Plugging in a known instrument loads that player's profile, level, pad map and latency offset.
How it works. Instruments are recognised by manufacturer plus name, not the port id, which changes on Windows. Settings are stored per instrument, so a second child inherits the pad map and brings only a level. A four-digit PIN with a local hash can be guessed by a script in seconds.
Why. A child who cannot read cannot type a password, and "every byte that never leaves the machine is a byte nobody has to trust us with". The PIN decision of 2026-09-15 was "on the device plus backup, not on any server".
Status: Built. The name picker is from the design note; the family lock is Built (checked in the code, not yet tested end to end).
Not known yet: A later change to ask who joined, instead of guessing, is in the history but not in my notes.
3.16 Instruments and input routing
What you see and do. Presets exist for a reference electronic drum kit and a 37-key mini keyboard over USB MIDI. A Connect wizard asks a drummer to hit the drums left to right. The laptop keyboard plays piano: the home row gives white keys with A as C. A phone or tablet running the same site becomes an instrument that can be given to player 1 or 2. Knobs and faders map to effects, mixer values or lanes.
How it works. Presets assume General MIDI percussion notes; the wizard's map overrides them. Two earlier laptop layouts were judged not understandable. The phone sends note and control messages through the same path as a real port, over the local network through a small relay or between tabs. Limits: 4096 bytes and 64 events per message, away after 6500 ms. Every message is treated as hostile and checked. WebRTC and a public relay were ruled out, since every drum hit would round-trip through the internet. Safari has no MIDI at all.
Why. A drummer does not know the snare is note 38. On 2026-09-13 I asked to map letter keys to piano keys and to add a phone option.
Status: Built (checked in the code, not yet tested end to end).
Not known yet: Presets are starting points, marked unverified. Phone control works only when the app starts with the relay. Wi-Fi latency between phone and computer is not measured.
3.17 Mixer, effects, text modes and output windows
What you see and do. Every instrument and sound is a track with gain, pan, mute, solo and an effects rack. Fourteen effects: filter, eq, reverb, delay, drive, bitcrush, chorus, flanger, phaser, tremolo, autopan, compressor, gate and a voice changer. Every screen works with zero words; text modes are off (the default), English, and English with German tagged DE. Extra browser windows can show the visuals on projectors.
How it works. Solo is computed without changing mute flags. Rewiring a rack ramps output to zero over 8 ms to avoid clicks. Reverb uses generated noise. On Safari 12.1 two heavy effects are off by default.
Why. On 2026-09-13 I asked for effects on every track, "some nice options for children to try" and synth options for his own production, and on 2026-09-12 for all text to be optional with German clearly marked.
Status: Built (checked in the code, not yet tested end to end). Text modes are Designed in the note, widely used in code.
3.18 Where the notes and the code disagree
Several older design notes still say "not yet built" for features whose code says it is the working version. For about a dozen features I relied on the top comments of the code, not on running the app: Band Build, the sound machines, the growing song, the singer lane, Karaoke Pro, the sky sound and sky song, the family lock, the jazz generators, the mixer, effects and input routing. I wrote their status as "Built (checked in the code, not yet tested end to end)". I will not call them tested until I have used them.
Other mismatches:
Machines object cap: 20 in the note, 16 (12 in light mode) in the code.
Band Build word list: "200+" in the note, roughly 270 in the code.
Pitch knob: semitones in the note, scale steps in the code.
Profiles: the note says no sign-in, the code adds a grown-up PIN.
Avatars: coloured in the note, monochrome and angular in the code.
Jazz Jam length: ten minutes in one header, about five in another.
Growing song: planned in the Band Build note, present in code.
None of these features has been used by a child in a study. What they do on real microphones and old iPads is not known yet.
LINKS
4. Safety, privacy and platform
momo is meant for children aged about 3 to 10, so I wrote down what it must never do early on. This section covers that rule set, how I track it, which rules are met, and the platform choices that let momo run on old tablets without a server.
One caution first. momo is designed to follow the laws and guidelines named below. Compliance is not audited by a lawyer, and nothing here is legal advice.
The rule set and what it is based on
The rule set is a document of 61 numbered rules for children's apps, first written on 15 September 2026. Each rule has a plain statement, a reason and a source, and unread sources are marked unverified.
The sources, named as the document names them:
GDPR, the EU data protection law. Article 8: a child's own consent is valid only from 16 in Germany. Article 5(1)(c): keep only the data you need. Articles 12 and 13: tell people plainly what you hold.
The ICO Children's Code (Age Appropriate Design Code) from the UK regulator, with 15 standards, as a baseline although momo is hosted in the EU.
TDDDG § 25, formerly TTDSG, the German rule on storing things on a user's device: no consent needed when it is strictly necessary for a service the user asked for.
COPPA, the US children's privacy rule (version of 22 April 2025), as a checklist of what is never collected.
Apple and Google store rules, relevant only if momo is ever wrapped as a store app; WCAG 2.2 and its 2.3.1 flashing limit; WHO-ITU H.870 and EN 71-1 for sound; USK, PEGI and the German JuSchG; and the EU Digital Services Act guidelines on minors (July 2025).
Research cited per rule, for example on manipulative design in apps for young children (Radesky and colleagues, 2022), praise (Kamins and Dweck, 1999) and rewards (Deci, Koestner and Ryan, 1999).
Some research is correlational or US-centred. The rule document says so.
How rules are tracked
A rule is only useful if I can see whether the app meets it. So the rule document is a ledger: every rule has a source and a state.
Built: the app meets the rule today.
Partly built: some of it is met, or it is met in one place but not everywhere.
Designed: the rule is written down but the app does not meet it yet, or it applies only once something else exists.
Of the 61 rules, 27 are Built, 32 are Partly built and 2 are Designed (store readiness, and telling a child that parents can see progress). These counts come from the notes, not from an outside review.
The ledger also has a gap table, one row per open item, written on 15 September. It went stale fast, because I kept building. On 14 October 2026 it was re-checked row by row, by reading my notes and the code (nothing was run), and the result is mixed on purpose.
Verified in code: the grown-up gate and its call sites, the privacy section, the reset and forget tools, the flash cap, the focus ring, the music player autoplay, the animal count, and the missing undo on clearing a loop.
Verified only in notes: screen-reader names following the language, shorter songs and the new learning switches.
Not re-checked: the review of song words, the representation check, some touch target sizes, studio note dragging, colour-only duet lines and visual help for listening challenges. These keep their original mark.
What changed: the gate row said "no gate anywhere" but the gate is built and wired in several places, so it is Partly built because I cannot confirm full coverage. "No flash cap" is now true only outside Music Visuals. "No privacy page" is out of date. Still open as written: autoplay of the next song, a headphone volume hint, and undo for clearing a loop.
Data and storage
The plain rule: momo keeps what a child makes on the child's own device, sends nothing anywhere, and asks for nothing it does not need. "Local-first" means the device is the home of the data, not a server.
Collect nothing that would need a child's consent.: State: Built
Keep only an animal, an optional name, a level and simple stats.: State: Partly built; Note: Reset, forget and backup tools exist. A single screen listing everything stored, with sizes, does not.
No third-party analytics, ads or trackers, and no network calls while running.: State: Partly built; Note: One opt-in exception, a player for a pasted link, now behind the gate. A call to a music service with a user-supplied token is not confirmed to be gated.
Use storage only for what the family asked for.: State: Built; Note: The published site also has a password with a login cookie, which my rule document does not discuss.
Meet app-store kids category rules before any store listing.: State: Designed; Note: Not applicable today: momo is a website. No standalone privacy policy page or imprint.
Imported songs and words stay on the device and are an adult's action.: State: Partly built; Note: The file picker is gated. Whether a child can reach the words panel was not re-checked.
Local-first storage, no tracking. Everything momo remembers stays in the browser: profiles, settings, words, imported songs, favourites, progress. Small items sit in the browser's local storage and imported recordings in IndexedDB, the browser's database storage. No analytics, ads or trackers. A child cannot consent under GDPR in Germany before 16, so the safest design holds no data that needs it. Status: Built, with the one opt-in exception above. Not known yet: how the site password cookie fits my statement that no cookie notice is needed.
Accounts and profiles
The idea: a child is an animal, not a name. A four-year-old cannot read a name, so picking an animal is who you are.
Children enter without passwords, puzzles or memory tests.: State: Built; Note: The adult PIN and the site password are adult side only. Some older notes still say "no accounts".
Removing a child's work can be undone or asks first.: State: Partly built; Note: Removing a saved player asks with a clear warning. Clearing a loop has no undo.
Grown-up account and PIN.
What it is. A family lock on the device: one grown-up PIN, children who pick an animal, and a backup file. No server. The account page says it is a lock, not a safe.
How it works. The PIN has 4 to 8 digits and is stored as a salted PBKDF2 SHA-256 hash over 100,000 rounds. Five wrong tries lock that login for 30 seconds, doubling per further miss up to 5 minutes. A login lasts for the tab only. The backup is a file holding names, animals, progress and PIN hashes, to be kept like a photo album. "Reset everything" needs the word DELETE typed.
Why. Data lives on the device plus a backup, never on a server. The honest limit: a four-digit PIN whose hash sits on the device can be guessed by a script in seconds.
Status. Built.
Profiles, avatars and what they wear. A profile is an animal plus an optional generated name, so no typing is needed. The code defines 16 animals (older notes say twelve), drawn flat with soft rounded eyes because hard geometric eyes read as menacing. The animal wears only what the child's growing music flower has earned, from nothing to a crown with sunglasses, at 15, 90, 230, 450 and 680 sound seeds. It is a fixed ladder with no chance in it. Status: Built. Not known yet: whether this fully meets my rule that rewards be few and not the point. A grown-up page also lists every character ever made on the device, including deleted ones.
Outbound links and the grown-up gate
The plain rule: nothing a child can tap should leave momo, and anything that opens the internet or keeps a file needs an adult first.
Nothing a child can tap leaves momo.: State: Partly built; Note: Embedded players are gated. A button copies a link to an outside pattern site; I did not click it to confirm it only copies.
One gate for the parent area, links, embeds, imports and microphone setup.: State: Partly built; Note: The gate is built and wired in several places. Full coverage is not confirmed.
Grown-up gate.
What it is. A speed bump asking an adult to do two things before something opens that reaches the internet or keeps a file. It is not security.
How it works. Step one: hold a button for 3 seconds with a visible fill. Step two: read a number word such as "sixty-three" (German or English) and tap its digits among 4 choices. The number runs from 21 to 99 with two different non-zero digits, and one wrong choice is the digits swapped (36 for 63) to catch guessing. A pass lasts for the page session only and is never saved. A child logging in ends it.
Where it is wired. The link player, file import, video band, YouTube, and the grown-up panel and first microphone explanation in lessons. Not found: a gate on the front page footer or the copy-link button in the pattern box.
Why. An audit on 15 September found a child could open YouTube from inside the playground. Apple expects gates to be adult-level tasks.
Status. The gate is built. Coverage of every outbound point is Partly built.
Rebuild from a link. A grown-up pastes a YouTube, SoundCloud or Spotify link and the official player is embedded, only after the gate is passed. It is the one place momo contacts other services. Status: Partly built. Not known yet: whether the music service call is gated.
Flashing and motion
The plain rule: a child hammering pads must never produce a strobe.
Never flash a large bright area more than three times a second.: State: Partly built; Note: Built for Music Visuals only. The small hit flashes in the play screen have no confirmed rate cap.
Text and control edges have enough contrast.: State: Partly built; Note: Main text 15.7:1, dim text 7.6:1. Control edges 2.1:1, below the 3:1 target.
Flash cap.
What it is. Music Visuals limit how often a large bright patch or saturated red can flash. Beyond three big flashes in a second, further ones become a soft glow.
How it works. A limiter sits between every scene and its large brightness changes (a quarter of the picture or more). In any 1 second window the first three pass at full strength; the fourth and later get 0.25 strength with a fade of at least 0.4 s. A 10 percent step in relative luminance counts, and so does a large saturated red change. With reduced motion, large pulses do not happen and camera movement runs at about 0.35 speed. Brightness from the camera passes the same cap. Small marks such as a note's glow are not capped.
Why. WCAG 2.3.1: flashing can trigger seizures in photosensitive people.
Status. Partly built: Music Visuals only.
Not known yet. The luminance steps are estimated, not measured on a screen. The hit verdict flash and shockwave ring have no confirmed rate limit.
Sound levels
A limiter on the master output, always.: State: Built; Note: A test render that peaked at 1.12 without it stays under the ceiling with it. Light mode keeps it.
Headphone guidance: start quiet, tell adults the volume is set on the device.: State: Partly built; Note: Microphone monitoring is headphones only and off by default. No hint for adults found.
Never feed a microphone back through speakers.: State: Built; Note: Speaker monitoring is refused, and a howl guard stops feedback.
Limiter and calm start.
What it is. Every sound passes one limiter before the speakers, and every challenge starts calmly.
How it works. The voice bus has a gentle compressor into a fast limiter, and the studio master has a limiter by default. A miss plays no sad sound. Karaoke voice level is capped at 150 percent of input.
Why. WHO-ITU H.870 sets stricter weekly allowances for children. A browser app cannot measure sound pressure at the ear, so I limit and start calmly instead. A microphone near a speaker howls within seconds, which is frightening for a young child.
Status. Built.
Not known yet. The level of count-ins and of some cues relative to the music was not measured.
Microphone and camera use
The plain rule: a child's voice and picture are among the most sensitive data there is, so momo analyses them as they happen and keeps nothing.
Never record, store or upload a child's voice.: State: Built; Note: Audio is analysed frame by frame and discarded. There is no recorder.
An adult prepares the first microphone request.: State: Partly built; Note: Lessons show an adult explanation behind the gate. Band play and karaoke were not re-checked.
The camera stays on the device, shows when live, keeps nothing by itself.: State: Built; Note: See below.
Camera and photos.
What it is. The camera is used only for a photo the child deliberately keeps, or as a live input for Music Visuals.
How it works. One shared local stream, no network. A first-use card for adults appears before the browser asks, and a "Camera on" sign shows while live. A photo is stored only after the child taps "Use". Visuals sample a 160 pixel frame in memory and keep nothing.
Status. Built.
Notifications, time and dark patterns
Dark patterns are design tricks that push people to keep using an app. momo sends no notifications at all, because it has no server and no child account to send them to.
No streaks or daily login pressure.: State: Built; Note: Stars never go down.
No purchases, ads or virtual currency.: State: Built; Note: No payment or advertising code found.
No autoplay chains.: State: Partly built; Note: The music player still moves to the next song by itself.
Also Partly built in this group: the "welcome back" message must stay free of any request; stars show on result cards; there is no "one more song" option for adults ending a session; and karaoke still shows an evening board, which is a ranking. Built: no streaks, no random rewards, no purchases or ads, natural ends to challenges, and praise that names the action, not the child.
Parents page and privacy section
Tell parents plainly what momo does with data.: State: Partly built; Note: A privacy section now exists. No imprint found.
A parent area that shows and removes everything stored.: State: Partly built; Note: Reset, forget and backup exist. A list with sizes does not.
Parents page.
What it is. A hub for adults: what momo is, how to use it with children, and what happens to the data.
How it works. Four sub-pages cover use with children, how children learn, the rules for children's apps and how to help build it. The privacy section has five bullets: data lives in the browser; no tracking; microphones are not recorded; YouTube only behind the gate; delete data through the browser's site settings.
Status. Partly built.
Not known yet. Whether an imprint is needed depends on the operator's situation. I must check before wider publishing.
Insights page. A private progress dashboard on local data only: the child sees their own growth, the grown-up a fuller view. It keeps at most 600 raw events per profile over 90 days and only whitelisted fields, with no names, free text, audio or clock times. A grown-up can export an anonymous share file after ticking consent and seeing the exact content; nothing is sent automatically. Status: Built. The adaptive hints (review sooner, never "go down a level") are Designed, since I did not confirm the lesson code calls them. Not known yet: whether the share file was ever used.
Accessibility and language
Every screen works with words off (three text modes, an icon on every label), and German is a full translation with German music terms. Partly built: the play and front pages still declare English as page language, some small controls are under the 44 px target, a visible focus ring exists globally but is not tested per browser, and canvas state is not exposed to screen readers as text.
Platform features
Old-device support.
What it is. The app must start on an iPad Air from 2013 running Safari 12.1, the oldest browser I support.
How it works. In the app's own code I ban optional chaining, the nullish operator, class fields and CSS gap, because one such token makes a file fail to parse and the child sees a blank page. The project had eight, fixed on 12 September. Safari has never supported Web MIDI, so instruments work on an iPad only inside a free Web MIDI Browser app; touch pads work when no MIDI exists.
Why. I want it to work on hand-me-down tablets.
Status. Built as rules. Not known yet. Whether it runs well on a real iPad Air from 2013.
**Light mode and performance readout.
What it is. A mode that cuts cost, never content, plus a readout showing what hurts.
How it works. At most 10 voices sound (otherwise 40), fire has 90 particles at 30 fps (otherwise 210), and canvases use 1x pixels. It turns on by a setting or automatically on iOS 12 or older, two cores or fewer, or a median frame over 40 ms. Adding ?perf=1 shows frame times and voices.
Status. Built. Not known yet. Whether 10 voices is right on a real iPad.
Offline and no build.
What it is. momo runs from plain files. Edit a file, reload, see the change.
How it works. A small Python 3.9 server using only the standard library serves on 127.0.0.1:8790. Third-party code is kept in the project, with no CDNs. The published site is built by a script that only filters files, fixes paths, strips comments and bundles scripts, cutting play page requests from about 110 to 11.
Status. Built.
Open source licence. momo's own code is under the GNU Affero General Public License v3 (AGPL-3.0), and contributions use the same terms. Third-party parts keep their own licences (AGPL-3.0, MIT, BSD-3-Clause, public domain). Status: Built.
Design system and look. One look for the whole app: flat vector icons only (about 130), no emoji, little clutter, buttons 44 px high. An emoji looks different on every device and is an empty box on an old tablet. On phones only four or five main actions show, the rest sit behind "More" and "Advanced". Status: Built.
Phone as controller.
What it is. A phone becomes a drum pad, keyboard or knob controller that sends notes to the main screen.
How it works. Three faces: four big pads, two octaves of keys, and faders with an XY pad. Messages enter the same path as a real MIDI port. It needs the home server started by an adult in a local network mode with six guards, among them a private address only, a secret path and one write path. Every message is checked twice: integers in MIDI ranges only.
Status. Built.
Probes for MIDI and devices. Small test pages that measure instead of guess: a device probe that ends in a verdict from "full player" to "not usable", an iPad check in large type, and a MIDI probe that records which note number each drum pad sends. Status: Built.
Deploy.
What it is. One script assembles the folder for the website from an allow-list.
How it works. HTTPS only, with a one-year HSTS header, and a server-enforced password: five wrong tries from one connection wait 15 minutes, and logins last a year. A browser test walks every page at desktop and phone width.
Status. Built. I did not exercise the lock for this check, so I rely on the change log.
What was built when
Dates come from the plain-words change log. Dates before 15 September come from other notes, and the project's version history starts on 15 September, so those cannot be checked against commits.
2026-09-12 to 2026-09-14 (other notes): old-device rules written and eight unsupported syntax tokens fixed; device probe, MIDI probe, touch pads, light mode and the performance readout built; phone control requested; four more animals.
2026-09-15: play app opens with its main games, 39 short lessons in six stages, the music flower, accounts with a grown-up PIN, favourites, local insights and backup, a front page with a real sky, flat icons, one volume limit and the grown-up gate before YouTube, links and file import. The same day I wrote the rule document.
2026-09-16: levels reach 25 in seven chapters; karaoke voice chain with howl guard; the site ships security headers and its licence.
2026-09-17: screen-reader names follow the language; play page requests fall from about 110 to 11; an automatic browser test is added.
2026-09-18 and 2026-09-19: avatar accessories grow with the music flower; every key and pad of a plugged-in instrument is shown.
2026-09-23: instruments work on an iPad through the Web MIDI Browser app; calm start with count-in dots.
2026-09-25: every challenge opens while building, with an "Unlock everything" switch.
2026-09-25 (evening): server-enforced site password.
2026-09-29: new challenges; two grown-up learning switches; a saved player can be removed with a warning.
2026-09-30: category buttons show words again.
5. How it is tested, and what is not known
How momo is used and tested today
I test the app myself, and in short play sessions with my own children and me. The sessions are informal. They are not a study: nobody is measured, nothing is recorded, and no child's name, voice or picture enters any file that leaves my computer.
I also asked several colleagues for feedback in conversation. Nothing was written down at the time, so I treat it as context and not as a finding. It shaped the questions, but I do not cite it as evidence. I am writing the remembered points down in a fixed short template, and anything that survives that will appear here with the date it was recorded.
Evidence levels used on this page
Built: it exists in the running app
Designed: it is documented and reasoned, not built
Measured: a technical number was measured (for example a delay in milliseconds)
Observed: seen in informal use, with a written note
Hypothesis: a claim that could fail and has not been tested
Unverified: a source or number I have not been able to open and check
Contested: the research literature disagrees
What is not shown
No efficacy data. Every learning rule is designed from the literature. None is shown by momo to make children learn faster or better. This is a design rationale with technical measurements, not an effectiveness study.
Hypotheses, none tested yet:
H1: age lanes on one shared clock keep a 4-year-old and an 8-year-old each inside their own success zone on the same piece.
H2: a parent with a real role in the game stays longer and plays better than a parent who only supervises.
H3: showing sound as shape and movement lowers the explanation a child needs before playing.
H4: short sessions with a visible end bring more voluntary return than long open ones.
H5: an automatic difficulty nudge keeps the failure rate in a band without the child noticing a change of level.
Timing over Wi-Fi is not measured. The only measured delay is a local loopback test.
Adults learning music beside children: the evidence I have is blog-grade only.
Contested ground: praise that targets effort and the "growth mindset" claims are disputed in the literature; momo follows the cautious reading and says so.
Notes versus code: in places my older design notes say "not yet built" where the code exists, and in places the reverse. Each section lists the differences it found.
What comes next
A two-minute session note after each family session (challenge played, age lane, minutes, who chose the next step, what went well, what broke the fun), kept private, with only aggregated numbers moving to this page.
Written-down colleague feedback in the same short template.
A timing measurement over a home network.
An ethics route before any session with other families or a school.
Cite, reuse, contact
Cite as: Moritz Richartz, momo: shared play across ages (research page, work in progress), mojari.de. The app code is AGPL-3.0; third-party code and music are listed in the repository. Contact: via the contact section of mojari.de.