fixed sound library loading issue.

app.py

@@ -381,6 +381,32 @@ function () {
 		setTimeout(() => clearInterval(iv), 20000);
 	}
 
+	// Initial render on RELOAD/restore. Gradio repopulates the hidden #ls-editor-state
+	// textbox with the previous score on a page reload but does NOT fire a `change`
+	// event, so the normal change->render path never runs and the sheet stays blank.
+	// This is self-healing against the reload race (mount, Gradio's textbox restore,
+	// and Verovio init all settle at different times): poll until an SVG has actually
+	// appeared, re-calling render each tick while the editor has text but no SVG is
+	// shown yet. render() has a lastCode no-op guard, so repeat calls with the same
+	// text are cheap once it has succeeded. On a FRESH deep-link load the editor
+	// starts empty and the radio-click path renders it, so the SVG shows up and this
+	// loop stops without ever calling render itself (no double render).
+	{
+		let rtries = 0;
+		const initialRender = () => {
+			const root = document.getElementById('ls-score');
+			const shown = root && root.querySelector('.ls-svg svg');
+			if (shown) return;                       // something rendered — done
+			const ta = document.querySelector('#ls-editor-state textarea');
+			const txt = ta && ta.value;
+			if (window.LilyScore && root && txt && txt.trim()) {
+				try { window.LilyScore.render(txt); } catch (e) {}
+			}
+			if (++rtries < 100) setTimeout(initialRender, 150);
+		};
+		initialRender();
+	}
+
 	// Deep-link: if the URL carries #score=<file>, select that Score List entry on
 	// first load (so a bookmarked/shared score opens directly). We strip the leading
 	// emoji prefix (📄/✨) when comparing, and click the matching radio input — that

web/fluid-audio.js

@@ -32,6 +32,12 @@
 	var FLUID_URL = (window.__LILYSCRIPT_FLUID_URL || './fluid/');
 	var SOUNDFONT_URL = (window.__LILYSCRIPT_SOUNDFONT_URL || './soundfont/');
 
+	// DEBUG TOGGLE: when true, skip loading gm.sf3 / FluidSynth entirely and keep
+	// playing through the legacy ogg.js piano fallback. Lets us isolate whether the
+	// fallback path alone is audible, independent of the FluidSynth handoff. Set via
+	// window.__LILYSCRIPT_DISABLE_FLUID before this script runs, or flip the default.
+	var DISABLE_FLUID = !!window.__LILYSCRIPT_DISABLE_FLUID;
+
 	// The with-libsndfile build is required to decode .sf3 (ogg-compressed) fonts;
 	// it also reads .sf2. Both modules load into the AudioWorklet scope.
 	var LIBFLUIDSYNTH_FILE = FLUID_URL + 'libfluidsynth-2.4.6-with-libsndfile.js';
@@ -87,6 +93,28 @@
 			// 2) Wait for the fallback to finish before kicking off the heavy GM load.
 			try { await legacyPromise; } catch (e) {}
 
+			// DEBUG: gm.sf3/FluidSynth disabled — stay on the legacy ogg.js fallback.
+			if (DISABLE_FLUID) {
+				log('FluidSynth DISABLED (DISABLE_FLUID) — using legacy ogg.js fallback only');
+				return;
+			}
+
+			// 3) Fetch the 40MB gm.sf3 bytes FIRST, before touching any AudioContext.
+			// This is the key to keeping the fallback audible the whole time: if we
+			// instead created FluidSynth's AudioContext (+ worklet modules) up-front and
+			// only then downloaded the soundfont, TWO suspended AudioContexts (the legacy
+			// fallback's and FluidSynth's) would coexist during the long download window.
+			// The browser autoplay policy only lets us resume a suspended context
+			// synchronously inside a user gesture, and with two of them the single
+			// in-gesture resume() couldn't reliably warm BOTH — the legacy one lost and
+			// stayed silent (the "fallback plays but no sound until gm.sf3 loads" bug).
+			// By deferring all FluidSynth context creation until the bytes are in hand,
+			// exactly ONE AudioContext (the legacy fallback) is alive for the whole
+			// download, so its in-gesture resume is unambiguous and it actually sounds.
+			var sfontBuffer = await (await fetch(SOUNDFONT_FILE)).arrayBuffer();
+			log('gm.sf3 fetched (' + sfontBuffer.byteLength + ' bytes); building FluidSynth');
+
+			// Now build the FluidSynth AudioContext + worklet graph and load the font.
 			audioCtx = new (window.AudioContext || window.webkitAudioContext)();
 			// libfluidsynth must be added before the worklet module.
 			await audioCtx.audioWorklet.addModule(LIBFLUIDSYNTH_FILE);
@@ -98,13 +126,19 @@
 			node = synth.createAudioNode(audioCtx);
 			node.connect(audioCtx.destination);
 
-			var sfontBuffer = await (await fetch(SOUNDFONT_FILE)).arrayBuffer();
 			await synth.loadSFont(sfontBuffer);
 
 			seq = await synth.createSequencer();
 			await seq.registerSynthesizer(synth);
 			seq.setTimeScale(1000);   // 1 tick = 1 ms, matching performance.now()
 
+			// FluidSynth's context is created fresh here, AFTER the user has likely
+			// already pressed play (gm.sf3 takes seconds to fetch+decode). Its context
+			// therefore starts suspended with no pending user gesture to resume it. Try
+			// to resume right away; if the autoplay policy blocks it, the next play()
+			// click resumes it synchronously in-gesture and the handoff completes then.
+			if (audioCtx.state === 'suspended') { try { await audioCtx.resume(); } catch (e) {} }
+
 			// Hand off from the fallback: silence any lingering notes.
 			if (legacyReady && legacy && legacy.stopAllNotes) legacy.stopAllNotes();
 
@@ -115,13 +149,12 @@
 	}
 
 	// Resume audio output; must be called from a user gesture (autoplay policy).
-	// CRITICAL: both the FluidSynth AudioContext AND the legacy fallback's WebAudio
-	// context start suspended and can only be resumed *synchronously within the user
-	// gesture*. So we must fire BOTH resume()/awaitWarmup() calls BEFORE the first
-	// `await` — otherwise the second one runs in a later microtask, outside the gesture
-	// activation, and the browser refuses to resume it (it hangs/rejects). That was the
-	// "fallback plays but is silent" bug: only FluidSynth's context got resumed, the
-	// legacy one stayed suspended so its buffer sources produced no sound.
+	// A suspended AudioContext can only be resumed *synchronously within a user
+	// gesture*, so we fire all resume()/awaitWarmup() calls BEFORE the first await.
+	// During the fallback window `audioCtx` is null (FluidSynth's context isn't
+	// created until gm.sf3 is fetched — see loadPlugin), so only the legacy WebAudio
+	// context exists and gets warmed up here; there's no second context to contend
+	// with. Once gm.sf3 has loaded, audioCtx exists and is resumed too.
 	function resume () {
 		var promises = [];
 		if (audioCtx && audioCtx.state === 'suspended') {

web/score-player.js

@@ -199,9 +199,15 @@
 			}
 			if (backend.empty && backend.empty()) { log('audio not ready (no backend audible)'); return false; }
 			state.audioReady = true;
-			// warm up eagerly (the in-gesture resume() in play() is what actually
-			// satisfies the browser autoplay policy).
-			if (backend.resume) { try { await backend.resume(); } catch (e) {} }
+			// NOTE: do NOT warm up / resume the audio context here. This runs at page
+			// load, outside any user gesture, so the browser autoplay policy won't
+			// actually resume a suspended context. Worse, the legacy WebAudio backend's
+			// awaitWarmup() *caches* the in-flight resume() promise — calling it
+			// out-of-gesture starts a resume() that never settles (no gesture) and
+			// caches that permanently-pending promise. Every later in-gesture warmup
+			// then returns the same hung promise, so play()'s `await resumeP` blocks
+			// forever and the transport freezes ("no reaction"). The in-gesture
+			// resume() inside play() is the ONLY place we resume.
 			log('audio ready (fluid=' + (backend.ready ? backend.ready() : '?') + ')');
 			return true;
 		} catch (e) {
@@ -267,8 +273,20 @@
 			if (!(await buildPlayer())) return;   // still can't build (no MEI/toolkit) → nothing to play
 		}
 		if (!state.player || !state.midiData) return;
-		// now make sure the resume actually completed before scheduling notes
-		if (resumeP) { try { await resumeP; } catch (e) {} }
+		// Make sure the resume completed before scheduling notes — but never let a hung
+		// resume freeze the transport. (The legacy backend can return a resume promise
+		// that never settles; see the awaitWarmup note in initAudio.) Race it against a
+		// short timeout: notes start scheduling regardless, and sound follows as soon as
+		// the context actually resumes. Resuming is in-gesture above, so this is just a
+		// safety valve, not the thing that satisfies autoplay.
+		if (resumeP) {
+			try {
+				await Promise.race([
+					Promise.resolve(resumeP).catch(function () {}),
+					new Promise(function (r) { setTimeout(r, 250); }),
+				]);
+			} catch (e) {}
+		}
 		state.isPlaying = true;
 		if (state.pausedTime > 0) {
 			state.playStartTime = performance.now() - state.pausedTime;