A slider can now hold a float value and display it in the UI converted to
either a percentage or a decibel (still returning a linear float value
programmatically for the rest of the code).
Earlier, footage that was not the same frame rate as the sequence had the chance
of their length value falling between a frame. This doesn't really help anything
with video since a frame is a discrete point in time, and only led to confusion
while navigating the timeline.
Splitting commands would run CopyInputs after set_length. Since length is now
a parameter (aka a NodeInput) the former would override the latter breaking the
implementation. This commit fixes that.
OCIO config was set on a per-project basis, but we were using a singleton for
the ColorManager that would break if more than one project was ever open.
Now the ColorManager belongs to the Project and is always accessed through the
Project.
An earlier commit implementing media in and out parameters was primarily for
this addition. A simple control dialog for the clip's speed presentation
reimplemented from the old codebase.
The viewer had the color management backend in place already, but the frontend
was non-functional. This commit implements most if not all color management
functionality.
Previous iteration used some "magic code" that added clips automatically to the
timeline. This was functional but ultimately outside of the undo commands'
control meaning nodes could be infinitely added and abandoned. This makes the
add process part of the undo command which means it's all undoable as the user
would expect.
This will be useful for various reasons, however the behavior of selecting
gaps and transitions will need to be regulated harder than clips in the near
future.
This was many changes that were largely fundamentally related. They included:
- More const modifiers to enforce read only node graphs
- Support for fragment and vertex shaders from the nodes
- Support for node code loaded externally (embedded into the binary)
- Fixed issue preventing two textures from being used in a shader
- Removed several unused functions and cleaned up code
- Fixed video media node misreading its matrix input
Like the base "Block" type, the "Transition" type will not be a node used on its
own, it will have to be derived. This type defines some basic behavior for a
transition (e.g. how much it overlaps its "from" and "to" blocks).
Workers run in different threads and the backends can poll whether the worker
is currently busy or not. However the previous iteration has the worker (and an
atomic int) provide the busy state which could easily desync with the main
thread (since all workers run in different threads). By holding the busy states
in the main thread, the main thread will always be able to poll the busy state
accurately.
If Nodes only have the one output, we don't need to do so much differentiation
between them. Previous iteration used outputs as like a distinct function
within a Node (e.g. length output would return one result, buffer output would
produce a different result - each run different code to produce their results).
Now in this iteration, it's more accurate to say a Node is just one function
(which seems more appropriate for a node system anyway).
itsmattkc