Update app.py

app.py

@@ -1,20 +1,6 @@
 # ============================================================================
 #  app.py — ZeroGPU deployment via gradio.Server
 #
-#  gradio.Server extends FastAPI, so:
-#    - @app.get("/")           serves the custom HTML editor (unchanged)
-#    - @app.api()              wraps the GPU transcription with Gradio's queue
-#                              + ZeroGPU allocation (@spaces.GPU)
-#    - @app.post("/analyze")   and @app.post("/pmi") are plain FastAPI routes
-#                              (CPU only — key estimation / PMI, no GPU)
-#
-#  IMPORTANT (ZeroGPU): the browser must call the @app.api() transcription
-#  endpoint through @gradio/client (see transcription-editor.html), NOT a bare
-#  fetch(), so the HF iframe auth headers reach ZeroGPU for quota handling.
-#
-#  This is a first-draft port. The ZeroGPU runtime differs from the Docker
-#  image (torch build, CUDA, FFmpeg), so the torchcodec / demucs monkeypatches
-#  in pipeline.py may need re-checking on the live Space.
 # ============================================================================
 import os, base64, tempfile, time
 
@@ -113,33 +99,7 @@ def _audio_seconds(path):
         return 30.0                      # unknown -> assume a modest clip
 
 def _gpu_duration(audio_path, instrument="vocals"):
-    # Calibrated against actual runs. Two consecutive calls from the logs:
-    #   cold, 35.1 s clip: demucs 1.20 s + inference 1.98 s + post 0.01 s = 3.2 s
-    #   warm, 40.9 s clip: demucs 0.50 s + inference 1.89 s + post 0.01 s = 2.4 s
-    # Two things follow. Inference barely moves with clip length in this range
-    # (1.98 s for 35 s of audio vs 1.89 s for 41 s), so scaling the estimate
-    # linearly with duration is mostly wrong -- fixed cost dominates. And a cold
-    # worker's demucs runs 2.8x slower than a warm one (29 vs 82 s of audio per
-    # second) as CUDA kernels and weights warm up. Across five clips (160 s of
-    # audio) the total was ~48 s of GPU time, i.e. ~6-7 s per call of pure
-    # overhead against 2-3 s of actual compute.
-    #
-    # Two formulas, because a cold worker and a warm one are not comparable: the
-    # cold path pays kernel warm-up and disk->VRAM weight streaming on top of
-    # the same compute.
-    #
-    # This buys queue position, NOT quota. Quota is charged on actual seconds
-    # used and the declaration only gates admission ("do you have this many
-    # seconds left?"), so at ~9 s of real cost per call the gate barely bites
-    # until the quota is nearly spent -- declaring 15 s instead of 22 s is worth
-    # about one extra call in thirty. What it does buy is priority: among queued
-    # requests, a shorter declared duration ranks higher.
-    #
-    # The warm claim is time-limited on purpose. ZeroGPU recycles idle workers,
-    # so "we succeeded once" does not mean the NEXT request lands on a warm one.
-    # Past WARM_WINDOW we assume cold again -- under-declaring is the worse
-    # error, because the declaration is also the hard timeout: the task is killed
-    # mid-run and the quota is spent anyway.
+
     sec = _audio_seconds(_resolve(audio_path))
     if (time.monotonic() - _last_gpu_ok) < WARM_WINDOW:
         return int(max(15, min(120, 8 + 0.2 * sec)))    # ~1.7x over measured
@@ -324,10 +284,7 @@ async def pmi_api(midi_a: UploadFile = File(...), midi_b: UploadFile = File(...)
             except OSError: pass
 
 
+demo = app
+
 if __name__ == "__main__":
-    # ssr_mode=False: Spaces force SSR on via an env var, which makes Gradio put a
-    # Node process on 7860 that proxies to Python on 7861. When that layer fails to
-    # answer, the platform's readiness probe never passes and the Space sits on
-    # "Starting" forever even though the log shows the app running. We serve our own
-    # HTML anyway, so server-side rendering buys us nothing here.
     app.launch(ssr_mode=False)