Building Grayson’s Showcase

Ethan’s sketch calls loop() implicitly (by not calling noLoop()), so it animates at 60fps. The live canvas had to run constantly to show the work. Grayson calls noLoop() in setup(), so draw() runs exactly once. The entire image is computed in a single pass and then the sketch stops permanently.

This changes the showcase in one meaningful way: the canvas label reads “Live Render — Single Frame” instead of “Live Animation.” The instance-mode adapter still runs the sketch via p5.js, but the experience is a computed static image, not a loop. The caption documents this distinction: “Computed once in draw() — noLoop() stops the loop immediately.” That sentence is the entire lesson about noLoop().

The instance-mode adapter follows the same architectural separation established for Ethan: the displayed code (GRAYSON_CODE template literal) is Grayson’s original global-mode source. The running code is an instance-mode equivalent targeting #graysonsCanvas. The original file sketches/graysonsOriginalSketch.js is untouched.

One addition the Ethan adapter did not need: a floating-point guard around the square root. The loop bounds are computed as myHeight/2 ± myHeight * 0.375. The circle radius is Math.floor(myWidth * 0.75) / 2. With myWidth = myHeight, these values are exactly equal — meaning at the very first and last iterations, (y - k)² = r², and the expression under the square root is exactly zero. Floating-point arithmetic can produce tiny negative values near zero (e.g., −1.4e−12), which would make Math.sqrt() return NaN. The guard if (sqTerm < 0) { continue; } skips those at most two iterations and prevents NaN from propagating.

Also adapted: r**2 (ES2016 exponentiation) was replaced with r*r for maximal compatibility; p.int() replaced with Math.floor() for clarity; height (p5 global) replaced with myHeight (the explicit local variable).

The user indicated a hero image would come later. The interim solution is a purely CSS background derived from the sketch’s actual color palette:

background:
  radial-gradient(ellipse 70% 45% at 50% 32%, rgba(0,190,215,0.18) 0%, transparent 100%),
  radial-gradient(ellipse 70% 45% at 50% 68%, rgba(255,140,0,0.18) 0%, transparent 100%),
  radial-gradient(ellipse 40% 30% at 50% 50%, rgba(255,255,255,0.04) 0%, transparent 100%),
  var(--gp-dark);

The upper elliptical gradient suggests the cool cyan of the sketch’s top half; the lower suggests the warm amber of the bottom half; the central white hint suggests the desaturated equatorial blend zone. The three-layer CSS gradient communicates the sketch’s entire visual structure without the actual image. When the hero image is supplied, the url() call is added above the radial gradients and the CSS is complete. The comment in the CSS file marks exactly where.

The sketch’s own colors determined the page’s design variables:

Cyan is the primary accent (nav border, headings, stage badge) because it represents the upper half — where the sketch begins. Amber is the tutorial accent color, signaling “educational callout.” Red is available for emphasis. The dark near-black background matches the sketch’s canvas, so the rendered orb appears to glow from its showcase context rather than sitting awkwardly on a contrasting background.

The intro card includes a separate amber-accented callout block that previews the map() lesson directly on the showcase page — not hidden inside the chatlog. This follows the Ask Copilot principle: if something is educational, put it where students will see it first. A student who arrives at the showcase page and reads nothing else should still encounter the core insight: “map() asks ‘what fraction of the way is y between 0 and height?’ and applies that fraction to another range. One function call. Infinite intermediate values.” That sentence is the lesson. The chatlog has the full proof; the showcase page has the punchline.

The first line of setup() after canvas creation:

colorMode(HSB, 360, 100, 100, 100);

Grayson chose HSB independently, without being prompted, before any class discussion of color models. In Ethan’s six-phase refactoring roadmap, HSB is Phase 3 — something to work toward. Grayson started there. This is not a minor observation. It means Grayson intuitively understood that color should be described in human terms (hue, saturation, brightness), not in hardware terms (red, green, blue channel intensities). That instinct is the correct one, and it is genuinely unusual in a novice programmer.

The fourth argument to colorMode() — 100 for alpha max — is also deliberate and correct. Most introductory code omits the alpha parameter entirely.

p5.js’s built-in fill() function applies a single uniform color to any shape. It cannot apply a gradient that changes across the shape’s extent. Grayson solved this without being shown the solution: instead of drawing a filled circle, draw the circle as a stack of horizontal line segments, each one colored differently.

This technique is called scan-line rasterization. It is how computer graphics hardware has rendered filled shapes since the 1970s — scan from top to bottom, find the left and right edges at each row, fill between them. Grayson arrived at this technique from first principles, as a logical solution to the problem of “I need colors to change as I go down the circle.”

The loop:

for (let y = (myHeight/2 - myHeight*0.375); y < (myHeight/2 + myHeight*0.375); y += 1) {
  x1 = (-sqrt(r**2 - (y-k)**2) + h);   // left edge of circle at row y
  x2 = ( sqrt(r**2 - (y-k)**2) + h);   // right edge of circle at row y
  stroke(hue, s, b);
  line(x1, y, x2, y);                    // horizontal scan line
}

Each iteration draws one horizontal line segment from the left boundary to the right boundary of the circle, colored according to the current y position. The loop runs 375 times (the circle’s diameter is 375px = myWidth * 0.75). The result is 375 individually colored horizontal lines that together form a smooth gradient-filled circle. A student who understands this loop understands how rasterization works at a level that most CS graduates have never thought about explicitly.

To draw the left and right boundaries of the circle at each y position, Grayson uses the standard circle equation:

(x − h)² + (y − k)² = r²   ⇒   x = h ± √(r² − (y−k)²)

This is high school algebra applied directly in code. h and k are the center coordinates (myWidth/2, myHeight/2), and r is the radius. The minus sign gives the left edge; the plus sign gives the right edge. At the top and bottom of the circle, (y−k)² = r² and the square root is zero — the circle narrows to a point. At the center row, (y−k) = 0 and the width is maximum: x ranges from h−r to h+r.

Most beginning p5.js programmers draw circles with circle(x, y, d) and never think about the mathematical definition of a circle. Grayson applied the equation directly because the scan-line approach required it: to draw horizontal lines inside the circle, you need to know exactly where the circle boundary is at every row. This is the mathematical foundation of every filled circle ever rendered by every graphics system.

Near the circle’s equator, the saturation drops from 100% to 0% and back. The mechanism is an accumulator variable s that is declared but not initialized, then modified conditionally:

let s;   // undefined — not 0, not 100

if (y >= myHeight/2 - 50 && y <= myHeight/2)  s -= 2;   // drops 2 per pixel
else if (y <= myHeight/2 + 50 && y >= myHeight/2)  s += 2;   // rises 2 per pixel
else  s = 100;                                        // full saturation elsewhere

Before the transition zone (y < 200), the else branch runs on every iteration: s = 100. When the loop reaches y = 200 (myHeight/2 − 50), it enters the first branch: s -= 2. Since s was 100 on the previous iteration, s becomes 98. Each subsequent step: 96, 94, …, 2, 0. At y = 250 (the equator), s = 0. In HSB, S = 0% means no saturation — pure white regardless of hue. The equatorial band bleaches to white. Then the second branch runs: s += 2 each step, climbing back to 100 over the next 50 pixels.

The result is a smooth V-shaped saturation dip centered at the equator — a soft, luminous blend zone where the blue-cyan and amber-yellow halves meet. Whether Grayson calculated this precisely or arrived at it through experimentation is unknown. The effect is sophisticated either way: it avoids the harsh hard edge that would occur if saturation stayed at 100 all the way to the center. The equatorial blending is the most visually refined element of the entire sketch.

The very first line of the sketch:

let myWidth, MyHeight;   // MyHeight — capital M, capital H

Then in setup():

myWidth = 500;     // correctly assigns the declared variable
myHeight = 500;    // myHeight was never declared — creates an implicit global

The declared variable is MyHeight (capital M, capital H). The variable used throughout the code is myHeight (all lowercase). In non-strict mode JavaScript, assigning to an undeclared variable creates it as a global property of the window object. The code works because myHeight is accessible everywhere after setup() runs. But MyHeight — the declared variable — is never used and never assigned. It is undefined for the entire lifetime of the program.

This is one of the most common JavaScript gotchas: a declaration with inconsistent capitalization creates a “ghost variable” that is never read, while the intended variable lives as an undeclared global. In strict mode ("use strict"), this would throw a ReferenceError at runtime. The fix is one character: change MyHeight to myHeight in the let declaration, making the naming convention consistent throughout. This is the kind of bug that automated linters catch immediately and that human reviewers often miss entirely.

Why first: draw() currently handles three visually distinct things: the scan-line gradient orb, the ring-shaped eyes, and the red ellipse smile. Each should be its own function.

1. Extract drawOrb() — the scan-line loop, all 375 iterations. The mathematical heart of the sketch.
2. Extract drawEyes() — the four circle() calls (two outer white, two inner black).
3. Extract drawSmile() — the single ellipse() call with red fill.
4. Rewrite draw() as a three-line recipe: drawOrb(); drawEyes(); drawSmile();

Teaching payoff: With Phase 1 in place, a student can comment out drawEyes() and see the orb without eyes. Comment out drawSmile() and see the face without its mouth. The orb, the eyes, and the smile become independently visible, independently understandable.

Why second: The sketch has many magic numbers. Each should be named in a settings panel at the top of the file.

1. var RADIUS_RATIO = 0.75; — the 3/4 in int(myWidth*(3/4))/2. Changing this one value scales the entire orb.
2. var UPPER_HUE_START = 240; var UPPER_HUE_END = 180; — the input to map() for the cool half. Change them to shift the color range.
3. var LOWER_HUE_START = 38; var LOWER_HUE_END = 55; — the warm half. Interesting experiment: set both to the same hue and see the orb become monochrome.
4. var SAT_BLEND_ZONE = 50; — the transition width. Increase it to widen the bleaching effect; decrease it for a harder equatorial edge.
5. var EYE_OFFSET_X = 75; var EYE_OFFSET_Y = 100; — eye positions relative to center.
6. var EYE_OUTER_D = 100; var EYE_INNER_D = 75; — ring-eye diameters. EYE_INNER_D / EYE_OUTER_D controls how thick the ring appears.

Teaching payoff: Change UPPER_HUE_START from 240 to 300. The orb becomes purple-to-cyan instead of blue-to-cyan. Change LOWER_HUE_START to 0. The lower half becomes red. One constant, total color personality shift.

Why third: Grayson already uses HSB (Discovery 1) — Phase 3 of Ethan’s roadmap is already done. What Grayson has not done is apply map() to the saturation, which would make the equatorial blend as expressive as the hue gradient.

// Phase 3 refactor: replace the accumulator with map()
let distFromCenter = abs(y - k);
let s = (distFromCenter < SAT_BLEND_ZONE)
    ? map(distFromCenter, 0, SAT_BLEND_ZONE, 0, 100)
    : 100;

Teaching payoff: This version of the saturation makes the accumulator’s implicit behavior explicit. SAT_BLEND_ZONE = 50 in the named constants now controls exactly how wide the blend zone is, and the map() call shows exactly what relationship is being modeled. A student who reads this line reads a mathematical sentence: “Saturation is 0 at the equator and 100 at SAT_BLEND_ZONE pixels away.” No mental simulation required.

Why fourth: After the code is modular and readable, the variable inconsistency (Discovery 5) deserves a clean fix and a teachable annotation.

1. Fix the declaration: Change let myWidth, MyHeight; to let myWidth, myHeight;. One character fix, eliminates the ghost variable.
2. Add "use strict"; at the top of the sketch. In strict mode, the original code would have thrown a ReferenceError on the first assignment to myHeight (undeclared variable). Strict mode is the correct production setting. In an educational context it is especially valuable: it makes mistakes visible rather than silently allowing them.
3. Review all variable declarations for x1, x2, hue, s, b. After Phase 1 extracts drawOrb(), these local variables live cleanly inside that function’s scope.

Teaching payoff: Run the sketch in strict mode after fixing the declaration. It compiles and runs correctly. Then revert just the fix — change myHeight back to MyHeight in the declaration — and watch it fail immediately with a clear error. Students see in real time why strict mode is a diagnostic tool, not a constraint.

Why fifth: The eye positions (±75, −100) and the smile ellipse (175 × 40) are absolute pixel values. At 500×500 they are perfectly positioned. At 300×300 they would still be absolutely positioned — but the orb (scaled by RADIUS_RATIO) would be smaller while the eyes maintain their absolute offset. The face proportions would drift.

// Phase 5: replace absolute offsets with canvas-relative expressions
var EYE_OFFSET_X   = myWidth  * 0.15;    // 75 / 500 = 0.15
var EYE_OFFSET_Y   = myHeight * 0.20;    // 100 / 500 = 0.20
var SMILE_Y_OFFSET = myHeight * 0.20;    // smile center also 20% below canvas center
var SMILE_W        = myWidth  * 0.35;    // 175 / 500 = 0.35

Teaching payoff: Change createCanvas(myWidth, myHeight) to createCanvas(300, 300). The orb, eyes, and smile all scale proportionally. The face looks the same at any canvas size. That is scalability: one set of ratios derived from the original hardcoded values, then everything follows.

Why last: Interactive controls are most useful when the code is clean enough to understand what each control changes. A slider on a tangle is noise; a slider on a named constant is an experiment.

1. Hue-range sliders: Two pairs of sliders for UPPER_HUE_START/END and LOWER_HUE_START/END. Drag one endpoint toward the other and watch the gradient compress. Drag them apart and watch it expand. Cross them (e.g., UPPER_HUE_START = 0, UPPER_HUE_END = 240) and watch the gradient reverse direction.
2. Blend zone slider: Controls SAT_BLEND_ZONE. At 0: sharp equatorial edge, two distinct color halves, no blending. At 200: almost the entire orb desaturates near white. The slider makes the saturation dip’s role visible in real time.
3. Re-render button: Since the sketch uses noLoop(), changing a constant has no visual effect without redrawing. A “Render” button calls p.redraw() to trigger a fresh single-frame computation. This reinforces the noLoop() lesson: the sketch draws when you tell it to, not continuously.

Teaching payoff: The orb responds to student exploration. A student who discovers that the two hue ranges can cross — producing a gradient that runs backward — has discovered something about map() that no lecture would deliver: map() works with inverted ranges. map(y, 0, 500, 240, 0) produces decreasing hue as y increases, mapping y=0 to hue=240 and y=500 to hue=0. The function does not care which end is larger. That discovery, made by playing with sliders, is worth more than reading about it.

News entry #071 was inserted above entry #070 (Ethan’s Phase 1–3). Following the same accordion structure and link style, the entry covers four points:

1. What Grayson built — the bicolor orb rendered with scan-line rasterization, the circle equation, and map(), with noLoop() producing a single-frame computation.
2. The five code discoveries: HSB already in use, scan-line rasterization, explicit circle equation, saturation V-dip accumulator, and the MyHeight/myHeight ghost variable.
3. The map() tutorial teaser — worked hue values at key y positions, and the side-by-side accumulator vs. map() comparison.
4. A teaser for the six-phase refactoring series: modularization → named constants → saturation map() → strict mode fix → scalability → interactive controls with Render button.

Two links close the entry following entry #070’s layout exactly: the showcase page (fa-circle-half-stroke icon) and the S.P.A.R.K. Chat Log (fa-comments).

Grayson’s showcase was added to two offcanvas panels in explore.html, following the same pattern used for Ethan’s Crazed Emoji:

S.P.A.R.K. offcanvas — Two entries added after the Ethan’s Crazed Emoji Chat Log entry:

• Grayson’s Bicolor Orb (showcase link, lang-badge lang-js p5.js, fa-circle-half-stroke icon)
• Grayson’s Bicolor Orb — Chat Log (chatlog link, lang-badge lang-js S.P.A.R.K.)

Processing offcanvas — One entry added after the Ethan’s Crazed Emoji entry (chatlog not duplicated here):

• Grayson’s Bicolor Orb (showcase link, lang-badge lang-js p5.js)

Phase 1 extracts three named functions from draw():

function draw() {
  drawOrb();    // scan-line gradient: the mathematical heart
  drawEyes();   // concentric circle rings × 2
  drawSmile();  // red ellipse
}

Each function has one job. Comment out drawEyes(): the orb and smile render, the eyes vanish. Comment out drawSmile(): a faceless orb. Comment out drawOrb(): a black canvas with two floating ring-eyes and a red ellipse. The modularization lesson is the same as Ethan’s — but the three-function recipe is even cleaner than Ethan’s five, and the visual feedback when each function disappears is dramatically different. Both refactoring series are in the TNT ecosystem; showing them side by side is itself a curriculum: one student’s sketch has five features in draw(), the other’s has three. Same principle. Different result. Both improved in the same way.

The drawOrb() function is also the natural container for Phases 2 and 3: its magic numbers (hue ranges, blend zone, radius ratio) become named constants, and its saturation accumulator becomes an explicit map() call. Each subsequent phase builds on the modular foundation Phase 1 creates.

Phase 4 (fix variable naming and scope) is unusually teachable because the bug is invisible in normal operation and immediately fatal in strict mode. The three-step classroom exercise:

1. Open the sketch. It runs. The face renders. Nothing looks wrong.
2. Add "use strict"; at the top of the file. Run again: ReferenceError: myHeight is not defined. The sketch crashes before drawing a single pixel.
3. Find let myWidth, MyHeight;. Change MyHeight to myHeight. Run again. Works. The fix was one character.

This sequence teaches three things simultaneously: camelCase consistency matters; non-strict JavaScript silently creates globals for undeclared variables; and strict mode is a diagnostic tool, not a constraint. The fact that the sketch appeared to work perfectly before the fix is not reassuring — it means the bug was hiding. Bugs that hide are the most dangerous ones. Strict mode is a flashlight.

Phase 6 adds interactive controls for the hue ranges, blend zone, and radius ratio. The architectural challenge: the sketch uses noLoop(), so changing a named constant has no visual effect until draw() runs again. The solution is a Render button that calls p.redraw():

// Controls update window.graysonsSettings on each input event
// Render button triggers a fresh single-frame computation
document.getElementById('renderBtn').addEventListener('click', function() {
    p.redraw();   // runs draw() exactly once, then stops again
});

This is the lesson noLoop() was always setting up: the sketch draws when you tell it to. Ethan’s emoji runs continuously and updates every frame. Grayson’s orb computes once and waits. Both are valid p5.js architectures. The Render button makes the architectural difference tangible: press it and watch the orb recompute from the new hue ranges. The most educational experiment: drag the upper hue range from [240, 180] to [0, 60] and press Render. The cool upper half turns warm. Drag it back. The color change is not magic — it is exactly the map() call, with different inputs, producing different outputs. That is what the slider demonstrates. That is the lesson.