Currently retiming is quite awkward, when you need to retime multiple
strips strips in sync. It is possible to use meta strips, but this is
still not great. This is resolved by implementing selection.
General changes:
Gizmos are removed, since they are designed to operate only on active
strip and don't support selection.
Transform operator code is implemented for retiming data, which allows
more sophisticated manipulation.
Instead of drawing marker-like symbols, keyframes are drawn to
represent retiming data. Retiming handles are now called keys. To have
consistent names, DNA structures have been renamed.
Retiming data is drawn on strip as overlay.
UI changes:
Retiming tool is removed. To edit retiming data, press Ctrl + R, select
a key and move it. When retiming is edited, retiming menu and
context menu shows more relevant features, like making transitions.
Strip and retiming key selection can not be combined. It is possible to
use box select operator to select keys, if any key is selected.
Otherwise strips are selected.
Adding retiming keys is possible with I shortcut or from menu.
Retiming keys are always drawn at strip left and right boundary. These
keys do not really exist until they are selected. This is to simplify
retiming of strips that are resized. These keys are called "fake keys"
in code.
API changes:
Functions, properties and types related to retiming handles are renamed
to retiming keys:
retiming_handle_add() -> retiming_key_add()
retiming_handle_move() -> retiming_key_move()
retiming_handle_remove() -> retiming_key_remove()
retiming_handles -> retiming_keys
RetimingHandle -> RetimingKey
Retiming editing "mode" is activated by setting `Sequence.show_retiming_keys`.
Pull Request: https://projects.blender.org/blender/blender/pulls/109044
To reproduce build error, set `WITH_AUDASPACE` to `ON` in `blender_lite.cmake` and build using `make lite`.
The problem is that the function `AUD_Sound_equalize` is declared in `blender/extern/audaspace/bindings/C/AUD_Sound.h` within `WITH_CONVOLUTION` and not `WITH_AUDASPACE`.
Pull Request: https://projects.blender.org/blender/blender/pulls/111994
This commit disambiguates the following messages:
- Sequencer effect strip types: use "Sequence" context in relevant
places, as that is already extracted as part of the
`sequencer_prop_effect_types` enum, and more specific.
- "Language" (a natural or programming language)
- "Flat" (gender)
- "Smooth" (action or amount -- very partial disambiguation for now
because this is all over the place)
It also extracts these messages:
- Newly created Freestyle data
- LineStyle
- LineSet
- Modifiers
- "Registering panel class:" error message from RNA registration
- "Node must be run as tool" error message from tool geometry nodes
Ref #43295
Pull Request: https://projects.blender.org/blender/blender/pulls/111146
The sound equalizer is using the Audaspace FFT Convolver.
The blender part creates an array of descriptions of power per "band"
and orders the creation of Equalizer (ISound) in the Audaspace.
Modifier can be created on sound strips. It lets you define
amplification or attenuation over frequency range from 30Hz to 20 kHz.
The power is limited to -30 db - 30 db. This is done using curve
mapping widget.
Co-authored-by: menda <alguien@aqui.es>
Co-authored-by: Richard Antalik <richardantalik@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/105613
With such small proxy sizes (combined with a small blur radius), the
kernels `halfWidth` can get zero, which leads to a memory allocation of
same zero size and writing to that memory leads to overflow/crashes/can
only go downhill from there.
Now early out in such cases [which leads to
slightly different output -- well if the "buggy" output survives and
does not crash that is].
(alternatively we could just prevent the overflow and still let do
`RVBlurBitmap2_float` do stuff that it really shouldnt imo, see first version of the PR)
Pull Request: https://projects.blender.org/blender/blender/pulls/111660
Previously `SEQ_modifier_list_copy` in append mode does not ensure
unique strip name, which will result in duplicated names in target
modifier list, then `strip_modifier_remove(name="something")` can remove
the wrong one later on. Now fixed using `BLI_uniquename`.
Pull Request: https://projects.blender.org/blender/blender/pulls/111602
The `lib_link` callback cannot always be fully replaced/removed, as in
some case it is also doing some validation checks, or data editing based
on the result of lib_linking internal ID pointers.
The callback has been renamed for that purpose, from `read_lib` to
`read_after_liblink`. It is now called after all ID pointers have been
fully lib-linked for the current ID, but still before the call to
`do_versions_after_linking`.
This change should not have any behavioral effect. Although in theory
the side-effect of this commit (to split lib linking itself, and the
validation/further processing code) into two completely separated steps
could have some effects, in practice none are expected, and tests did
not show any changes in behavior either..
Part of implementing #105134: Removal of readfile's lib_link & expand code.
The `expand` callback is 'trivial' to replace, since it is only iterating
over ID pointers and calling a callback.
The only change in behavior here is that some pointers that were not
processed previously will now be.
In practice this is not expected to have any real effect (usually
the IDs used by these pointers would have been expanded through other
usages anyway). But it may solve a few corner cases, undocumented issues
though.
Part of implementing #105134: Removal of readfile's lib_link & expand code.
Factor of Color>Multiply should not have an effect on the alpha channel.
Alpha values can be adjusted separately by the factor associated to blend mode.
Factors below 1.0 reducing alpha would reduce color twice, while factors
above 1.0 would be clamped to 1.0.
- Removed ops on alpha channel in multiBuf()
- Removed adjustement of ibuf-planes since alpha channel is no longer
modified
Pull Request: https://projects.blender.org/blender/blender/pulls/110984
This fixes a few related issues in VSE code:
* 'lib_link' code was doing 'read_data' tasks (like cleaning up internal
runtime data).
* Handling of `SEQ_TYPE_SOUND_HD` deprecated type of strips was
extremely confusing (versioning done partly in 'lib_link' code, partly
in some 2.50 do_version code).
* Still using deprecated `SEQ_TYPE_SOUND_HD` strip type outside of
versioning code.
* Missing proper usage of deprecated `SEQ_TYPE_SOUND_HD` type inside of
versioning code (!).
Note that the actual conversion from `SEQ_TYPE_SOUND_HD` to
`SEQ_TYPE_SOUND_RAM` is now done in the 'after setup' versioning
process, where it is somewhat safer to add IDs. This implies that
`SEQ_TYPE_SOUND_HD` must be taken into account throughout the whole
regular versioning process (before and after liblink).
Conversion logic itself has been moved to the VSE code.
Pull Request: https://projects.blender.org/blender/blender/pulls/111135
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438