christianandClaude Opus 5.5
0f0adb4c60
On a Resi that publishes every ~30s, the board could start a few seconds before a publish and learn a 2s cadence from that partial first gap. Every honest 30s gap after that was thrown out as a pause, so playback read as paused 15s into every update: the countdown froze, and the next cue -- and the name on the Timers card -- stopped moving on. - The partial gap right after startup is no longer learned, and one outlier gap can no longer lock out the real cadence. - Until a cadence is measured, a pause is only called after 45s, not 15s. - The Timers card is titled with the cue's name; its status line now says "Next cue" / "Held" instead of repeating the name. - server.test.js awaited nothing, so an async test raced the next one and failed on main; tests now run one at a time. Same fix as the Resi -> ProPresenter bridge and the Companion module 0.1.2. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
92 lines
3.0 KiB
JSON
92 lines
3.0 KiB
JSON
{
|
|
"id": "resi-cues",
|
|
"name": "Resi Cues",
|
|
"version": "1.0.1",
|
|
"proddash": ">=1.4.0",
|
|
"description": "Time until the next Resi cue point, on the board and as a timer",
|
|
"provides": ["timers"],
|
|
"client": "client.js",
|
|
"server": "server.js",
|
|
"style": "style.css",
|
|
"minSize": { "w": 2, "h": 1 },
|
|
"defaultSize": { "w": 4, "h": 3 },
|
|
"configGroups": {
|
|
"Resi account": {
|
|
"help": "The Resi Studio login the board reads with. Cue points and the decoder's playhead both come from Resi's cloud, so nothing is installed at the decoder. Worth using a dedicated low-privilege Resi user rather than a personal one."
|
|
},
|
|
"Decoder": {
|
|
"help": "Which decoder to follow. The list is read from the account once the login above is saved."
|
|
},
|
|
"Timing": {
|
|
"collapsed": true,
|
|
"help": "Resi refreshes a decoder's position only every few seconds, on an irregular cadence, and each reading is already slightly stale. The board estimates between readings rather than repeating them, so these only change how often it asks — not how accurate it is."
|
|
}
|
|
},
|
|
"configSchema": {
|
|
"username": {
|
|
"type": "string",
|
|
"label": "Resi login",
|
|
"group": "Resi account",
|
|
"default": "",
|
|
"help": "The email address used to sign in to studio.resi.io."
|
|
},
|
|
"password": {
|
|
"type": "password",
|
|
"label": "Password",
|
|
"group": "Resi account",
|
|
"default": ""
|
|
},
|
|
"player": {
|
|
"type": "select",
|
|
"label": "Decoder",
|
|
"group": "Decoder",
|
|
"default": "",
|
|
"optionsRoute": "/decoders",
|
|
"help": "Leave unset to follow the only decoder on the account."
|
|
},
|
|
"pollSeconds": {
|
|
"type": "number",
|
|
"label": "Position poll (s)",
|
|
"group": "Timing",
|
|
"default": 1,
|
|
"help": "How often Resi is asked where the playhead is. A faster poll notices a fired cue sooner; it does not make the countdown smoother, which is handled by estimating between readings."
|
|
},
|
|
"cueRefreshSeconds": {
|
|
"type": "number",
|
|
"label": "Cue list refresh (s)",
|
|
"group": "Timing",
|
|
"default": 5,
|
|
"help": "How often the cue list is re-read. It is also re-read immediately whenever the playhead jumps, so a cue fired at the host shows up without waiting for this."
|
|
},
|
|
"positionTrimMs": {
|
|
"type": "number",
|
|
"label": "Position trim (ms)",
|
|
"group": "Timing",
|
|
"default": 0,
|
|
"help": "Leave at zero. Only needed if the whole chain reads consistently behind; a positive value pushes the estimate forward."
|
|
}
|
|
},
|
|
"instanceSchema": {
|
|
"showCueName": {
|
|
"type": "switch",
|
|
"label": "Cue name",
|
|
"default": true
|
|
},
|
|
"showPrevious": {
|
|
"type": "switch",
|
|
"label": "Previous cue",
|
|
"default": true
|
|
},
|
|
"showPosition": {
|
|
"type": "switch",
|
|
"label": "Playhead",
|
|
"default": true
|
|
},
|
|
"showCueList": {
|
|
"type": "switch",
|
|
"label": "Cue list",
|
|
"default": false
|
|
}
|
|
}
|
|
}
|