noe/tl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
102 commits 1 branch 0 tags 902 KiB
Find a file
Your Name 12ab7c4fca fix: bind repeated marks to their own occurrence in their own context 
A mark that repeats an earlier part produced bars for every occurrence of
that part, so all of an annotation's marks lit up at once inside it. In the
annotation's own context the local ranges are already the truth — merge those
instead of re-projecting the part across the parent's segments. Other contexts
still project, which is what makes a repeat visible from outside.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-17 15:54:11 -04:00
scenes refactor: anchor annotation marks to clips and unify visibility edges 2026-09-17 15:10:52 -04:00
server feat: production deploy (Fly + R2) + frame controls and picker glow 2026-06-30 00:56:09 -04:00
tl fix: bind repeated marks to their own occurrence in their own context 2026-09-17 15:54:11 -04:00
.dockerignore transclusion fixes and other things by chat 2026-07-06 23:48:01 -04:00
.gitignore feat: production deploy (Fly + R2) + frame controls and picker glow 2026-06-30 00:56:09 -04:00
DEPLOY.md feat: production deploy (Fly + R2) + frame controls and picker glow 2026-06-30 00:56:09 -04:00
Dockerfile feat: production deploy (Fly + R2) + frame controls and picker glow 2026-06-30 00:56:09 -04:00
fly.toml fix: thumbnail parser overflow, autostop-killed jobs, unified playhead 2026-06-30 09:48:08 -04:00
manage.py Add Django backend: users, admin, OTIO + scene persistence 2026-06-28 23:45:49 -04:00
README.md feat: timeline links, network error handling, Tailscale access, mobile fixes 2026-06-29 19:24:40 -04:00
requirements.txt feat: production deploy (Fly + R2) + frame controls and picker glow 2026-06-30 00:56:09 -04:00

README.md

scene_analysis

  • tl/ — the lumet frontend (ClojureScript / reagent / re-frame). See tl/.
  • Django backend (this folder) — users, admin, and persistence of OTIO + the timeline scene.

Backend

The backend stores one Project per editing session: the uploaded OTIO source file, the playback fps, and the live scene (the {:tracks :groups} mark-group map the frontend keeps in app-db) as a JSON dump.

Run

python -m venv .venv && .venv/bin/pip install -r requirements.txt
.venv/bin/python manage.py migrate
DJANGO_SUPERUSER_PASSWORD=admin .venv/bin/python manage.py createsuperuser --noinput --username admin --email admin@example.com
.venv/bin/python manage.py seed_demo          # demo project from tl/.../one_two_three.otio
.venv/bin/python manage.py runserver 0.0.0.0:9001   # 0.0.0.0 so it's reachable over Tailscale/LAN

Admin: http://127.0.0.1:9001/admin/ (admin / admin). Upload OTIO and inspect the scene JSON there.

API (session auth; 401 if not logged in)

Method Path Purpose
GET /api/projects/ the current user's projects
GET /api/projects/<id>/scene/ {fps, scene}
PUT /api/projects/<id>/scene/ replace scene and/or fps (JSON body)
GET /api/projects/<id>/otio/ serve the uploaded OTIO file
GET /api/projects/<id>/revisions/ save history (who / when / summary)

Attribution

Annotations are the authored unit, so that's what's attributed — and the server is the authority (client-sent stamps are ignored, so authorship can't be forged). On each scene PUT the server diffs incoming annotation groups against the stored ones and stamps createdBy/editedBy (+ timestamps) from request.user; it also writes a Revision (user, time, +N ~N −N summary, snapshot of the annotation layer). A project is editable by its owner and any collaborators (managed in the admin), so different users get distinct stamps.

The frontend currently loads /one_two_three.otio and persists annotations to localStorage; pointing it at /api/projects/<id>/otio/ and the scene endpoints is the next wiring step (CORS/credentials needed across the dev ports).