Implemented basic audio animation.
* AnimatableProperty: Propper cache writing and spline interpolation for reading (the solution for stair steps in audio animation)
* Animatable properties so far are: volume, pitch, panning
* Users note: Changing the pitch of a sound results in wrong seeking, due to the resulting playback length difference.
* Users note: Panning only works for mono sources, values are in the range [-2..2], this basically controls the angle of the sound, 0 is front, -1 left, 1 right and 2 and -2 are back. Typical stereo panning only supports [-1..1].
* Disabled animation of audio related ffmpeg output parameters.
* Scene Audio Panel: 3D Listener settings also for Renderer, new Volume property (animatable!), Update/Bake buttons for animation problems, moved sampling rate and channel count here
This commit adds an experimental effect strip to the sequencer: "Title
Card".
This is useful for adding simple one-line text section headers or
"title cards" (i.e. title + author/contact details) to video clips,
which is often seen in demo videos accompanying papers and/or
animation tests.
See http://aligorith.blogspot.com/2011/06/gsoc11-simple-title-
cards.html for some more details on usage.
Code notes:
- There are a few things I've done here which will probably need
cleaning up. For instance, the hacks to get threadsafe fonts for
rendering, and also the way I've tried to piggyback the backdrop
drawing on top of the Solid Colour strips (this method was used to
keep changes here minimal, but is quite fragile if things change).
This patch adds adjustment layer tracks to the sequencer and does some cleaning
up of the code.
What's an adjustment layer?
Think of it as an effect track, which takes no explicit input, but alters
the output of everything down the layer stack.
So: you can add several stages of color correction with it.
And: you can even use it with metastrips to group several adjustments together.
- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
* documented and rewrote the render interface of the sequencer.
(now, the geometry / render_type / etc. settings are stored within a
seperate structure called SeqRenderData that is passed within the code.)
* that fixes
* cache problems, since the caching system didn't keep track of
proxy files vs. final renders.
* is a necessary step, to bring back frame blending in speed effect
(the SeqRenderData structure elements are already there)
* will make motion blur render options available within the sequencer!
* this patch also fixes:
* "easy retiming" using speed effects. (in Blender 2.49, you could
add a speed effect and resize the source track to retime it to that
length)
* adds labels for the Original dimensions for Image + Movie tracks
(worked in 2.49, too)
also known as: broken multicam strip caused by other fix.
Calculated render_size where it belongs (within the glow effect) and
restored old functionality.
also: renamed render_size to preview_render_size at all relevant places,
where the naming wasn't used correctly.
Hopefully it's now a little bit more clear.
render_size := render size from scene (just rescales width/height)
preview_render_size := preview render size from sequencer preview,
controls the resolution and the use of sequencer proxy sources
- omit render code from this warning (cmake only), until render branch is merged.
- moved -Wunused-parameter warning to apply to all C code in blender (not just ./source/blender), (cmake only).
- removed deprecated bitmap arg from IMB_allocImBuf (plugins will need updating).
- mostly tagged UNUSED() since some of these functions look like they may need to have the arguments used later.
* Sequence speed effect was functional in theory, but very difficult to actually use.
* Now the effect works as follows:
- "Speed Factor" (formerly "speed fade") controls the current speed of the sequence (can be animated).
- "Use as speed" (formerly "f-curve velocity") is now the default behavior so that the "speed effect" by default changes the "speed" of the sequence.
- "Multiply Speed" (formerly "global speed") is a scale factor that's applied to the calculated frame (can't be animated).
- Without animation "Speed Factor" and "Multiply Speed" work exactly the same (in this case "multiply speed" could perhaps be disabled in ui, but currently there's no easy way to check this).
- If "Use as speed" is not checked the effect simply remaps the current frame to the given "Frame Number" (can be animated).
- "Scale to length" (formerly "f-curve compress y")scales "Frame numbers" from 0.0-1.0 to the length of the target strip to allow easy animation.
* Tooltips added for all values and options.
* Code for frame blending was nowhere to be seen, so I commented the option out from ui.
* This should fix at least bugs #20979 and #21309.
This fixes: [#23184] Problems with speed control effect strip in the
video sequence editor
Also: got rid of tstripdata caches in DNA.
Fixes some potential crashes in SEQ_IMAGE rendering (s_elem wasn't
checked for NULL).
Some cleanup on effects:
- converted interface to float cfra
- made effects return their own ImBufs, which has the following
advantages:
* code in sequencer.c is a lot more readable.
* multicam saves one memcpy of an image
* prepares things for GPU-rendering
This patch cleans up the sequencer core by replacing the caching system
(TStripElems) with a hash based system, which is:
a) a lot faster
b) a lot more readable
c) a lot more memory conserving
The new caching system is also a good building ground for
a) sub frame precision rendering (even on scene strips)
b) multi core rendering (threaded rendering is still disabled, but can
be extended now to arbitrary core numbers)
I tested the code on an extensive editing session today and had no
crashes during 4 hours of editing. So I consider it very stable.
This adds MULTICAM-editing support for blender. (Well, the beginning of.)
There is now a new effect track, named MULTICAM, which just selects
one of the lower tracks.
Doesn't sound that exciting, but if you combine this with A/B-Trim (moving
split points of two directly connected tracks around, while magically
resizing both strips, something to be added), you just do:
* add several tracks for your camera angles
* (optionally) sync those tracks
* add one multicam track on top
Use that multicam-track to edit your movie. (Either using fcurves on the
multicam source selector or using knife-tool and A/B-Trim.)
Compare that to:
* add several tracks
* add cross fades between them
* do some python scripting to add several fcurves to make that beast
somewhat work.
* cry out loud, using it, if you have to move cut points around
Alternatively, even harder:
* just edit the old way and put strip after strip
You might think, that this isn't really helpfull for animators, but
consider using scene-strips (in OpenGL-mode) for input, that are set for
different camera angles and can now be intercut a lot more easily...
Also: small fix on the way: the speed effect can now be used in cascade.
(Don't know, if anyone used it that way, but now it works.)
