From: Good Guy Date: Fri, 12 Mar 2021 23:40:29 +0000 (-0700) Subject: add in nesting/file by reference workaround X-Git-Tag: 2021-05~10 X-Git-Url: https://cinelerra-gg.org/git/?a=commitdiff_plain;h=88392a5f55bd47648523f6365115702772a7b8f9;p=goodguy%2Fcin-manual-latex.git add in nesting/file by reference workaround --- diff --git a/parts/Advanced.tex b/parts/Advanced.tex index 87eecea..0c84fd4 100644 --- a/parts/Advanced.tex +++ b/parts/Advanced.tex @@ -290,6 +290,9 @@ off even though it gives you the option to do so. These include: Instead just use the X to dismiss the warning. \end{enumerate} +Workaround cases for the alpha channel not working as intended when using an EDL inserted as a reference +is described in \ref{sub:nested_clips}. + Here is a step by step example of how you can use \textit{File by Reference}: \begin{enumerate} @@ -631,6 +634,23 @@ way they did originally with respect to the audio waveforms. This is simply a re video track which is independent from the redrawing of the audio tracks. The playback is still synchronized. \end{itemize} +Workaround cases for the alpha channel not working as intended when using an EDL inserted as a reference +or when an EDL is nested, is described here. + +\paragraph{Case 1 using the Projector on the EDL within a Master Project:} follow these next steps. +\begin{itemize} + \item Open your EDL with \textit{Open EDL} by using the middle mouse button on the Nested edit on its track. + \item In this nested EDL, insert a new Video track below the last video track. + \item Add the Alpha plugin to the new Video track for the entire length of the nested EDL. + \item Change the value of the Alpha to 0.00. + \item Close the EDL. +\end{itemize} This solves the alpha channel not working as expected and the Master Project now looks correct. + +\paragraph{Case 2 using FadeIn/Out with autos:} +In the Master Project for the Videeo track containing the nested EDL, in its Patchbay change +the \textit{Overlay Mode} from \textit{Normal} to \textit{PorterDuff->SrcOver}. + + \paragraph{Usage Examples of Nested Clips} \begin{description} diff --git a/parts/Developer.tex b/parts/Developer.tex index 5532ce8..6fc9f00 100644 --- a/parts/Developer.tex +++ b/parts/Developer.tex @@ -492,7 +492,10 @@ Now your \CGG{} obj has all of the debug stuff. Next run valgrind as root for th This runs \CGG{} under the control of valgrind, and produces a log file in /tmp which will list information about any leaks, usually clearly identifiable. Be sure to Quit out of \CGG{} normally instead of Ctrl-C or a SEGV otherwise the program does not have a chance to cleanup and there will be some false alarms. But it runs very slowly, and is basically single threaded, which means that race conditions may be impossible to catch$\dots$ like one thread deletes memory that another thread is currently using. But overall it is a big help and if you test any new features, please email the log output. A lot of effort when writing the code was put into trying to be sure that all of the object constructors have matching destructors so that the leaks can be identified. There are already several libraries that create predictable memory leaks and valgrind does a good job for most of these. -It is impossible to test everything with valgrind because some things are just too big and slow for a practical test. Occasionally you can find a leak or an illegal memory access. There are several false alarms that are difficult to avoid \textit{Conditional jump} messages, and \textit{unhandled DW\_OP\_}, but anything with the word \textit{illegal} in the message is important. Memory leaks that originate in \CGG{} are good to find and fix, but are usually not deadly. +It is impossible to test everything with valgrind because some things are just too big and slow for a practical test. Occasionally you can find a leak or an illegal memory access. There are several false alarms that are difficult to avoid \textit{Conditional jump} messages, and \textit{unhandled DW\_OP\_}, but anything with the word \textit{illegal} in the message is important. Memory leaks that originate in \CGG{} are good to find and fix, but are usually not +deadly. The listing of the memory leaks can be quite voluminous so locating the \textit{LEAK SUMMARY} section +towards the end of the report is most useful. + \section{CFLAGS has -Wall} \label{sec:cflags_has_-wall}