Skip to content

Commit 4cc230a

Browse files
rjmunrorjmunro
committed
Fix typos in new docs
1 parent f21337b commit 4cc230a

22 files changed

Lines changed: 51 additions & 51 deletions

File tree

‎packages/documentation/docs/for-developers/device-integrations/tsr-plugins.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ Some useful npm scripts you may wish to copy are:
2727

2828
There are a few key properties that your plugin must conform to, the rest of the structure and how it gets generated is up to you.
2929

30-
1. It must be possible to `require(...)` your plugin folder. The resuling js must contain an export of the format `export const Devices: Record<string, DeviceEntry> = {}`
30+
1. It must be possible to `require(...)` your plugin folder. The resulting js must contain an export of the format `export const Devices: Record<string, DeviceEntry> = {}`
3131
This is how the TSR process finds the entrypoint for your code, and allows you to define multiple device types.
3232

3333
2. There must be a `manifest.json` file at the root of your plugin folder. This should contain json in the form `Record<string, TSRDevicesManifestEntry>`

‎packages/documentation/docs/user-guide/features/prompter.md‎

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -46,7 +46,7 @@ The prompter can be controlled by different types of controllers. The control mo
4646
| `?mode=shuttlewebhid` | Controlled by a Contour Design ShuttleXpress, using the browser's WebHID API [See configuration details](prompter.md#control-using-contour-shuttlexpress-via-webhid) |
4747
| `?mode=pedal` | Controlled by any MIDI device outputting note values between 0 - 127 of CC notes on channel 8. Analogue Expression pedals work well with TRS-USB midi-converters. [See configuration details](prompter.md#control-using-midi-input-modepedal) |
4848
| `?mode=joycon` | Controlled by Nintendo Switch Joycon, using the HTML5 GamePad API. [See configuration details](prompter.md#control-using-nintendo-joycon-gamepad) |
49-
| `?mode=xbox` | Controlled by Xbox controller, using the HTML5 GamePad API. [See configuration details](prompter.md#control-using-xbox-controller-modexbox) |
49+
| `?mode=xbox` | Controlled by Xbox controller, using the HTML5 GamePad API. [See configuration details](prompter.md#control-using-xbox-controller-modexbox) |
5050

5151
#### Control using mouse \(scroll wheel\)
5252

@@ -175,16 +175,16 @@ This mode uses the browsers Gamapad API and polls connected Joycons for their st
175175

176176
The Joycons can operate in 3 modes, the L-stick, the R-stick or both L+R sticks together. Reconnections and jumping between modes works, with one known limitation: **Transition from L+R to a single stick blocks all input, and requires a reconnect of the sticks you want to use.** This seems to be a bug in either the Joycons themselves or in the Gamepad API in general.
177177

178-
| Query parameter | Type | Description | Default |
179-
| :----------------------- | :--------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------- |
178+
| Query parameter | Type | Description | Default |
179+
| :----------------------- | :--------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------- |
180180
| `joycon_speedMap` | Array of numbers | Speeds to scroll by \(px. pr. frame - approx 60fps\) when scrolling forwards. The beginning of the forwards-range maps to the first number in this array, and the end of the forwards-range map to the end of this array. All values in between are being interpolated in a spline curve. | `[1, 2, 3, 4, 5, 8, 12, 30]` |
181-
| `joycon_reverseSpeedMap` | Array of numbers | Same as `joycon_speedMap` but for the backwards range. | `[1, 2, 3, 4, 5, 8, 12, 30]` |
182-
| `joycon_rangeRevMin` | number | The end of the backwards-range, full speed backwards. | `-1` |
183-
| `joycon_rangeNeutralMin` | number | The beginning of the backwards-range. | `-0.25` |
184-
| `joycon_rangeNeutralMax` | number | The minimum input to run forward, the start of the forward-range \(min speed\). This is also the end of any "deadband" you want filter out before starting moving forwards. | `0.25` |
185-
| `joycon_rangeFwdMax` | number | The maximum input, the end of the forward-range \(max speed\) | `1` |
186-
| `joycon_rightHandOffset` | number | A ratio to increase or decrease the R Joycon joystick sensitivity relative to the L Joycon. | `1.4` |
187-
| `joycon_invertJoystick` | 0 / 1 | Invert the joystick direction. When enabled, pushing the joystick forward scrolls up instead of down. | `1` |
181+
| `joycon_reverseSpeedMap` | Array of numbers | Same as `joycon_speedMap` but for the backwards range. | `[1, 2, 3, 4, 5, 8, 12, 30]` |
182+
| `joycon_rangeRevMin` | number | The end of the backwards-range, full speed backwards. | `-1` |
183+
| `joycon_rangeNeutralMin` | number | The beginning of the backwards-range. | `-0.25` |
184+
| `joycon_rangeNeutralMax` | number | The minimum input to run forward, the start of the forward-range \(min speed\). This is also the end of any "deadband" you want filter out before starting moving forwards. | `0.25` |
185+
| `joycon_rangeFwdMax` | number | The maximum input, the end of the forward-range \(max speed\) | `1` |
186+
| `joycon_rightHandOffset` | number | A ratio to increase or decrease the R Joycon joystick sensitivity relative to the L Joycon. | `1.4` |
187+
| `joycon_invertJoystick` | 0 / 1 | Invert the joystick direction. When enabled, pushing the joystick forward scrolls up instead of down. | `1` |
188188

189189
- `joycon_rangeNeutralMin` has to be greater than `joycon_rangeRevMin`
190190
- `joycon_rangeNeutralMax` has to be greater than `joycon_rangeNeutralMin`
@@ -241,11 +241,11 @@ The controller can be connected via Bluetooth or USB. **Note:** On macOS, Xbox c
241241

242242
**Configuration parameters:**
243243

244-
| Query parameter | Type | Description | Default |
245-
| :--------------------- | :--------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------- |
244+
| Query parameter | Type | Description | Default |
245+
| :--------------------- | :--------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------- |
246246
| `xbox_speedMap` | Array of numbers | Speeds to scroll by (px per frame, ~60fps) when scrolling forwards. Values are interpolated using a spline curve based on trigger pressure. | `[2, 3, 5, 6, 8, 12, 18, 45]` |
247247
| `xbox_reverseSpeedMap` | Array of numbers | Same as `xbox_speedMap` but for the backwards range (left trigger). | `[2, 3, 5, 6, 8, 12, 18, 45]` |
248-
| `xbox_triggerDeadZone` | number | Dead zone for the triggers, to prevent accidental scrolling. Value between 0 and 1. | `0.1` |
248+
| `xbox_triggerDeadZone` | number | Dead zone for the triggers, to prevent accidental scrolling. Value between 0 and 1. | `0.1` |
249249

250250
You can turn on `?debug=1` to see how your trigger input maps to scroll speed.
251251

‎packages/documentation/src/components/GitHubReleases.jsx‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ import IconExternalLink from '@docusaurus/theme-classic/lib/theme/Icon/ExternalL
44
const GITHUB_API_URL = 'https://api.github.com'
55

66
export default function GitHubReleases({ org, repo, releaseLabel, state }) {
7-
const [isReady, setIsReady] = useState(0) // 0 - not ready, 1 - loaded, 2 - failed permamently
7+
const [isReady, setIsReady] = useState(0) // 0 - not ready, 1 - loaded, 2 - failed permanently
88
const [releases, setReleases] = useState([])
99

1010
useEffect(() => {

‎packages/documentation/versioned_docs/version-1.52.0/for-developers/data-model.md‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,7 @@ In every case, any layout changes and any scheduled cleanup are performed by the
1818

1919
This category of collections is rather loosely defined, as it ends up being everything that doesn't belong somewhere else
2020

21-
This consists of anything that is configurable from the Sofie UI, anything needed soley for the UI and some other bits. Additionally, there are some collections which are populated by other portions of a Sofie system, such as by Package Manager, through an API over DDP.
21+
This consists of anything that is configurable from the Sofie UI, anything needed solely for the UI and some other bits. Additionally, there are some collections which are populated by other portions of a Sofie system, such as by Package Manager, through an API over DDP.
2222
Currently, there is not a very clearly defined flow for modifying these documents, with the UI often making changes directly with minimal or no validation.
2323

2424
This includes:
@@ -82,7 +82,7 @@ Some of these collections are used by Package Manager to initiate work, while ot
8282

8383
This category of collections is owned by the playout [worker threads](./worker-threads-and-locks.md), and is used to model the playout of a Rundown or set of Rundowns.
8484

85-
During the final stage of an ingest operation, there is a period where the ingest worker aquires a `PlaylistLock`, so that it can ensure that the RundownPlaylist the Rundown is a part of is updated with any necessary changes following the ingest operation. During this lock, it will also attempt to [sync any ingest changes](./for-blueprint-developers/sync-ingest-changes) to the PartInstances and PieceInstances, if supported by the blueprints.
85+
During the final stage of an ingest operation, there is a period where the ingest worker acquires a `PlaylistLock`, so that it can ensure that the RundownPlaylist the Rundown is a part of is updated with any necessary changes following the ingest operation. During this lock, it will also attempt to [sync any ingest changes](./for-blueprint-developers/sync-ingest-changes) to the PartInstances and PieceInstances, if supported by the blueprints.
8686

8787
As before, Meteor is allowed to write to these collections as part of migrations, and cleaning up old documents.
8888

@@ -127,6 +127,6 @@ Our solution to some of this early on was to not regenerate certain Parts when r
127127

128128
At this point in time, Adlib Actions did not exist in Sofie. They are able to change almost every property of a Part of Piece that ingest is able to define, which makes the resetting process harder.
129129

130-
PartInstances and PieceInstances were added as a way for us to make a copy of each Part and Piece, as it was selected for playout, so that we could allow ingest without risking affecting playout, and to simplify the cleanup performed. The PartInstances and PieceInstances are our record of how the Rundown was played, which we can utilise to output metadata such as for chapter markers on a web player. In earlier versions of Sofie this was tracked independently with an `AsRunLog`, which resulted in odd issues such as having `AsRunLog` entries which refered to a Part which no longer existed, or whose content was very different to how it was played.
130+
PartInstances and PieceInstances were added as a way for us to make a copy of each Part and Piece, as it was selected for playout, so that we could allow ingest without risking affecting playout, and to simplify the cleanup performed. The PartInstances and PieceInstances are our record of how the Rundown was played, which we can utilise to output metadata such as for chapter markers on a web player. In earlier versions of Sofie this was tracked independently with an `AsRunLog`, which resulted in odd issues such as having `AsRunLog` entries which referred to a Part which no longer existed, or whose content was very different to how it was played.
131131

132132
Later on, this separation has allowed us to more cleanly define operations as ingest or playout, and allows us to run them in parallel with more confidence that they won't accidentally wipe out each others changes. Previously, both ingest and playout operations would be modifying documents in the Piece and Part collections, making concurrent operations unsafe as they could be modifying the same Part or Piece.

‎packages/documentation/versioned_docs/version-1.52.0/for-developers/device-integrations/intro.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Introduction
22

3-
Device integrations in Sofie are part of the Timeline State Resolver (TSR) library. A device integration has a couple of responsibilites in the Sofie eco system. First and foremost it should establish a connection with a foreign device. It should also be able to convert Sofie's idea of what the device should be doing into commands to control the device. And lastly it should export interfaces to be used by the blueprints developer.
3+
Device integrations in Sofie are part of the Timeline State Resolver (TSR) library. A device integration has a couple of responsibilities in the Sofie eco system. First and foremost it should establish a connection with a foreign device. It should also be able to convert Sofie's idea of what the device should be doing into commands to control the device. And lastly it should export interfaces to be used by the blueprints developer.
44

55
In order to understand all about writing TSR integrations there are some concepts to familiarise yourself with, in this documentation we will attempt to explain these.
66

‎packages/documentation/versioned_docs/version-1.52.0/for-developers/for-blueprint-developers/lookahead.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -38,7 +38,7 @@ export enum LookaheadMode {
3838
}
3939
```
4040

41-
If undefined, `lookaheadMaxSearchDistance` currently has a default distance of 10 parts. This number was chosen arbitrarily, and could change in the future. Be careful when choosing a distance to not set it too high. All the Pieces from the parts being searched have to be loaded from the database, which can come at a noticable cost.
41+
If undefined, `lookaheadMaxSearchDistance` currently has a default distance of 10 parts. This number was chosen arbitrarily, and could change in the future. Be careful when choosing a distance to not set it too high. All the Pieces from the parts being searched have to be loaded from the database, which can come at a noticeable cost.
4242

4343
If you are doing [AB Playback](./ab-playback.md), or performing some other processing of the timeline in `onTimelineGenerate`, you may benefit from increasing the value of `lookaheadDepth`. In the case of AB Playback, you will likely want to set it to the number of players available in your pool.
4444

‎packages/documentation/versioned_docs/version-1.52.0/for-developers/for-blueprint-developers/manipulating-ingest-data.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ At times it can be useful to manipulate this data before it gets passed into the
77

88
A new method `processIngestData` was added to transform the `NRCSIngestRundown` into a `SofieIngestRundown`. The types of the two are the same, so implementing the `processIngestData` method is optional, with the default being to pass through the NRCS rundown unchanged. (There is an exception here for MOS, which is explained below).
99

10-
The basic implementation of this method which simply propogates nrcs changes is:
10+
The basic implementation of this method which simply propagates nrcs changes is:
1111

1212
```ts
1313
function processIngestData(

‎packages/documentation/versioned_docs/version-1.52.0/for-developers/for-blueprint-developers/part-and-piece-timings.mdx‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -131,7 +131,7 @@ const inTransition = {
131131

132132
Pieces with an infinite lifespan (ie, not `lifespan: PieceLifespan.WithinPart`) get handled differently to other pieces.
133133

134-
Only one pieceGoup is created for an infinite Piece which is present in multiple of the current, next and previous Parts.
134+
Only one pieceGroup is created for an infinite Piece which is present in multiple of the current, next and previous Parts.
135135
The Piece calculates and tracks its own started playback times, which is preserved and reused in future takes. On the timeline it lives outside of the partGroups, but still gets the same caps applied when appropriate.
136136

137137
### Interactive timings demo

0 commit comments

Comments
 (0)