Comments (7)
Great to finally see our brand name in lights @hummelstrand - it's been a long-time coming (thinking back to those open CasparCG sessions in Birmingham and London in the previous decade!)
from sofie-core.
Meeting notes, Workshop January 22nd
Use cases
We discussed and listed various possible use cases
Editing Pieces
- Change Piece from camera 1 to camera 2 (no side effects)
- Change Piece from camera 1 to camera 2 (side effects)
Where the change has side effects on other Pieces, eg a studio light and mic is ON when on camera 2. - Change Piece from camera 1 to OS (“outside source”) 2
Side effect: mics - re-timing (or remove) a gfx Piece in a Part
- using a MOS plugin
- using dragging of the Piece in Sofie GUI
- Trimming VT in/out points
- Replace a VT with another
The new VT Piece should automatically get new timings according to the new VT. - Update spelling in a gfx
(possibly using a MOS plugin?)
Editing Parts
- Move a Piece from a Part into another Part
Does this change things about the piece? I.e. is it also editing pieces? - Change Part from camera 1 to Full VT
- Lock the (edited) contents of a Part from NRCS updates
- Protect from changes
- Protect from deletions
- Moving a Part within a rundown
- Changing a clip from a “package”/VT to “voice-over”
Side effect: mic levels - Delete a Part (and un-delete a previously deleted Part)
- Make a Part “invalid”
(this is useful in order to skip a Part)
Creating new content
- Insert/Create a new Part from “nothing” or “something”
- Create a Part from a “piece” or mos-object (dragging in from NRCS)
- Insert/Create a new Piece from “nothing” or “something”
- Add/remove/edit Transitions
- Add/remove/edit Adlibs
Editing the rundown
- Dragging/moving Parts
- Move/Add/edit/delete Segments
- Add/remove/edit Global Adlibs
Initial Architectural thoughts
A VERY short discussion on possible solutions.
“Editing the Next PartInstance”
Easy implementation, but very limited useability, might be a short term solution?
“Instantiate the whole Rundown as PartInstances”
Hard to envision how it could work? Likely a dead end?
“Add manipulation stage(s) to the ingest data flow”
A large addition to the data flow.
Significant effort needed in implementing this, but possibly doable.
“Rework the ingest data flow to have fine grained reactions to every NRCS update”
A complete change in how we take in updates.
Significant effort needed in implementing this, but possibly doable.
“Write back changes to the NRCS”
Keeps the "single source of truth".
Likely to be a problem with some NRCSes that don't support write-back.
Other notes from the discussions
- It should be possible to define “editing rules”, eg “user should not be able to change a cam1 to a VT”.
- It would be good to define what is the scope of this work, to have a stopping poind and avoid feature creep.
Next workshop
Another workshop is planned for Monday, January 29th at 14:00 CET (13:00 GMT).
In preparation for next workshop
BBC and NRK will rank the use cases from blocker → important → later → not important
Agenda:
- Architectural discussions
- Relate solutions to use cases
If anyone else wishes to join the series of workshops, please email me at [email protected]
from sofie-core.
Thank you for submitting this RFC!
(If you haven’t already, please give our contribution guidelines a read.)
The Sofie Team thinks that this is a very interesting idea, it is something we've been discussing internally before as well.
This type of change would likely affect a fairly large chunk of the ingest logic in Sofie, therefore we think that several workshops would be needed to make an implementation plan, to ensure we come up with something that works well and is sustainable.
We propose a first workshop on Monday, January 22nd at 14:00 CET (13:00 GMT), where we can discuss the use cases and possible solutions.
Agenda, Workshop 1
- Presentation of the RFC from BBC
- Outlining of use cases
Discuss the use cases, ideate other use cases and potential edge cases/pitfalls.- Which would be required initially?
- Which would be optional / for the future?
- Initial (short) discussion of possible architectural solutions.
- Planning of next workshop
If anyone else wishes to join the workshop, pleas email me at [email protected]
from sofie-core.
Hi - just joining this thread. Great meeting today, thanks all.
from sofie-core.
Meeting notes, Workshop January 29th
Use case prioritizations
BBC's priorities are
- Most important:
- cases related to changing properties of Pieces (ie cam 1 to cam 3)
- cases rekated to changing the type of Story (ie change a VT with full audio to "No audio"
- Disable/Remove a gfx Piece
- Nice-to-have
- Update spelling in a gfx (eg using mos plugin)
- change timing a gfx Piece
It was noted that side-effects (ie a mic fader changes due to a changed camera) are likely to happen in all relevant use cases.
MOS Plugin
Discussion on the subject of MOS Plugin support in Sofie to edit for example gfx Pieces.
- Because the gfx Piece content is defined by the gfx system, it will be hard/unsafe to edit it directly in Sofie.
One solution could be for Sofie to support loading a MOS Plugin in an iframe which is used to edit the gfx Piece. The mos-protocol API for MOS Plugins (using iframepostMessage
) could be used for this. - We should probably support both editing a Piece by using an internal inspector and/or a MOS Plugin to edit data.
- Question: When implementing the inspector, what should the inputs support? Uploading images? Food for thought.
Implementation options
We discussed briefly the options brought up last week.
The two options
- “Add manipulation stage(s) to the ingest data flow”
- “Rework the ingest data flow to have fine grained reactions to every NRCS update”
seems to be the most feasible to continue thinking about. The other options where discarded.
It was noted that there is a high likelihood that the implementation affects the implementation planned in #1126 . Care should be taken to coordinate implementation efforts.
Technical workshop
We concluded that the next step is to have an in-depth technical workshop on designing the architectural structures.
Questions to be answered by the technical workshop:
- Does the proposed solution support all of the above mentioned use cases?
- Can the proposed solution be implented in stages?
- How small can an initial implementation be for a PoC or MVP?
The technical workshop will be held this week, joined by @nytamin, @PeterC89, @Julusian, @mint-dewit and @jstarpl .
Next workshop
Another workshop is planned for Monday, February 5th at 14:00 CET (13:00 GMT) Thursday, February 8th at 14:00 CET (13:00 GMT).
Agenda:
- Presentation from the technical workshop
- Future / implementation plan?
If anyone else wishes to join the series of workshops, please email me at [email protected]
from sofie-core.
Note: The next workshop is moved to Thursday, February 8th at 14:00 CET (13:00 GMT), to give the technical workshop group time to finish up.
If anyone else wishes to join the series of workshops, please email me at [email protected]
from sofie-core.
Meeting notes, Workshop February 8th
Presentation from the technical workshop group
A series of technical workshops have been held during the past week, which have resulted in the following proposal (presented by @mint-dewit and @Julusian on behalf of BBC).
How Sofie works right now
- INGEST STAGE
a. Data from NRCS is sent into Sofie Core via MOS Gateway (or another ingest gateway)
b. Sofie Core maintains a copy of the (NRCS)ingestRundown
and applies MOS upates onto it.
c. Blueprints transforms theingestRundown
into Segments, Parts & Pieces. - PLAYOUT STAGE
a. Sofie Core: Play Parts and Pieces, using PartInstances & PieceInstances & generate the Timeline
b. Playout Gateway: Executes the Timeline
Our proposal
We propose to add a second stage on the ingest side, and add a new Blueprint method which can selectively choose how to update the SourceData
, using the NRCS IngestRundown
and user-edit-action as input.
- INGEST STAGE
a. Data from NRCS is sent into Sofie Core via MOS Gateway (or another ingest gateway)
b. Sofie Core maintains a copy of the (NRCS)ingestRundown
and applies MOS upates onto it.
c. Sofie Core maintainsSourceData
in the DB
d. Blueprints updates theSourceData
selectively, using theingestRundown
and user-edit-action results as input. - CONTENT STAGE
a. Blueprints transforms theSourceData
into Segments, Parts & Pieces. - PLAYOUT STAGE
a. Sofie Core: Play Parts and Pieces, using PartInstances & PieceInstances & generate the Timeline
b. Playout Gateway: Executes the Timeline
Note: The SourceData
has the same type definition as the previous IngestRundown
, so it'll be backwards compatible with Blueprints.
With this proposal, the Blueprints will now have full control of the rundown data and have the ability to e.g. split stories into segments, reject updates or insert data freely.
This change will be backwards compatible, as there can be implemented a simple fallback blueprint method with the functionality of simply "accept all data from the NRCS, and split stories into segments using the ";"
delimiter".
Blueprint helpers
In order to make it easier to write blueprints, we propose that we eventually add a few "helper function", to be used by the blueprints for common operations such as "basic editing of properties", "move a Part", "invert change/undo/redo". Not needed initially though.
User Actions
Blueprints will now be able to define user-edit-action manifests on Parts and Pieces, allowing the Sofie GUI to provide the user with editing capabilities to match.
The exact types of user-edit-actions and their UX is not handled in this RFC, but some potental ones are:
- Edit propterties in a web form (defined by a schema)
- Display a MOS Plugin to edit something
- Display drag-handlers to be able to drag Pieces, or Parts
- Drop MOS objects into the GUI to insert Parts/Pieces
When a user makes an user-edit-action, the result is sent into 1.d step above, and so the Part will be regenerated downstream.
Future
- After this change, we could potentially replace the
blueprint.getSegment
with ablueprint.getPart
instead. Allowing for a finer update granularity, resulting in better performance.
Questions
- Q: Does this mean that we could potentially have more than one data source to generate the Rundowns from?
A: Yes, that could be a natural continuation after this has been implemented. - Q: So how would the default helper functions work? How do we decide what is a default functionality?
A: We'll begin by implementing it all in blueprints-only to begin with. Then, when we've gathered knowledge and proven the concepts, we'll start looking into moving the some of the blueprint code into Sofie Core functionality and exposing it as "helper functions". - Q: How would Mos active/inactive (and reloading NRCS data) work?
A: It would be possible to distinguish between changed data vs just a reload (for example by using modified timestamp), so the blueprints would be able to intelligently handle this situation. - Q: Should the blueprints be able to reject a "removed rundown" input?
A: Yeah, probably. That would be a good use case to take into account.
Next steps
We consider the discussions on this RFC to be concluded for now.
If anyone else have any opinions or questions regarding this, feel free to post questions in this thread, or contact me at [email protected].
from sofie-core.
Related Issues (20)
- RFC: This is a test
- RFC: This is a test
- RFC: Changes and addition to (meta)data properties (SOFIE-2797) HOT 5
- RFC: Updating the Looping Feature with Per-Part Looping HOT 9
- RFC: Removing potentially unused feature: 'Preserve contents of playing segment when unsynced' HOT 5
- RFC: Playlist Bucket Adlibs HOT 5
- Bug Report: Runaway playhead (SOFIE-2899) HOT 3
- Bug Report: AutoNexting missed Parts after Playout Gateway downtime HOT 1
- RFC: Improve GUI Accessibility HOT 1
- RFC: iNews compatiblity with segments HOT 5
- Bug Report: "debug_playlistRunBlueprints" breaks 'Reload NRCS Data' HOT 2
- Bug Report: Pieces reported as stopped when they're not
- Bug Report: Package statuses incorrectly get changed when set as next HOT 4
- Bug Report: Diff Different between (SOFIE-3004) HOT 1
- Bug Report: Inital Sofie Core Setup : Issue with Persistant Storage HOT 6
- RFC: Picking future technologies HOT 4
- RFC: Segment budget timing as primary timing in Sofie HOT 1
- RFC: Server-side notifications HOT 2
- Bug Report: Device Triggers temporarily go blank HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sofie-core.