Let me start by exploring the environment to understand what's available.

Let me check the Tone version and confirm it exposes a global `Tone`.

This is Tone.js version 14 (or later) since it uses `Tone.Synth` with a newer API. The minified version exposes `Tone` globally. Let me build the piano keyboard app.

Let me design:
- 88-key or a smaller keyboard. Let me do a full 88-key piano, but maybe a good range. Let me do 4 octaves or so. Maybe A0 to C8 full range? Let me do a reasonable range like A1 to C6 or a full 88. Let me do 88 keys for completeness but render compactly.

Actually, let me make a nice full 88-key piano (A0 to C8). That's the standard.

Controls:
- Mouse: click/drag on keys to play (polyphonic)
- Computer keys: map computer keyboard rows to piano keys. Classic mapping using keys Z X C V B N M for one octave starting at C, then A S D F G H J for next octave, etc. Let me use the common "midi" row mapping: 
  - Z = C4 (middle C)
  - X = D4
  - C = E4
  - V = F4
  - B = G4
  - N = A4
  - M = B4
  - Row A: A=Cs (C#), W... 

Actually let me use the standard mapping where:
- Bottom row (Z through / and comma etc.): white keys
- Top row (Q through ]): black keys (sharps)

Standard mapping:
Z, X, C, V, B, N, M  → C D E F G A B (C major)
S, D, G, H, J → C# D# F# G# A# (sharps)
Q, W, E, R, T, Y, U in top... 

Let me use the common layout used by many online pianos:

Row 2 (keys): Q W E R T Y U I O P [ ] 
Row 3 (keys): A S D F G H J K L ; 
Row 4 (keys): Z X C V B N M , . / 

Mapping:
- Z=C, S=C#, X=D, D=D#, C=E, V=F, G=F#, B=G, H=G#, N=A, J=A#, M=B
Then next octave: Q=C up. A=C#, W=D, S? wait S used. Hmm.

Let me use the classic "Octave" mapping extensively used:

Q W E R T Y U I O P = C D E F G A B C D E (white keys starting on Q)
2 3 5 6 7 9 0 = C# D# F# G# A# C# D# (black keys)
A S D F G H J K L ; = C D E F G A B C D E (white keys octave below)
W E T Y U etc = sharps

Actually a cleaner widely-used mapping (from Virtual Piano):
- Black row: `1 2 3 4 5 6 7 8 9 0 - =` for sharps in some, or QWERTY.

Let me just define with octave offset. I'll define:

White keys row (lower): Z X C V B N M , . /  → C D E F G A B C D E
Black keys row: S D G H J L ; → C# D# F# G# A# C# D#

Actually the standard mapping aligned so that:
C = Z (or Q). Let me pick base = A0 and map each key.

Let me choose a clean approach: I'll define keyboard mapping with two "rows" using the classic scheme where the keyboard mirrors piano layout:

Row of white keys (bottom, using letters): 
Z=A0? no. Let me base on C.

I'll set the lowest mapped note. Let me map:

White keys (z-row + a-row + q-row):
Z=C4, X=D4, C=E4, V=F4, B=G4, N=A4, M=B4, ','=C5, '.'=D5, '/',=E5
A=C5? No A=S-row is black.

Hmm conflict. Let me use this widely-known mapping:

Bottom row (Z..): C D E F G A B C D E F G A B...
To extend, use:
Z=C, X=D, C=E, V=F, B=G, N=A, M=B, , =C, . =D, /=E
A=C#? No.

The standard one that includes sharps:
- White keys on Q row and Z row:
  - Z = C4
  - S = C#4
  - X = D4
  - D = D#4
  - C = E4
  - V = F4
  - G = F#4
  - B = G4
  - H = G#4
  - N = A4
  - J = A#4
  - M = B4
  - , = C5
  - L = C#5
  - . = D5
  - ; = D#5
  - / = E5

Then add upper octave:
  - Q = C5? But we already reach C5 with comma.

This is getting complex. Let me do a cleaner, elegant job with a defined mapping over a couple octaves, and allow octave shift with arrow keys.

Plan: Base octave range. I'll render 3 octaves (C3 to B5) = 21 white keys + 15 black = 36 keys. Add octave shift buttons (+/-) or arrow keys to shift keyboard mapping (and maybe highlighted marks).

Let me keep it simpler but nice: render one full interactive octave set that can shift. Keys mapping fixed to 2 octaves with Q/A/Z rows.

Let me use a well-known clean mapping (from many JS pianos):

Two octaves, "home row" mapping:

White keys: 
Z C4, X D4, C E4, V F4, B G4, N A4, M B4,  ',' C5, '.' D5
Black:
S C#4, D D#4, G F#4, H G#4, J A#4, L C#5, ';' D#5

That's octave 4 starting at C. Then to add an octave above with Q row:
White: Q C5? but we already have comma=C5.

Ah, conflict again because the Z row's comma is C5.

Let me instead make keyboard play using a mapped set independent of labels; I'll assign each key a midi number directly, no conflict:

Bottom/interface rows → distinct notes:
- A S D F G H J K L ; = C4#? 

Simplest clean solution used by "Virtual Piano" classic:
- Row: Q W E R T Y U I O P [ ]  → white C D E F G A B C D E F G
- Row: 1 2 3 4 5 6 7 8 9 0 - = → black (C# D# F# G# A# C# D# F# G# A#)
- Row: A S D F G H J K L ; ' → white octave down C D E F G A B C D E
- Row: Z X C V B N M , . / → black octave down

But that's 4 rows which is messy.

I'll go with the classic 2-row mapping which is what most people expect and is conflict-free if I define it my own way:

White keys row (letters + bottom): Z X C V B N M , . /   = C D E F G A B C D E  (descending? no, ascending)
Black keys row: S D G H J L ;  = represent the sharps interspersed.

To make it conflict-free and intuitive, I'll lay out:

The 3 rows SDFGHJKL, QWERTYU, ZXCVBNM can represent consecutive octaves.

Let me define explicit MIDI for each. I'll go with this widely used mapping (I recall from many tutorials):

Row `Z X C V B N M , . /` → C D E F G A B C D E (white, octave = base)
Row `S D G H J` → C# D# F# G# A# (black)
Row `Q W E R T Y U` → C D E F G A B (next octave white)
Row `2 3 5 6 7` → next octave black

No, still 4 rows.

Decision: Use the standard "two keyboard rows" mapping that many online pianos use (e.g., the "Piano by Number" / typical javascript):

I'll assign:
- Lower keyboard row (white): `Z X C V B N M , . /` → notes C4, D4, E4, F4, G4, A4, B4, C5, D5, E5
- Upper row (black): `A S D F G H J` (they're physically above/in between) → black keys: A=C#4, S=D#4, D=F#4, F=G#4, G=A#4, H=C#5, J=D#5

Wait but A row is the one right above Z row, that's fine. And there's also the Q row. But the issue is the natural white keys extend onto the Q row if we want more than 2 octaves.

I think rendering a fixed set of keys and mapping is the cleanest and most predictable. Let me go with this:

Keyboard-to-piano mapping (classic, two full visible octaves of "home rows"):
- `Z` C3, `S` C#3, `X` D3, `D` D#3, `C` E3, `V` F3, `G` F#3, `B` G3, `H` G#3, `N` A3, `J` A#3, `M` B3, `,` C4, `L` C#4, `.` D4, `;` D#4, `/` E4
And also `Q` C4, `2` C#4... hmm.

I'll stop overcomplicating and just go with the very standard mapping used by the famous "VirtualPiano.net" style, which is:

White keys: `A W S E D F T G Y H U J K O L P ; [ ]
Black: ...`

No. Let me just commit to the cleanest defensible mapping and document it clearly in the UI.

Final mapping (I'll show on the keys via labels!):
I'll render actual piano keys with their assigned computer-key labels printed on them. This makes it self-documenting.

Mapping (base):
Computer key → note:
Z→C, S→C#, X→D, D→D#, C→E, V→F, G→F#, B→G, H→G#, N→A, J→A#, M→B
Q→C+1oct, 2→C#+1, W→D+1, 3→D#+1, E→E+1, R→F+1, 5→F#+1, T→G+1, 6→G#+1, Y→A+1, 7→A#+1, U→B+1

That gives 2 octaves, each with 7 white + 5 black, mapped to two computer rows (bottom Z-row for lower octave, Q-row arranged above for upper octave). Black keys in Z row are the S D G H J keys; black in Q row are the numbers 2 3 5 6 7.

Hmm but the Z row only has 7 white keys (Z X C V B N M) which is exactly one octave C-B. Good. And 5 black (S D G H J) interspersed. 

The Q row: 7 white (Q W E R T Y U) = one octave C-B, with black (2 3 5 6 7). 

This is clean! Two octaves, mapping:
Lower octave (C4..B4):
- Whites: Z X C V B N M
- Blacks: S D G H J
Upper octave (C5..B5):
- Whites: Q W E R T Y U
- Blacks: 2 3 5 6 7

Great, conflict-free, two full octaves. I'll render two octaves (C4 to B5 = 24 keys). Maybe add octave shift to extend.

I'll add octave shift with arrow keys (up/down) and +/- buttons, shifting which MIDI the keyboard and clicking produce. Actually shifting the rendered keyboard would be complex; instead I'll render a fixed piano range and clicking any key plays that note. Keyboard mapping plays the two-octave block; I can allow it to play the same notes regardless. To keep it clear, I'll set the rendered piano to C3–C6 (3 octaves, 37 keys) and the keyboard mapping plays notes relative to a shift offset shown on screen.

Let me simplify: Render 3 octaves C3..C6 (C3 to B5 = 36 keys). Keyboard plays 2 octaves mapped to the Q-row (C5..B5) and Z-row (C4..B4). All within the rendered range. Clicking plays by pitch. No shifting needed. Clean.

Actually, let me render the full range the keyboard covers plus a bit, maybe 4 octaves for nice mouse play. I'll do C2..C6 = 4 octaves, 49 keys. Hmm, mouse-scrolling a wide keyboard. Let me do 3 octaves C3..B5 plus maybe C6. 37 keys.

Let me render 3 octaves: C3 (MIDI 48) through B5 (MIDI 83) = 36 keys. 21 white + 15 black.

Keyboard mapping: Q-row plays C5..B5 (MIDI 72-83), Z-row plays C4..B4 (MIDI 60-71). Both in range. 

Now features:
- Tone.js Synth with ADSR envelope
- Polyphony: Tone.PolySynth(Tone.Synth).volume, or just multiple synths. Better: use Tone.PolySynth with Tone.Synth and set ADSR. 
- Audio context started on first user interaction.
- Visual feedback: pressed key lights up (CSS class), also maybe a subtle glow.
- Mouse: mousedown on a key plays, mouseup/leave stops; dragging across keys triggers arpeggio.
- Computer keys: keydown triggers (if not repeat), keyup stops.
- Sustain pedal with spacebar maybe.
- Volume, octave display, note labels.
- Sustain toggle with right shift? Keep it simple: spacebar = sustain pedal.

ADSR: use Tone.PolySynth(Tone.Synth, { envelope: { attack: 0.01, decay: 0.2, sustain: 0.4, release: 1.2 }, oscillator: { type: 'triangle' } }).

PolySynth constructor: new Tone.PolySynth(Tone.Synth, options) or new Tone.PolySynth({...}). In Tone 14, Tone.PolySynth(Tone.Synth, opts). Let me just use Tone.PolySynth with options.

Let me verify Tone API version. The minified uses `version:()=>i` suggesting Tone 14.x. In Tone 14, `Tone.PolySynth` exists, `Tone.Synth` exists with `oscillator` and `envelope` settings. Also `Tone.getContext()`, `Tone.start()`, `Tone.now()`.

Let me build.

Piano layout: white keys width e.g. 60px, height 220. Black keys positioned at boundaries. Standard.

Let me structure HTML:
- Header with title, controls (volume slider, sustain button, waveform select maybe, octave indicator)
- Piano container
- Footer with key hints

I'll generate keys via JS for maintainability.

For black key positioning: after creating white keys with index within octave (0..6), black keys placed after white indices 0,1,3,4 (C,D,F,G,A) — i.e., black key between white i and i+1 for i in {0,1,3,4,5}. Position left = (i+1)*whiteWidth - blackWidth/2.

Let me write the code that builds white keys, tracks their positions/rects, then builds black keys on top.

Each key has midi number. Note names: from midi.

Let me code note names: midiToName(midi) → e.g., "C4". Using formula.

Black/white: white if (midi % 12) in {0,2,4,5,7,9,11}.

Now interactions:
- pointerdown on key (mouse). Use Pointer Events for mouse+maybe touch. I'll use mousedown/mouseup/mouseleave plus touch? Keep mouse-focused but robust: use 'mousedown' on document, determine key under cursor. Simpler: attach to each key element.

For dragging across keys (glissando) I'll track on mousedown store "this key is held", then on mouseover with button pressed, hold new key, release previously held. Use a Set of active mouse notes.

Let me implement:
- state.audioStarted false
- synth created once
- noteOn(midi): synth.triggerAttack(midiToFreq? ) Actually PolySynth.triggerAttack accepts note name or frequency. I'll pass note name like "C4". Or midi number (number works as frequency? PolySynth accepts note name or frequency number. MIDI number is NOT frequency). So convert: midiToFreq = 440 * 2^((midi-69)/12). Pass frequency. Or pass name. I'll pass note name.
- noteOff(midi): synth.triggerRelease(name). For poly, need to release the specific note. triggerRelease(name).

Track currently active computer-key notes in a Map key→midi, and active mouse notes in a Set.

For visual: key.highlight() adds .pressed; key.release() removes. Since same midi could be triggered by both mouse and keyboard, track count. I'll keep a per-midi counter (Set of sources). When no sources, remove highlight.

Let me implement a registry: heldNotes = Map midi -> Set of sources ('mouse' or keycode).

noteOn(midi, source): if sources empty → triggerAttack + add .pressed. Add source.
noteOff(midi, source): remove source; if empty → triggerRelease + remove .pressed.

Sustain: store sustained notes, only release when sustain lifted and no active source. I'll implement: sustainOn flag. On noteOff, if sustain on, add to sustainedNotes set; else release. On sustain off, release all sustained notes (that aren't still held by another source).

Actually to keep robust with multiple sources, simplest: noteOff triggers release only if no sources remain. With sustain, defer releases. Let me implement a decent version.

Let me now write index.html.

For audio start: on first pointerdown or keydown, call Tone.start() (resolves promise) then proceed. Since triggers happen synchronously in same handler, Tone.start should be called first; Tone 14 auto-starts on user gesture? Better to explicitly await Tone.start() once.

I'll do: async ensureAudio() { if(!started){ await Tone.start(); synth = new Tone.PolySynth(...); synth.toDestination(); started=true; } }

Note: Creating synth before context started could throw in older versions; in 14 it's fine, context starts lazily. I'll create synth at init.

Let me write it.

Waveform selector: sine/triangle/square/sawtooth. Update synth.set({ oscillator: { type } }). For PolySynth, synth.set({ oscillator:{type} }) applies to... PolySynth.set sets options on children. Actually PolySynth forwards options to its voice. Should work with `synth.set({ oscillator: { type } })`. In Tone 14 PolySynth constructor `new Tone.PolySynth(Tone.Synth, options)`. Let me create with that and set via synth.set.

Let me just create a single PolySynth and adjust volume.

Volume slider: synth.volume.value = db.

Let me build the UI.

Now let me write it all.

Good, Tone 14 with PolySynth. Let me build the app.

Let me verify the HTML file loads tone.min.js correctly and the script is valid. Let me check the black key positioning logic - the initial layoutBlackKeys uses mod of white key, but mod values for white keys are 0,2,4,5,7,9,11. blackAfter=[0,1,3,4,5] - but mod can't be 1,3 white. So blackAfter should be [0,2,4,5,7,9]? Wait black keys are placed after white D (mod 2) -> D#, after E (mod 4) -> none (E# doesn't exist). Let me think again.

Black keys: C# (after C), D# (after D), F# (after F), G# (after G), A# (after A).
White keys in order: C(0), D(2), E(4), F(5), G(7), A(9), B(11).

Black after C(mod0)→C#; after D(mod2)→D#; after F(mod5)→F#; after G(mod7)→G#; after A(mod9)→A#.

So blackAfter = [0,2,5,7,9]. I incorrectly wrote [0,1,3,4,5]. Need to fix.

Also note my earlier loop positioning in the key build used a weird formula but then layoutBlackKeys recalculates. Let me fix layoutBlackKeys.

Also the mod check in the build loop for black keys uses mod 1,3,6,8,10 which is correct for black key conditions (C#=1,D#=3,F#=6,G#=8,A#=10). Good, that matches. The initial 'left' calculation in build is redundant/wrong but layoutBlackKeys overrides. Let me just fix layoutBlackKeys blackAfter values.

Let me fix.

Now let me verify the file works. Let me check it syntactically by extracting the main script.

The syntax error "Unexpected token '>'" is likely from my extraction logic capturing the src script content (tone.min.js huge) incorrectly, or the regex. Let me extract more carefully - the first <script src=...> block should be excluded. My filter used `!inner.includes('src=')` but inner for the tone block is the minified JS which is huge and doesn't contain 'src='. Hmm. But the issue: the body script block — does my extraction include the `>` from somewhere? Let me extract properly by splitting on script tags with a different approach.

The inline JS is syntactically valid. The earlier error was just from my extraction regex. 

Now let me double check the black key layout logic once more and make sure the piano renders well. Let me also verify Tone.PolySynth constructor with options works in this version. In Tone 14, `new Tone.PolySynth(Tone.Synth, options)` where options include voice config. Actually the signature: `new Tone.PolySynth(voice, options)` or `new Tone.PolySynth(options)` where options can include `voice`. My usage `new Tone.PolySynth(window.Tone.Synth, {maxPolyphony:24, voice:0, ...})` — maxPolyphony may need to be in options. Also `voice: 0` is the voice constructor param for first positional. Actually the 2nd arg is options object; maxPolyphony isn't a standard option. Setting `poly.maxPolyphony = 24` directly might be needed. Let me set poly.maxPolyphony after creation to be safe. Actually in Tone 14, PolySynth(options) where options can have maxPolyphony and voice. The form `new PolySynth(voice, options)` — voice is a class, options apply. maxPolyphony is an option too. Let me just create with `new Tone.PolySynth({ voice: Tone.Synth, maxPolyphony: 24, ... })` which is cleaner. But `voice` as option expects an instance or class. In Tone 14, options.voice can be a class. Let me use that form to be safe since it's documented.

Let me update ensureAudio to use the single-object form. Also 'fatsawtooth' oscillator type is valid in Tone.

Let me update the constructor. Also `poly.set({oscillator:{type}})` — PolySynth.set applies options to all voices; should be fine.

Let me refine the code.

Now, there's a subtle bug: `ensureAudio()` creates the poly with volume -8 and sets `poly.volume.value` on init via `poly.toDestination()`. But the volume slider events before audio started are handled only if poly exists. Since poly is created on first interaction, the slider initial -8 matches. Good.

However, there's an ordering issue: `ensureAudio()` is async. When user presses a key, ensureAudio starts the context (which is a promise), and press() is called in the .then — good.

But there's another concern: `Tone.start()` in v14 returns a promise; once started, subsequent calls fine.

One concern: pointer capture on the piano means pointerup outside still captured — fine, and I also added window pointerup.

Another: For drag glissando, I release with each mouse source then re-press. If lastPointerKey is null initially it's set on pointerdown.

Let me verify the whole thing loads in a browser context. I can't easily run a browser, but let me at least sanity-check the file structure and that tone is a global. Let me confirm Tone.PolySynth exists in the global.

I already verified PolySynth exists in the bundle. Good enough.

Let me also verify the black key build loop: it creates black keys for mod 1,3,6,8,10 between LOW..HIGH. Then layoutBlackKeys positions them. For each white key with mod in [0,2,5,7,9], place black at blackMidi=m+1 (m+1 for mod0→1 C#, mod2→3 D#, mod5→6 F#, mod7→8 G#, mod9→10 A#). Correct.

But wait: for a white key at the boundary where m+1 exceeds HIGH (B5=83, mod11, not in list, fine). Also for m where m+1 is beyond range (none since blacks exist only at those mods within range). Good. Also low boundary C3=48 mod0 → C#3=49 exists. Good.

One issue: the build loop creates the black key with an initial `left` computed using a formula referencing `li` (index of left white). That formula is messy but then layoutBlackKeys recomputes `left` properly. Let me simplify but it's fine since overridden. Actually there's a potential bug: the initial left formula might place black keys at wrong spot before layoutBlackKeys runs, but layoutBlackKeys runs synchronously right after build, so final positions correct. Fine.

Let me just do a final read of the black key building section to make sure no leftover issues.

Actually let me clean up that redundant formula to avoid confusion, it's harmless but let me leave it. It works.

Let me verify file end and do a quick validation that the whole HTML references match. Let me view the relevant section.

Let me simplify the redundant black-left formula to avoid the unused variable confusion. Actually `leftWhite`, `li` and the formula — let me replace with a placeholder that layoutBlackKeys fixes. It's harmless but let me just clean it up.

Now let me verify the final file loads and validate in a headless way if possible. Let me check if there's a way to run a quick DOM test. Probably no browser available. Let me at least re-run the syntax check.

Also one issue: the `midiName` function is used before definition? No, it's defined at top.

Let me also double-check the keyboard mapping KB - comma and period keys: e.key for comma is ',' and period is '.'; toLowerCase keeps them. KB has ',' and '.'. Good. Semicolon ';'. slash '/'. Numbers '2','3','5','6','7'. Good.

Let me re-run syntax check.