You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: packages/documentation/docs/user-guide/concepts-and-architecture.md
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,19 +15,19 @@ It is a [NodeJS](https://nodejs.org/) process backed up by a [MongoDB](https://w
15
15
16
16
### Gateways
17
17
18
-
Gateways are applications that connect to Sofie Core and and exchanges data; such as rundown data from an NRCS or the [Timeline](#timeline) for playout.
18
+
Gateways are applications that connect to Sofie Core and exchange data; such as rundown data from an NRCS (Newsroom Computer System) or the [Timeline](#timeline) for playout.
19
19
20
-
An examples of a gateways is the [Spreadsheet Gateway](https://github.com/SuperFlyTV/spreadsheet-gateway).
20
+
An example of a gateway is the [Spreadsheet Gateway](https://github.com/SuperFlyTV/spreadsheet-gateway).
21
21
All gateways use the [Core Integration Library](https://github.com/nrkno/sofie-core/tree/master/packages/server-core-integration) to communicate with Core.
22
22
23
23
## System, \(Organization\), Studio & Show Style
24
24
25
-
To be able to facilitate various workflows and to Here's a short explanation about the differences between the "System", "Organization", "Studio" and "Show Style".
25
+
To be able to facilitate various different kinds of show, Sofie Core has the concepts of "System", "Organization", "Studio" and "Show Style".
26
26
27
27
- The **System** defines the whole of the Sofie Core
28
28
- The **Organization**\(only available if user accounts are enabled\) defines things that are common for an organization. An organization consists of: **Users, Studios** and **ShowStyles**.
29
29
- The **Studio** contains things that are related to the "hardware" or "rig". Technically, a Studio is defined as an entity that can have one \(or none\) rundown active at any given time. In most cases, this will be a representation of your gallery, with cameras, video playback and graphics systems, external inputs, sound mixers, lighting controls and so on. A single System can easily control multiple Studios.
30
-
- The **Show Style** contains settings for the "show", for example if there's a "Morning Show" and an "Afternoon Show" - produced in the same gallery - they might be two different Show Styles \(played in the same Studio\). Most importantly, the Show Style decides the "look and feel" of the Show towards the producer/director, dictating how data ingested from the NRCS will be interpreted and how the user will interact with the system during playback (see: [Show Style](../configuration/settings-view#show-style) in Settings).
30
+
- The **Show Style** contains settings for the "show", for example if there's a "Morning Show" and an "Afternoon Show" - produced in the same gallery - they might be two different Show Styles \(played in the same Studio\). Most importantly, the Show Style decides the "look and feel" of the Show towards the producer/director, dictating how data ingested from the NRCS will be interpreted and how the user will interact with the system during playback (see: [Show Style](configuration/settings-view#show-style) in Settings).
31
31
- A **Show Style Variant** is a set of Show Style _Blueprint_ configuration values, that allows to use the same interaction model across multiple Shows with potentially different assets, changing the outward look of the Show: for example news programs with different hosts produced from the same Studio, but with different light setups, backscreen and overlay graphics.
@@ -40,7 +40,7 @@ To be able to facilitate various workflows and to Here's a short explanation abo
40
40
41
41
A Playlist \(or "Rundown Playlist"\) is the entity that "goes on air" and controls the playhead/Take Point.
42
42
43
-
It contains one or several Rundowns inside, which are playout out in order.
43
+
It contains one or more Rundowns, which are played out in order.
44
44
45
45
:::info
46
46
In some many studios, there is only ever one rundown in a playlist. In those cases, we sometimes lazily refer to playlists and rundowns as "being the same thing".
@@ -78,7 +78,7 @@ See also: [Showstyle](#system-organization-studio--show-style)
78
78
79
79
### AdLib Piece
80
80
81
-
The AdLib pieces are Pieces that isn't programmed to fire at a specific time, but instead intended to be manually triggered by the user.
81
+
The AdLib pieces are Pieces that aren't programmed to fire at a specific time, but instead intended to be manually triggered by the user.
82
82
83
83
The AdLib pieces can either come from the currently playing Part, or it could be _global AdLibs_ that are available throughout the show.
84
84
@@ -100,7 +100,7 @@ Being a web-based system, Sofie has a number of customisable, user-facing web [v
100
100
101
101
Blueprints are plug-ins that run in Sofie Core. They interpret the data coming in from the rundowns and transform them into a rich set of playable elements \(Segments, Parts, AdLibs etc\).
102
102
103
-
The blueprints are webpacked javascript bundles which are uploaded into Sofie via the GUI. They are custom-made and changes depending on the show style, type of input data \(NRCS\) and the types of controlled devices. A generic [blueprint that works with spreadsheets is available here](https://github.com/SuperFlyTV/sofie-demo-blueprints).
103
+
The blueprints are webpacked javascript bundles which are uploaded into Sofie via the GUI. They are custom-made and vary depending on the show style, type of input data \(NRCS\) and the types of controlled devices. A generic [blueprint that works with spreadsheets is available here](https://github.com/SuperFlyTV/sofie-demo-blueprints).
104
104
105
105
When [Sofie Core](#sofie-core) calls upon a Blueprint, it returns a JavaScript object containing methods callable by Sofie Core. These methods will be called by Sofie Core in different situations, depending on the method.
106
106
Documentation on these interfaces are available in the [Blueprints integration](https://www.npmjs.com/package/@sofie-automation/blueprints-integration) library.
@@ -111,19 +111,19 @@ There are 3 types of blueprints, and all 3 must be uploaded into Sofie before th
111
111
112
112
Handle things on the _System level_.
113
113
Documentation on the interface to be exposed by the Blueprint:
@@ -152,7 +152,7 @@ The Sofie system is made to work with a modern web- and IT-based approach in min
152
152
One drawback of running in a cloud over the public internet is the - sometimes unpredictable - latency. The Timeline overcomes this by moving all the immediate control of the playout devices to the Playout Gateway, which is intended to run on a local network, close to the hardware it controls.
153
153
This also gives the system a simple way of load-balancing - since the number of web-clients or load on Sofie Core won't affect the playout.
154
154
155
-
Another benefit of basing the playout on a timeline is that when programming the show \(the blueprints\), you only have to care about "what you want to be on screen", you don't have to care about cleaning up previously played things, or what was actually played out before. Those are things that are handled by the Playout Gateway automatically. This also allows the user to jump around in a rundown freely, without the risk of things going wrong on air.
155
+
Another benefit of basing the playout on a timeline is that when programming the show \(the blueprints\), you only have to care about "what you want to be on screen", you don't have to care about cleaning up previously played things, or what was actually played out before. This is handled by the Playout Gateway automatically. This also allows the user to jump around in a rundown freely, without the risk of things going wrong on air.
156
156
157
157
### How does it work?
158
158
@@ -181,7 +181,7 @@ The TSR then...
181
181
- Maps the target-state to each playout device
182
182
- Compares the target-states for each device with the currently-tracked-state and..
183
183
- Generates commands to send to each device to account for the change
184
-
-The commands are then put on queue and sent to the devices at the correct time
184
+
-Puts the commands on the queue and sends them to the devices at the correct time.
185
185
186
186
:::info
187
187
For more information about what playout devices _TSR_ supports, and examples of the timeline-objects, see the [README of TSR](https://github.com/nrkno/sofie-timeline-state-resolver#timeline-state-resolver)
Copy file name to clipboardExpand all lines: packages/documentation/docs/user-guide/configuration/settings-view.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -63,7 +63,7 @@ The Studio uses a studio-blueprint, which handles things like mapping up an inco
63
63
64
64
### Attached Devices
65
65
66
-
This section allows you to add and remove Gateways that are related to this _Studio_. When a Gateway is attached to a Studio, it will react to the changes happening within it, as well as feed the neccessary data into it.
66
+
This section allows you to add and remove Gateways that are related to this _Studio_. When a Gateway is attached to a Studio, it will react to the changes happening within it, as well as feed the necessary data into it.
67
67
68
68
### Blueprint Configuration
69
69
@@ -144,19 +144,19 @@ The triggers are designed to be either client-specific or issued by a peripheral
144
144
145
145
Currently, the Action Triggers system supports setting up two types of triggeers: Hotkeys and Device Triggers.
146
146
147
-
Hotkeys are valid in the scope of a browser window and can be either a single key, a combination of keys (_combo_) or a _chord_ - a sequnece of key combinations pressed in a particular order. _Chords_ are popular in some text editing applications and vastly expand the amount of actions that can be triggered from a keyboard, at the expense of the time needed to execute them. Currently, the Hotkey editor in Sofie does not support creating _Chords_, but they can be specified by Blueprints during migrations.
147
+
Hotkeys are valid in the scope of a browser window and can be either a single key, a combination of keys (_combo_) or a _chord_ - a sequence of key combinations pressed in a particular order. _Chords_ are popular in some text editing applications and vastly expand the amount of actions that can be triggered from a keyboard, at the expense of the time needed to execute them. Currently, the Hotkey editor in Sofie does not support creating _Chords_, but they can be specified by Blueprints during migrations.
148
148
149
149
To edit a given trigger, click on the trigger pill on the left of the Trigger-Action set. When hovering, a **+** sign will appear, allowing you to add a new trigger to the set.
150
150
151
-
Device Triggers are valid in the scope of a Studio and will be evaluated on the currently active Rundown in a given Studio. To use Device Triggers, you need to have at least a single [Input Gateway](../installation/installing-input-gateway) attached to a Studio and a Device configured in the Input Gateway. Once that's done, when selecting a **Device** trigger type in the pop-up, you can invoke triggers on your Input Device and you will see a preview of the input events shown at the bottom of the pop-up. You can select which of these events should be the trigger by clicking on one of the previews. Note, that some devices differentiate between _Up_ and _Down_ triggers, while others don't. Some may also have other activites that can be done _to_ a trigger. What they are and how they are identified is device-specific and is best discovered through interaction with the device.
151
+
Device Triggers are valid in the scope of a Studio and will be evaluated on the currently active Rundown in a given Studio. To use Device Triggers, you need to have at least a single [Input Gateway](../installation/installing-input-gateway) attached to a Studio and a Device configured in the Input Gateway. Once that's done, when selecting a **Device** trigger type in the pop-up, you can invoke triggers on your Input Device and you will see a preview of the input events shown at the bottom of the pop-up. You can select which of these events should be the trigger by clicking on one of the previews. Note, that some devices differentiate between _Up_ and _Down_ triggers, while others don't. Some may also have other activities that can be done _to_ a trigger. What they are and how they are identified is device-specific and is best discovered through interaction with the device.
152
152
153
153
If you would like to set up combination Triggers, using Device Triggers on an Input Device that does not support them natively, you may want to look into [Shift Registers](#shift-registers)
154
154
155
155
#### Actions
156
156
157
157
The actions are built using a base _action_ (such as _Activate a Rundown_ or _AdLib_) and a set of _filters_, limiting the scope of the _action_. Optionally, some of these _actions_ can take additional _parameters_. These filters can operate on various types of objects, depending on the action in question. All actions currently require that the chain of filters starts with scoping out the Rundown the action is supposed to affect. Currently, there is only one type of Rundown-level filter supported: "The Rundown currently in view".
158
158
159
-
The Action Triggers user interface guides the user in a wizzard-like fashion through the available _filter_ options on a given _action_.
159
+
The Action Triggers user interface guides the user in a wizard-like fashion through the available _filter_ options on a given _action_.
160
160
161
161
Copy file name to clipboardExpand all lines: packages/documentation/docs/user-guide/configuration/sofie-core-settings.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -97,7 +97,7 @@ There are various settings you can set for an installation. See the list below:
97
97
|`followOnAirSegmentsHistory`| How many segments of history to show when scrolling back in time (0 = show current segment only) |`0`|
98
98
|`maximumDataAge`| Clean up stuff that are older than this [ms]) | 100 days |
99
99
|`poisonKey`| Enable the use of poison key if present and use the key specified. |`'Escape'`|
100
-
|`enableNTPTimeChecker`| If set, enables a check to ensure that the system time doesn't differ too much from the speficied NTP server time. |`null`|
100
+
|`enableNTPTimeChecker`| If set, enables a check to ensure that the system time doesn't differ too much from the specified NTP server time. |`null`|
101
101
|`defaultShelfDisplayOptions`| Default value used to toggle Shelf options when the 'display' URL argument is not provided. |`buckets,layout,shelfLayout,inspector`|
102
102
|`enableKeyboardPreview`| The KeyboardPreview is a feature that is not implemented in the main Fork, and is kept here for compatibility |`false`|
103
103
|`keyboardMapLayout`| Keyboard map layout (what physical layout to use for the keyboard) | STANDARD_102_TKL |
|**studio**| Grants access to operate a studio for playout of a rundown. |
15
-
|**configure**| Grants access to the settings pages of Sofie, and other abilities to configure the system. |
16
-
|**developer**| Grants access to some tools useful to developers. This also changes some ui behaviours to be less agressive in what is shown in the rundown view |
17
-
|**testing**| Enables the page Test Tools, which contains various tools useful for testing the system during development |
18
-
|**service**| Grants access to the external message status page, and some additional rundown management options that are not commonly needed |
19
-
|**gateway**| Grants access to various APIs intended for use by the various gateways that connect Sofie to other systems. |
|**studio**| Grants access to operate a studio for playout of a rundown. |
15
+
|**configure**| Grants access to the settings pages of Sofie, and other abilities to configure the system. |
16
+
|**developer**| Grants access to some tools useful to developers. This also changes some ui behaviours to be less aggressive in what is shown in the rundown view |
17
+
|**testing**| Enables the page Test Tools, which contains various tools useful for testing the system during development |
18
+
|**service**| Grants access to the external message status page, and some additional rundown management options that are not commonly needed |
19
+
|**gateway**| Grants access to various APIs intended for use by the various gateways that connect Sofie to other systems. |
0 commit comments