Inspiration
A scene can look perfect and still lose an important line because a wireless microphone cuts out. Finding the problem after filming can mean another take or recording dialogue again later.
I built Signal Slate to help a film sound team answer a simple question before the next take: What should I change, and did that change actually help?
What it does
Signal Slate guides the user through five steps:
- Scene: Choose a sample rehearsal and check the sound.
- Sound: Listen to the marked problem and ask Gemini to investigate.
- Change: Add a restriction, such as "keep channel 11 free," confirm that it was understood correctly, and approve a suggested microphone setting change.
- Compare: Run a new sample rehearsal and listen to Before and After.
- Report: See which checks passed, inspect the Grafana readings, and download the result.
The person using the app approves the exact change before it is tested. An unsuccessful change stays marked as failed. Missing or incomplete readings produce an inconclusive result.
Google Cloud and Gemini
I use Gemini 2.5 Flash on Google Cloud Vertex AI, with the Google Agent Development Kit (google-adk) and Google Gen AI SDK (google-genai).
Gemini receives the scene details, microphone settings, measured sound problems, and the user's restrictions. Its tools let it look up measurements and events for the current rehearsal. It uses this evidence to explain the problem, suggest a change, and interpret restrictions written in everyday language.
The application checks Gemini's evidence references and proposed changes before using them. Fixed application checks decide whether the next rehearsal passed; a confident AI answer alone cannot mark a result as successful.
The bundled synthetic dialogue was generated using Google's Gemini speech model.
Grafana track: evidence behind every result
I am entering the Grafana track.
Grafana Cloud Metrics (Prometheus-compatible) stores the rehearsal measurements, and Grafana Loki stores the event records. Both are managed through Grafana Cloud. The application sends measurements as OpenTelemetry Protocol (OTLP) JSON over HTTP. Signal Slate calls the official grafana/mcp-grafana server at runtime to retrieve these records, including through its query_prometheus and query_loki_logs tools.
This makes Grafana part of the sound-check workflow. After an approved change, the application publishes a new rehearsal, reads the new measurements back through Grafana MCP, and checks them against the earlier run. The report checks complete coverage, agreement between measurements and event records, sound limits, important dialogue, and the user's confirmed restrictions.
In one completed cloud rehearsal, moving Elena's simulated microphone from channel 10 to channel 12 reduced missing sound from 1.9 seconds to 0.0 seconds, while keeping channel 11 free. All five report checks passed. That result describes this sample rehearsal, not a test of physical equipment.
How I built it
The interface uses React, TypeScript and Vite. A Python FastAPI backend runs the rehearsal workflow, calls Google Cloud and Grafana, and stores sessions and reports in PostgreSQL. Docker packages the application for hosting.
Cloud credentials stay on the server. Each workflow has a limit on model calls, and the application also limits daily live sessions.
Challenges and what I learned
The hardest part was making the result trustworthy. Fresh readings can take time to appear, data can be incomplete, and a suggested change can fail. I added checks that prevent old, missing, or conflicting evidence from being presented as a successful result.
I also learned that the interface needs to explain the next action in plain language. I replaced technical labels with Scene, Sound, Change, Compare and Report, and made the approval and playback steps more explicit.
What works today
The hosted application completes the full workflow with real Gemini calls and real Grafana Cloud queries, using simulated microphone readings and a 12-second synthetic dialogue sample.
Before and After let the user hear how the simulated sound faults differ between rehearsals. The app does not currently analyze uploaded recordings, control physical microphones, or repair an original recording. A separate preview mode demonstrates the interface without cloud calls.
What's next
I want to add direct analysis of uploaded rehearsal audio, then connect supported microphone receivers so the same approval and verification workflow can use real equipment readings.
My aim is to help a sound team make a clear, checked decision before filming the next take.
Built With
- alembic
- docker
- fastapi
- gemini
- google-adk
- google-cloud
- google-genai
- grafana
- grafana-cloud-metrics
- grafana-loki
- grafana-mcp
- otlp
- postgresql
- python
- react
- sqlalchemy
- tailwind-css
- typescript
- vertex-ai
- vite
Log in or sign up for Devpost to join the conversation.