Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
  • This project
    • Loading...
  • Sign in / Register
T
Tidal
  • Overview
    • Overview
    • Details
    • Activity
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 0
    • Issues 0
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • PLN
  • Tidal
  • Repository

Switch branch/tag
  • Tidal
  • tools
  • foundry
  • engine
  • loops.py
Find file
BlameHistoryPermalink
  • PLN (Algolia)'s avatar
    fix(foundry): a background job that takes the desktop down is not a background job · 9b832eb5
    PLN, mid-cut: "you're hogging the system :(". Nine children at ~88% of a core each
    put the load average at **15.6 on 16 cores**, and the machine he performs and edits
    on became unusable. My fault twice over — the default was one subprocess per track
    regardless of the box, and nothing told the scheduler this work was background.
    
    Both fixed at the source rather than by remembering to pass a flag:
    
    * `--jobs` defaults to **half the cores, capped at 6**. It is the total that matters,
      not the track count, and each child peaks near 2 GB.
    * Children start at **nice 19 and SCHED_IDLE** via a preexec hook, so they only run
      when nothing else wants the CPU. The nine still saturate the sixteen cores; the
      editor now wins every scheduling decision, because nothing waits on this work but
      me. (The live run was reniced in place rather than killed — eight minutes of
      analysis is not worth a restart.)
    
    The test for that hook is worth a note, because the first version of it was fake: it
    looked the hook up through `_fan_out.__globals__`, where a nested function does not
    live, got `None`, fell back to a no-op lambda, and passed. Same shape of mistake as
    the finder test earlier today. So `run_at_idle_priority` is module-level now and the
    test asserts on a **real child's** reported nice and scheduling policy — verified to
    read `0 0` without the hook and `19 5` with it.
    
    Also in here, from the same run: the presence gate I added to the finder was doing a
    full `max(abs(window))` per candidate — at 8 bars that is ~700 k samples times
    thousands of windows, which is most of why this run was slower than the last. It now
    reads a per-beat peak table computed once per stem. Exact, not approximate: the
    inter-beat segments partition `[int(times[i]*sr), int(times[e]*sr))` precisely, so it
    visits the same samples — with a test that checks the two agree for every window
    rather than trusting the argument.
    
    And `kitgate --link` now takes each kit's staging root from the manifest instead of
    `publish.samples_root()`. A pack cut with `--samples-root` lives beside its source, so
    the default root would have looked in the wrong place and called every kit missing.
    
    Suite 122 → 125.
    PLN (Algolia) authored Aug 21, 2026
    9b832eb5
loops.py 37.8 KB
EditWeb IDE
×

Replace loops.py

Attach a file by drag & drop or click to upload


Cancel
A new branch will be created in your fork and a new merge request will be started.