This is the first step in what will eventually be keyframable time
remapping. The speed/duration dialog was a holdover from 0.1 and we can
probably do better here.
Improves stability and cache reliability.
Earlier iterations were prone to skipping necessary signals (usually
leading to some sort of assert fail), particularly when track
optimizations were used. Those optimizations have been moved to the
viewer node so there's a higher degree of control over which signals
get optimized and in which ways.
A huge optimization that ensures only the parts of a node graph that have
changed get pushed to the renderer. For thread-safety, the node graph is
copied elsewhere so that users can make changes asynchronously and the graph
can update when its threads are ready. Up until now, if an input value changed,
every node's values would be re-copied, or worse, if a connection was changed,
the entire graph would be recopied. This has been negligible in testing since
we've been largely testing with small graphs, but for massive projects, it's
important that this be as optimized as possible.
Implemented the ability to copy/paste blocks/clips in the timeline. This did
require some large scale changes and reworking of the copy/paste system
introduced a few commits ago, but should be largely functional now.
Since rationals aren't a known Qt format, the QVariant container can't
automatically convert them to and from strings (for XML serialization). We have
to hijack these functions and do the conversion manually for those types.
Also moved the block name type to a node input, which means it's serialized
and copied by default (I'm not sure why it wasn't already like this).
This functions more or less identically to using a media out value, but the
desired speed is preserved through block length changes, even if the block's
length is reduced to zero (i.e. no rounding errors).
Previously the non-keyframed value was stored as a static keyframe but this
introduced issues when an input was in a state of keyframes being enabled but
0 keyframes existing. Having a standard value makes much more sense.
Since all NodeInputs will generally only need their data type and default
value set once, we place it all into the constructor for cleaner and easier
to manage code.
With differently set speeds, these functions would mess with the timing in ways
that would be confusing to the user. Now they act in a much more intuitive way
and also prevent negative media times.
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.
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.
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).
Since the nodes won't be holding any rendering data themselves in this system,
we may as well enforce some level of non-write access by setting all the
functions to const. They were already const-friendly, they just weren't
labelled as such.
Fixes recurring design issue that the Blocks were a frequent exception to the
DAG concept. The Blocks connecting to each others inputs/outputs while not
necessarily being "dependent" on each other to produce an image continually
causes issues while trying to create a rendering code path. This redesign
should provide a more "directed" approach to the directed acyclic graph.
It was becoming inevitable to get rid of this, it was continuously an exception
that had to be made to the DAG concept seeing as blocks are never really
"dependents" on each other, i.e. the images they produce have nothing to do
with other blocks. The only exception is a transition which will also be
easier to accomplish with this slightly different design.
A signal emitted and received in the same thread will call other functions
before returning to the one that emitted the signal. If these other functions
try to lock a mutex while a mutex is already locked by the emitting function,
we get stuck in a deadlock. These changes ensure that a signal is never emitted
by any function until all the nodes locked by it are unlocked.
Many changes were made throughout the codebase to support audio, these are
most of the small changes necessary.
The audio support still is not perfect. I still need to write in resampling
support. After that it should work correctly with all audio types.
The new rendering pipeline strives to simplify the nodes themselves as much
as possible and move much of the logic to an external rendering engine. This
change removes all of the responsibilities that no longer belong to the
nodes themselves and will soon be folded into the renderer.
Nodes were previously written to be "strongly typed" in that a parameter's
"type" enforced whether it could be connected to another. All code related
to that has now been removed since not only is it hard to maintain and
likely unnecessary, it's possible the nodes will work differently later on
anyway.
itsmattkc