Cinelerra context help - a complete implementation
Hi all, This new implementation of Cinelerra context help can be requested from almost any Cinelerra window or subwindow by pointing with the mouse cursor on the GUI element of interest and pressing Alt/h. That HTML manual page will be shown via the configured web browser, which is assumed as most relevant to the GUI element being currently under the mouse pointer. For more information see issue 568 on the bugtracker: https://www.cinelerra-gg.org/bugtracker/view.php?id=568 How to install, configure and demonstrate the new functionality --------------------------------------------------------------- 1. Apply the patch (see BT568) to the CinGG source tree: https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=775&type=b... 2. After patching one new file appears: doc/ContextManual.pl. This is a perl script. It must be given exetutable permissions. 3. Build and install CinGG as usual. 4. The prerequisite for context help is CinelerraGG HTML manual. After installation of CinGG itself, place the complete unchanged directory CinelerraGG_Manual, as it was produced by latex2html from the manual package, into the 'doc' directory of the installed Cinelerra package. This will be the directory bin/doc/CinelerraGG_Manual if CinGG was built --with-single-user. The script ContextManual.pl should appear after installation also here, in bin/doc. 5. In principle, this is sufficient. Nevertheless, the bin/doc/ContextManual.pl script can be configured further. Look in the script text. You can define your preferable web browser, or redefine it to 'echo' for debug purposes. There are also some predefined HTML pages for Contents and Index, and several explicitly rewritten keyphrases. However, there can be hardly a need to redefine anything except the name of the browser executable. 6. Start Cinelerra and open a project with some assets, effects, keyframes, etc. May be, open some additional Cinelerra dialog windows, plugin settings, etc. Try to point with the mouse on different GUI elements or on empty spaces in different windows and press Alt/h. You should get different manual pages in the browser (if browser was not yet started, it should start automatically). How it works, from the user's point of view ------------------------------------------- The hotkey to request context help is Alt/h. Why? A simple 'h' does not fit: in text fields it has to input the letter 'h'. So is Shift/h: it would mean the capital letter 'H'. Ctrl/h and Ctrl/Shift/h are also not suitable: it is <Backspace>. Something like <F1> would be also not good, <Fn> are already utilized in Compositor. Unlike these all, Alt/h seems to be a good hotkey and, to the best of my knowledge, it is not assigned to anything else throughout the whole Cinelerra code. What particular help page is shown, depends on the mouse cursor location while Alt/h is pressed. Usually, when the mouse is located in some window or dialog, the help page related to the functionality of this window or dialog is shown. In this case the mouse can point either on some widget, or on an empty area in the window. In Cinelerra GUI there are several rich loaded windows, Timeline and Compositor for example. In such a case different help pages can be requested depending on the particular GUI element under the mouse. For example, pressing Alt/h while pointing on the Autos curve in a track would show help on automation keyframes, pointing on the Overlay mode button in the patchbay would show help on overlays, pointing on the camera control in Compositor would show help on camera and projector. If no context dependent help page is found, the manual page of Contents itself is shown. Most probably it means, that either the meaning of this window is obvious (so is the 'Tip of the day' window, for example), or it is not (yet) documented. Requesting context help for plugins ----------------------------------- There are following possibilities to request help page for the particular plugin of interest. 1) Pressing Alt/h with mouse in the dialog window of plugin settings 2) Pressing Alt/h while pointing with the mouse on the plugin bar in a track (or transition bar, or transition icon) 3) Pressing Alt/h while pointing on the plugin name (icon) in the Resources window. If plugin tooltips are on, help for the highlighted (plugin under mouse) is shown. If plugin tooltips are off, help for the selected plugin is shown (it is made so, because in the latter case it would be difficult to figure out, without a visual feedback, which particular item is currently under mouse). 4) Pressing Alt/h while pointing on the plugin name in the Attach Effect dialog Requesting context help on Contour Shuttle ------------------------------------------ Contour Shuttle has no Alt/h, yeh. Nevertheless, its help page can be requested by simultaneous pressing both Alt keys (left and right) on the keyboard followed by pressing any button on the Contour Shuttle. Here, pressing both Alt keys is necessary due to the way of X11 to track the status of modifiers. To cancel this mode, press any single modifier key (Alt, Ctrl or Shift) once. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
Fantastic !! Easy to check this out on newer distros with AppImage (so all you have to do is a download, chmod +x, and run). There is an AppImage for users to test for newer distros (I will create one for older distros tomorrow after I fix my mistake first). It is at: https://cinelerra-gg.org/download/images/cin_for_newer_distros.AppImage It is great fun to test -- please report if you find any problems as I have found none so far. On Fri, May 7, 2021 at 9:34 AM Georgy Salnikov via Cin < [email protected]> wrote:
Hi all,
This new implementation of Cinelerra context help can be requested from almost any Cinelerra window or subwindow by pointing with the mouse cursor on the GUI element of interest and pressing Alt/h. That HTML manual page will be shown via the configured web browser, which is assumed as most relevant to the GUI element being currently under the mouse pointer. For more information see issue 568 on the bugtracker: https://www.cinelerra-gg.org/bugtracker/view.php?id=568
How to install, configure and demonstrate the new functionality ---------------------------------------------------------------
1. Apply the patch (see BT568) to the CinGG source tree:
https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=775&type=b...
2. After patching one new file appears: doc/ContextManual.pl. This is a perl script. It must be given exetutable permissions.
3. Build and install CinGG as usual.
4. The prerequisite for context help is CinelerraGG HTML manual. After installation of CinGG itself, place the complete unchanged directory CinelerraGG_Manual, as it was produced by latex2html from the manual package, into the 'doc' directory of the installed Cinelerra package. This will be the directory bin/doc/CinelerraGG_Manual if CinGG was built --with-single-user. The script ContextManual.pl should appear after installation also here, in bin/doc.
5. In principle, this is sufficient. Nevertheless, the bin/doc/ContextManual.pl script can be configured further. Look in the script text. You can define your preferable web browser, or redefine it to 'echo' for debug purposes. There are also some predefined HTML pages for Contents and Index, and several explicitly rewritten keyphrases. However, there can be hardly a need to redefine anything except the name of the browser executable.
6. Start Cinelerra and open a project with some assets, effects, keyframes, etc. May be, open some additional Cinelerra dialog windows, plugin settings, etc. Try to point with the mouse on different GUI elements or on empty spaces in different windows and press Alt/h. You should get different manual pages in the browser (if browser was not yet started, it should start automatically).
How it works, from the user's point of view -------------------------------------------
The hotkey to request context help is Alt/h. Why? A simple 'h' does not fit: in text fields it has to input the letter 'h'. So is Shift/h: it would mean the capital letter 'H'. Ctrl/h and Ctrl/Shift/h are also not suitable: it is <Backspace>. Something like <F1> would be also not good, <Fn> are already utilized in Compositor. Unlike these all, Alt/h seems to be a good hotkey and, to the best of my knowledge, it is not assigned to anything else throughout the whole Cinelerra code.
What particular help page is shown, depends on the mouse cursor location while Alt/h is pressed. Usually, when the mouse is located in some window or dialog, the help page related to the functionality of this window or dialog is shown. In this case the mouse can point either on some widget, or on an empty area in the window.
In Cinelerra GUI there are several rich loaded windows, Timeline and Compositor for example. In such a case different help pages can be requested depending on the particular GUI element under the mouse. For example, pressing Alt/h while pointing on the Autos curve in a track would show help on automation keyframes, pointing on the Overlay mode button in the patchbay would show help on overlays, pointing on the camera control in Compositor would show help on camera and projector.
If no context dependent help page is found, the manual page of Contents itself is shown. Most probably it means, that either the meaning of this window is obvious (so is the 'Tip of the day' window, for example), or it is not (yet) documented.
Requesting context help for plugins -----------------------------------
There are following possibilities to request help page for the particular plugin of interest.
1) Pressing Alt/h with mouse in the dialog window of plugin settings
2) Pressing Alt/h while pointing with the mouse on the plugin bar in a track (or transition bar, or transition icon)
3) Pressing Alt/h while pointing on the plugin name (icon) in the Resources window. If plugin tooltips are on, help for the highlighted (plugin under mouse) is shown. If plugin tooltips are off, help for the selected plugin is shown (it is made so, because in the latter case it would be difficult to figure out, without a visual feedback, which particular item is currently under mouse).
4) Pressing Alt/h while pointing on the plugin name in the Attach Effect dialog
Requesting context help on Contour Shuttle ------------------------------------------
Contour Shuttle has no Alt/h, yeh. Nevertheless, its help page can be requested by simultaneous pressing both Alt keys (left and right) on the keyboard followed by pressing any button on the Contour Shuttle. Here, pressing both Alt keys is necessary due to the way of X11 to track the status of modifiers. To cancel this mode, press any single modifier key (Alt, Ctrl or Shift) once.
_______________________________________________________________________________
Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected]
_______________________________________________________________________________
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I will waiting an AppImage for older distros to test it. I think it is very good, reading it in MantisBT: Georgy (sge) has documented both for user and developer very well. So I can try to learn. Thanks Georgy! Il 08/05/2021 04:18, Phyllis Smith via Cin ha scritto:
Fantastic !! Easy to check this out on newer distros with AppImage (so all you have to do is a download, chmod +x, and run).
There is an AppImage for users to test for newer distros (I will create one for older distros tomorrow after I fix my mistake first). It is at: https://cinelerra-gg.org/download/images/cin_for_newer_distros.AppImage
It is great fun to test -- please report if you find any problems as I have found none so far.
There is an AppImage for users to test for older distros now. It is at: https://cinelerra-gg.org/download/images/cin_for_older_distros.AppImage It works on older and will also work on newer distros, if you have multiple computers/partitions at different levels. On Sun, May 9, 2021 at 1:22 AM Igor BEGHETTO via Cin < [email protected]> wrote:
I will waiting an AppImage for older distros to test it. I think it is very good, reading it in MantisBT: Georgy (sge) has documented both for user and developer very well. So I can try to learn. Thanks Georgy!
Il 08/05/2021 04:18, Phyllis Smith via Cin ha scritto:
Fantastic !! Easy to check this out on newer distros with AppImage (so all you have to do is a download, chmod +x, and run).
There is an AppImage for users to test for newer distros (I will create one for older distros tomorrow after I fix my mistake first). It is at: https://cinelerra-gg.org/download/images/cin_for_newer_distros.AppImage
It is great fun to test -- please report if you find any problems as I have found none so far.
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Phyllis you are great. Thank you so much for the AppImage! On UbuntuStudio 16.04 LTS it works very fine. And, thanks Georgy, you did an amazing work! Il 09/05/2021 17:23, Phyllis Smith via Cin ha scritto:
There is an AppImage for users to test for older distros now. It is at:
https://cinelerra-gg.org/download/images/cin_for_older_distros.AppImage
It works on older and will also work on newer distros, if you have multiple computers/partitions at different levels.
To put Context Help on the manual, I thought I would put it at the beginning of chapter 18. I used sge's exact words with some cut-outs and minor edits since they are clear and precise. Do you think it's okay or is it better to do further editing? PS: I have changed the position of "CD Ripper", thank you.
On Mon, 10 May 2021, Andrea paz via Cin wrote:
To put Context Help on the manual, I thought I would put it at the beginning of chapter 18. I used sge's exact words with some cut-outs and minor edits since they are clear and precise. Do you think it's okay or is it better to do further editing?
To put the complete Context Help description in some single place in the manual is good, thank you Andrea. But there is additional consideration. It is well known: true users hate reading manuals. Most likely, such a user will never reach chapter 18 but will accidentally find out about existence of Alt/h from some forum around. I'd suggest, additionally, to mention Context Help somewhere near to the manual's beginning, and in some particularly relevant places (for unambiguity I give the corresponding HTML page names): 1) Einther in Chapters_Overview.html, or in CINELERRA_GG_Overview.html - some short sentence like: "Furthemore, CGG provides the Context Help facility. A relevant section of CGG manual can be quickly recalled in a web browser window by pointing with mouse on the GUI item of interest and pressing the hotkey Alt/h, see Chapter 18 for more info". 2) Perhaps in View_Listen.html (or in some other subsection of CINELERRA_GG_Quick_Start_Gu.html) - something like: "If you need more detailed information on a button or other particular GUI element than is contained in tooltips, press Alt/h hotkey and you get the HTML page in web browser with the documentation of the element being currently under mouse". 3) In How_see_short_Description_P.html - about the 4 possibilities of getting documentation on a plugin in the form of Context Help. 4) In Shuttle_key_default_arrange.html - "This page can be quickly requested from CGG by pressing both Alt keys (left and right) on keyboard followed by pressing any button on the Shuttle". 5) Perhaps some tip(s) about Context Help could be added to the list for the 'Tip of the day' window. 6) Some phrase about Context Help facility might be added to the list of documentation sources on the web page https://www.cinelerra-gg.org/downloads/#documentation Another addition for the Context Help documentation, for completeness, I have added as note to BT568 in reply to user fary54: how to configure some selected browsers to get Context Help pages displayed in same browser tab rather than in new tabs for each new Alt/h request, I cite this: 1) Use another browser which has such a mode configurable (example for Seamonkey): export CIN_BROWSER=seamonkey cin In seamonkey browser go to Edit -> Preferences... -> Browser -> Link Behavior -> Links from other applications Set the option "Open links passed from other applications in:" to the value "The current tab/window" And you get it! 2) Hack a default browser if you know how to hack it (example for Firefox): Start Firefox and open the pseudo-URL: about:config There comes a warning like "I'll be careful, I promise!", acknowledge it. Then comes a very long list with lots of undecipherable variable names. Scroll it down and find variable with the name "browser.link.open_newwindow.override.external". By default it has value: -1, which means: use value of the more general variable "browser.link.open_newwindow". Place mouse cursor over "browser.link.open_newwindow.override.external", press right button and select from the popup menu "Modify". The value becomes editable. Set it to 1, and you get new links from external apps opened in same tab. If you set the variable "browser.link.open_newwindow" instead, you get this behavior not only for external, but also for all links which otherwise would be opened in new tabs or new windows. The possible values of both variables are: 1: open in the current window and tab 2: open in the new window 3 (default): open in the new tab, current window _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
Great addition to Cinelerra but two problems... On my keyboard, the two Alt keys are separated from each other by 6.5" (16.5 cm). It is almost impossible for me to reach both keys at the same time with the fingers of one hand (so that the second hand can operate a shuttle button) The process works sometimes and sometimes not. Pierre Le 21-05-10 à 12 h 43, Georgy Salnikov via Cin a écrit :
4) In Shuttle_key_default_arrange.html - "This page can be quickly requested from CGG by pressing both Alt keys (left and right) on keyboard followed by pressing any button on the Shuttle".
Pierre, I was wondering about this and plan on testing the Shuttle later today to check this out. ...Phyllis On Mon, May 10, 2021 at 12:24 PM Pierre autourduglobe via Cin < [email protected]> wrote:
Great addition to Cinelerra but two problems...
On my keyboard, the two Alt keys are separated from each other by 6.5" (16.5 cm). It is almost impossible for me to reach both keys at the same time with the fingers of one hand (so that the second hand can operate a shuttle button)
The process works sometimes and sometimes not.
Pierre
Le 21-05-10 à 12 h 43, Georgy Salnikov via Cin a écrit :
4) In Shuttle_key_default_arrange.html - "This page can be quickly requested from CGG by pressing both Alt keys (left and right) on keyboard followed by pressing any button on the Shuttle". -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Error... The two Alt keys are separated from each other by 8.5" (21.5 cm)... Pierre Le 21-05-10 à 14 h 35, Phyllis Smith a écrit :
Pierre, I was wondering about this and plan on testing the Shuttle later today to check this out. ...Phyllis
On Mon, May 10, 2021 at 12:24 PM Pierre autourduglobe via Cin <[email protected] <mailto:[email protected]>> wrote:
Great addition to Cinelerra but two problems...
On my keyboard, the two Alt keys are separated from each other by 6.5" (16.5 cm). It is almost impossible for me to reach both keys at the same time with the fingers of one hand (so that the second hand can operate a shuttle button)
The process works sometimes and sometimes not.
Pierre
Le 21-05-10 à 12 h 43, Georgy Salnikov via Cin a écrit : > 4) In Shuttle_key_default_arrange.html - "This page can be quickly requested > from CGG by pressing both Alt keys (left and right) on keyboard followed by > pressing any button on the Shuttle". -- Cin mailing list [email protected] <mailto:[email protected]> https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Mon, 10 May 2021, Pierre autourduglobe via Cin wrote:
On my keyboard, the two Alt keys are separated from each other by 6.5" (16.5 cm). It is almost impossible for me to reach both keys at the same time with the fingers of one hand (so that the second hand can operate a shuttle button)
Pierre, try the following for the shuttle help. 1. Press both Alt keys together with two hands. 2. Release Alt keys. 3. And now press a button on the shuttle, it should remember Alt status. Another method. 1. Press left Alt, then press left Ctrl. Both keys have to remain pressed, but Alt must be pressed first. 2. Now press shuttle button. These tricks work due to the art X11 tracks status of the modifier keys. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
With the checkin to GIT of Georgy's fix in Bug Tracker #608, both of the problems reported by Pierre below are now no longer problems and will be in the updated AppImage release on March 31 !! Great addition to Cinelerra but two problems...
On my keyboard, the two Alt keys are separated from each other by 6.5" (16.5 cm). It is almost impossible for me to reach both keys at the same time with the fingers of one hand (so that the second hand can operate a shuttle button)
Now you only have to press the one Alt key simultaneously with the Shuttle button. (The 6.5" was really 8.5" so even worse).
The process works sometimes and sometimes not.
Now it should work all of the time as explained in the BT.
Pierre
Le 21-05-10 à 12 h 43, Georgy Salnikov via Cin a écrit :
4) In Shuttle_key_default_arrange.html - "This page can be quickly requested from CGG by pressing both Alt keys (left and right) on keyboard followed by pressing any button on the Shuttle". -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Yes you are right Phyllis about the 8.5"; I had measured wrong. To be able to press the two Alt keys with one hand, I would have had to grow my finger nails very long like the old wise men in the kung fu movies... Pierre Le 22-03-23 à 15 h 10, Phyllis Smith a écrit :
With the checkin to GIT of Georgy's fix in Bug Tracker #608, both of the problems reported by Pierre below are now no longer problems and will be in the updated AppImage release on March 31 !!
Great addition to Cinelerra but two problems...
On my keyboard, the two Alt keys are separated from each other by 6.5" (16.5 cm). It is almost impossible for me to reach both keys at the same time with the fingers of one hand (so that the second hand can operate a shuttle button)
Now you only have to press the one Alt key simultaneously with the Shuttle button. (The 6.5" was really 8.5" so even worse).
The process works sometimes and sometimes not.
Now it should work all of the time as explained in the BT.
Pierre
Le 21-05-10 à 12 h 43, Georgy Salnikov via Cin a écrit : > 4) In Shuttle_key_default_arrange.html - "This page can be quickly requested > from CGG by pressing both Alt keys (left and right) on keyboard followed by > pressing any button on the Shuttle". -- Cin mailing list [email protected] <mailto:[email protected]> https://lists.cinelerra-gg.org/mailman/listinfo/cin
Eh Pierre, do you have such a large keyboard? On two of them here the distance is 13 / 14 cm, and I can easily press them with thumb and pinky at the same time. Even pointing finger and pinky go fine, and I do not have large hands. MatN On Wed, 23 Mar 2022 19:39:22 -0400 Pierre autourduglobe via Cin <[email protected]> wrote:
Yes you are right Phyllis about the 8.5"; I had measured wrong. To be able to press the two Alt keys with one hand, I would have had to grow my finger nails very long like the old wise men in the kung fu movies...
Pierre
Le 22-03-23 à 15 h 10, Phyllis Smith a écrit :
With the checkin to GIT of Georgy's fix in Bug Tracker #608, both of the problems reported by Pierre below are now no longer problems and will be in the updated AppImage release on March 31 !!
Great addition to Cinelerra but two problems...
On my keyboard, the two Alt keys are separated from each other by 6.5" (16.5 cm). It is almost impossible for me to reach both keys at the same time with the fingers of one hand (so that the second hand can operate a shuttle button)
Now you only have to press the one Alt key simultaneously with the Shuttle button. (The 6.5" was really 8.5" so even worse).
The process works sometimes and sometimes not.
Now it should work all of the time as explained in the BT.
Pierre
Le 21-05-10 à 12 h 43, Georgy Salnikov via Cin a écrit : > 4) In Shuttle_key_default_arrange.html - "This page can be quickly requested > from CGG by pressing both Alt keys (left and right) on > keyboard followed by > pressing any button on the Shuttle". -- Cin mailing list [email protected] <mailto:[email protected]> https://lists.cinelerra-gg.org/mailman/listinfo/cin
Yes, I use an old "Macally ikey" keyboard (like the one on this picture https://u.pcloud.link/publink/show?code=XZfGU0VZ01uHSol5gSyVyuiqY84SiuREQry0). It is very old... But its keys are particularly pleasant and resistant to use. The center of the two Alt keys are in fact separated by precisely 21.3 cm. Pierre Le 22-03-24 à 01 h 48, [email protected] a écrit :
Eh Pierre,
do you have such a large keyboard? On two of them here the distance is 13 / 14 cm, and I can easily press them with thumb and pinky at the same time. Even pointing finger and pinky go fine, and I do not have large hands.
MatN
On Wed, 23 Mar 2022 19:39:22 -0400 Pierre autourduglobe via Cin <[email protected]> wrote:
Yes you are right Phyllis about the 8.5"; I had measured wrong. To be able to press the two Alt keys with one hand, I would have had to grow my finger nails very long like the old wise men in the kung fu movies...
Pierre
Le 22-03-23 à 15 h 10, Phyllis Smith a écrit :
With the checkin to GIT of Georgy's fix in Bug Tracker #608, both of the problems reported by Pierre below are now no longer problems and will be in the updated AppImage release on March 31 !!
Great addition to Cinelerra but two problems...
On my keyboard, the two Alt keys are separated from each other by 6.5" (16.5 cm). It is almost impossible for me to reach both keys at the same time with the fingers of one hand (so that the second hand can operate a shuttle button)
Now you only have to press the one Alt key simultaneously with the Shuttle button. (The 6.5" was really 8.5" so even worse).
The process works sometimes and sometimes not.
Now it should work all of the time as explained in the BT.
Pierre
Le 21-05-10 à 12 h 43, Georgy Salnikov via Cin a écrit : > 4) In Shuttle_key_default_arrange.html - "This page can be quickly requested > from CGG by pressing both Alt keys (left and right) on > keyboard followed by > pressing any button on the Shuttle". -- Cin mailing list [email protected] <mailto:[email protected]> https://lists.cinelerra-gg.org/mailman/listinfo/cin
All,
It is well known: true users hate reading manuals. Most likely, such a user will never reach chapter 18 but will accidentally find out about existence of Alt/h from some forum around.
Does anyone have any objections to my changing the default Status Bar
message in the lower right corner of the main program window from saying "Welcome to Cinelerra." to "Alt/h for Help on Mouse item." Welcome to Cinelerra conveys zero information and has only been more or less a placeholder for when there are no warning or other informative messages. And, yes, the Alt/h Help message will get written over, but at least it will most likely be seen once. Or is there better wording that is not too long?
On Tuesday, May 11, 2021, Phyllis Smith via Cin <[email protected]> wrote:
All,
It is well known: true users hate reading manuals. Most likely, such a user will never reach chapter 18 but will accidentally find out about existence of Alt/h from some forum around.
Does anyone have any objections to my changing the default Status Bar
message in the lower right corner of the main program window from saying "Welcome to Cinelerra." to "Alt/h for Help on Mouse item."
I was thinking about 'welcome to cinGG - use alt+h for context help' but this might not fit into default window on smallish screens....
Welcome to Cinelerra conveys zero information and has only been more or less a placeholder for when there are no warning or other informative messages. And, yes, the Alt/h Help message will get written over, but at least it will most likely be seen once. Or is there better wording that is not too long?
IMHO I think that the right place for "Alt+h" could be the "Tip of the day" window. There, there is more room to write how it works. If possible, the first time Cinelerra-GG is run the "Tip of the day" window should show the "Alt+h" for help. So, the new User can see it and remember (I hope) if She/He needs it. IgorBeg
Does anyone have any objections to my changing the default Status Bar message in the lower right corner of the main program window from saying "Welcome to Cinelerra." to "Alt/h for Help on Mouse item." Welcome to Cinelerra conveys zero information and has only been more or less a placeholder for when there are no warning or other informative messages. And, yes, the Alt/h Help message will get written over, but at least it will most likely be seen once. Or is there better wording that is not too long
Andrea, Igor, Both of your ideas are good. I will see what fits. On Tue, May 11, 2021 at 2:55 AM Igor BEGHETTO via Cin < [email protected]> wrote:
IMHO I think that the right place for "Alt+h" could be the "Tip of the day" window. There, there is more room to write how it works. If possible, the first time Cinelerra-GG is run the "Tip of the day" window should show the "Alt+h" for help. So, the new User can see it and remember (I hope) if She/He needs it.
IgorBeg
Does anyone have any objections to my changing the default Status Bar message in the lower right corner of the main program window from saying "Welcome to Cinelerra." to "Alt/h for Help on Mouse item." Welcome to Cinelerra conveys zero information and has only been more or less a placeholder for when there are no warning or other informative messages. And, yes, the Alt/h Help message will get written over, but at least it will most likely be seen once. Or is there better wording that is not too long -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
(About Context Help once program started.) OK, see attached. Used Andrea's wording suggestion on the Status Bar and put it in the color Green. It can be easily switched back to white, but I think Green shows up a lot better. Check the Tip of the Day wording and make a suggestion if you thinks it needs changing. IMHO I think that the right place for "Alt+h" could be the "Tip of the
day" window. There, there is more room to write how it works. If possible, the first time Cinelerra-GG is run the "Tip of the day" window should show the "Alt+h" for help. So, the new User can see it and remember (I hope) if She/He needs it.
In "Tip of the Day" 4 lines of text are too much, I think. It is better only 2 lines. Less is More for and User. My english is not good but I would write something as ********************************************* Move the mouse's pointer on a item and press ALT+h shortcut to open the Context HELP in your default browser. *************************************************** So an User read quickly and eventually try. Is the green text "Welcome to CinGG - Use ALT+h for Context HELP." only for that theme or for all themes? Note that I have written the words ALT and HELP in capital letters because they immediately catch the eye. Thanks! IgorBeg Il 11/05/2021 21:29, Phyllis Smith via Cin ha scritto:
(About Context Help once program started.) OK, see attached. Used Andrea's wording suggestion on the Status Bar and put it in the color Green. It can be easily switched back to white, but I think Green shows up a lot better. Check the Tip of the Day wording and make a suggestion if you thinks it needs changing.
Igor, you are right. I have shortened the message.
In "Tip of the Day" 4 lines of text are too much, I think. It is better only 2 lines. Less is More for and User. My english is not good but I would write something as ********************************************* Move the mouse's pointer on a item and press ALT+h shortcut to open the Context HELP in your default browser. *************************************************** So an User read quickly and eventually try. Is the green text "Welcome to CinGG - Use ALT+h for Context HELP." only for that theme or for all themes? Note that I have written the words ALT and HELP in capital letters because they immediately catch the eye.
Again, you are right. It would be green for all themes and did not always show well. I went back to the way it was because that makes it white or some themes and black for other light colored themes. Also, capitalized ALT and HELP.
Updated the Manual in GIT to include Georgy's documentation. Andrea did the formatting and if he gets time to check the formatting of the small parts that I added, that would be appreciated as he is a lot better at that and making it consistent. --------------------------------------------------------- Split the main Context Help section that Andrea formatted into 2 parts -- the user part is in the Trouble.tex file and the programmer portion is in the Developer.tex file.
1) Einther in Chapters_Overview.html, or in CINELERRA_GG_Overview.html - some short sentence like: "Furthemore, CGG provides the Context Help facility. A relevant section of CGG manual can be quickly recalled in a web browser window by pointing with mouse on the GUI item of interest and pressing the hotkey Alt/h, see Chapter 18 for more info".
Some wording like this was put in 2 places in the Introduction.tex file - closer to the beginning in case users don't read very far and under the short description of Chapter 18. Also added as a "Standard Feature" in Introduction.tex. BUT, is it really "standard"? or should it be "Innovative New Feature"? *Do other NLE's * *have easily available Help from the program? * I have never looked at any others.
2) Perhaps in View_Listen.html (or in some other subsection of CINELERRA_GG_Quick_Start_Gu.html) - something like: "If you need more detailed information on a button or other particular GUI element than is contained in tooltips, press Alt/h hotkey and you get the HTML page in web browser with the documentation of the element being currently under mouse".
Similar wording put in 2 places in the Quickstart.tex file.
3) In How_see_short_Description_P.html - about the 4 possibilities of getting documentation on a plugin in the form of Context Help.
Added to the Plugins.tex file.
4) In Shuttle_key_default_arrange.html - "This page can be quickly requested from CGG by pressing both Alt keys (left and right) on keyboard followed by pressing any button on the Shuttle".
Added to the Editing.tex file.
5) Perhaps some tip(s) about Context Help could be added to the list for the 'Tip of the day' window.
This was checked into the source code GIT yesterday. BUT the tips are 'rolling' so it will only show up the first time and then again when it wraps around. The user can always use the arrow keys to see a previous tip though.
6) Some phrase about Context Help facility might be added to the list of documentation sources on the web page https://www.cinelerra-gg.org/downloads/#documentation
I have not done this yet because I am not sure where I want it to go and I fumble a lot when using WordPress.
Another addition for the Context Help documentation, for completeness, I have added as note to BT568 in reply to user fary54: how to configure some selected browsers to get Context Help pages displayed in same browser tab rather than in new tabs for each new Alt/h request, I cite this:
This is in Trouble.tex (basically as cited). Other additions: ----------------------- 1) in the Shortcuts.tex file I mentioned the "hotkey Alt/h" in the verbage because in reality it is a shortcut to get to the manual page. 2) in Developer.tex file, I added "what about localization", "why using local html files, and small details about "Context_Help.pl". I plan to proofread again tomorrow what I checked in because I kept making editing mistakes in vi. ...Phyllis
On Sunday, May 16, 2021, Phyllis Smith via Cin <[email protected]> wrote:
Updated the Manual in GIT to include Georgy's documentation. Andrea did the formatting and if he gets time to check the formatting of the small parts that I added, that would be appreciated as he is a lot better at that and making it consistent. --------------------------------------------------------- Split the main Context Help section that Andrea formatted into 2 parts -- the user part is in the Trouble.tex file and the programmer portion is in the Developer.tex file.
1) Einther in Chapters_Overview.html, or in CINELERRA_GG_Overview.html - some short sentence like: "Furthemore, CGG provides the Context Help facility. A relevant section of CGG manual can be quickly recalled in a web browser window by pointing with mouse on the GUI item of interest and pressing the hotkey Alt/h, see Chapter 18 for more info".
Some wording like this was put in 2 places in the Introduction.tex file - closer to the beginning in case users don't read very far and under the short description of Chapter 18.
Also added as a "Standard Feature" in Introduction.tex. BUT, is it really "standard"? or should it be "Innovative New Feature"? *Do other NLE's * *have easily available Help from the program? * I have never looked at any others.
i think it was innovative in early 1990s) at least in many qt3/kde3 programs it was possible to click on small '?' labeled button at window titlebar and move cursor over element in GUI and get some kind of 'help in the bubble'. and of course there was help-AS-HTML in GIMP, but my latest selfmade builds doesn't show it, sadly.. (i probably need to learn where to put those help files there for offline/internetless views)
2) Perhaps in View_Listen.html (or in some other subsection of CINELERRA_GG_Quick_Start_Gu.html) - something like: "If you need more detailed information on a button or other particular GUI element than is contained in tooltips, press Alt/h hotkey and you get the HTML page in web browser with the documentation of the element being currently under mouse".
Similar wording put in 2 places in the Quickstart.tex file.
3) In How_see_short_Description_P.html - about the 4 possibilities of getting documentation on a plugin in the form of Context Help.
Added to the Plugins.tex file.
4) In Shuttle_key_default_arrange.html - "This page can be quickly requested from CGG by pressing both Alt keys (left and right) on keyboard followed by pressing any button on the Shuttle".
Added to the Editing.tex file.
5) Perhaps some tip(s) about Context Help could be added to the list for the 'Tip of the day' window.
This was checked into the source code GIT yesterday. BUT the tips are 'rolling' so it will only show up the first time and then again when it wraps around. The user can always use the arrow keys to see a previous tip though.
6) Some phrase about Context Help facility might be added to the list of documentation sources on the web page https://www.cinelerra-gg.org/downloads/#documentation
I have not done this yet because I am not sure where I want it to go and I fumble a lot when using WordPress.
Another addition for the Context Help documentation, for completeness, I have added as note to BT568 in reply to user fary54: how to configure some selected browsers to get Context Help pages displayed in same browser tab rather than in new tabs for each new Alt/h request, I cite this:
This is in Trouble.tex (basically as cited).
Other additions: ----------------------- 1) in the Shortcuts.tex file I mentioned the "hotkey Alt/h" in the verbage because in reality it is a shortcut to get to the manual page. 2) in Developer.tex file, I added "what about localization", "why using local html files, and small details about "Context_Help.pl".
I plan to proofread again tomorrow what I checked in because I kept making editing mistakes in vi. ...Phyllis
hehe... i think you can use EDITOR enviroment variable for controlling what kind of editor git use for commit message editing (found this out because here vi was not installed) in my case: export [skip a lot] declare -x EDITOR="mcedit" [skip more] Thanks a megaton for this work on documentation!
Great work! Only idea is to give more visibility to the context help in the introduction, moving it to the front page and putting it as a prominent note. See if you like it, it's not a important proposal.
Playing around with high fps rendering, I got crashes. I don't know if I am doing this right, but CinGG should not crash. Can anyone reproduce this? I do not want to make a BT entry if it is something local. Details: Machine: CPU AMD 2400G, 32 M ram, SSD storage. Linux Mint XFCE 20.1, kernel 5.4.0-77 . CinGG build: from git 20210623 UTC 1830 or so. Build went OK. Used the executable from the bin directory, not the AppImage. Format settings: 1920x1080 p120 RGBA, 1 video, 2 audio channels. Imported 1920x1080p50 yuv420 mp4 video. Rendering (H.264 vaapi) creates a 120 fps file, which plays fine quickly tested, but CinGG crashes at the end. I tried without and with the ffmpeg "interpolate video" filter, both crash, but with interpolate filter file is 3 times bigger (and the picture has problems, but that is another issue). Sizes: original 50 fps: 313 MB, 120 fps without filter 1.1G, 120 fps with filter 3.8 G. Lots of MotionHVScan error while rendering. MotionHVScan::pixel_search 535 range fail range1=0.140625 ** segv at 0x7ffaa64cf032 in pid 8691, tid 10535 MotionHVScan::pixel_search 535 range fail range1=0.136719 MotionHVScan::pixel_search 535 range fail range1=0.343750 MotionHVScan::pixel_search 535 range fail range1=0.152344 MotionHVScan::pixel_search 535 range fail range1=0.136719 MotionHVScan::pixel_search 535 range fail range1=0.578125 MotionHVScan::pixel_search 535 range fail range1=0.292969 MotionHVScan::pixel_search 535 range fail range1=0.191406 MotionHVScan::pixel_search 535 range fail range1=0.132813 writing debug data to /tmp/cinelerra_8691.dmp MotionHVScan::pixel_search 535 range fail range1=0.148438 MotionHVScan::pixel_search 535 range fail range1=0.390625 MotionHVScan::pixel_search 535 range fail range1=0.425781 Segmentation fault (core dumped) MatN
On Saturday, June 26, 2021, mnieuw--- via Cin <[email protected]> wrote:
Playing around with high fps rendering, I got crashes. I don't know if I am doing this right, but CinGG should not crash. Can anyone reproduce this? I do not want to make a BT entry if it is something local.
I think you still better to add BT entry...
Details:
Machine: CPU AMD 2400G, 32 M ram, SSD storage. Linux Mint XFCE 20.1, kernel 5.4.0-77 .
CinGG build: from git 20210623 UTC 1830 or so. Build went OK. Used the executable from the bin directory, not the AppImage.
Format settings: 1920x1080 p120 RGBA, 1 video, 2 audio channels. Imported 1920x1080p50 yuv420 mp4 video. Rendering (H.264 vaapi) creates a 120 fps file, which plays fine quickly tested, but CinGG crashes at the end.
I tried without and with the ffmpeg "interpolate video" filter, both crash, but with interpolate filter file is 3 times bigger (and the picture has problems, but that is another issue). Sizes: original 50 fps: 313 MB, 120 fps without filter 1.1G, 120 fps with filter 3.8 G.
Lots of MotionHVScan error while rendering.
MotionHVScan::pixel_search 535 range fail range1=0.140625 ** segv at 0x7ffaa64cf032 in pid 8691, tid 10535 MotionHVScan::pixel_search 535 range fail range1=0.136719 MotionHVScan::pixel_search 535 range fail range1=0.343750 MotionHVScan::pixel_search 535 range fail range1=0.152344 MotionHVScan::pixel_search 535 range fail range1=0.136719 MotionHVScan::pixel_search 535 range fail range1=0.578125 MotionHVScan::pixel_search 535 range fail range1=0.292969 MotionHVScan::pixel_search 535 range fail range1=0.191406 MotionHVScan::pixel_search 535 range fail range1=0.132813 writing debug data to /tmp/cinelerra_8691.dmp MotionHVScan::pixel_search 535 range fail range1=0.148438 MotionHVScan::pixel_search 535 range fail range1=0.390625 MotionHVScan::pixel_search 535 range fail range1=0.425781 Segmentation fault (core dumped)
those apparently come from plugins/motion-hv or plugins/motion2point... can you try without those?
MatN -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
MatN, Trying this now too -- first without the plugins added, but it renders so slow. On Sat, Jun 26, 2021 at 2:32 PM mnieuw--- via Cin < [email protected]> wrote:
Playing around with high fps rendering, I got crashes. I don't know if I am doing this right, but CinGG should not crash. Can anyone reproduce this? I do not want to make a BT entry if it is something local. Details:
Machine: CPU AMD 2400G, 32 M ram, SSD storage. Linux Mint XFCE 20.1, kernel 5.4.0-77 .
CinGG build: from git 20210623 UTC 1830 or so. Build went OK. Used the executable from the bin directory, not the AppImage.
Format settings: 1920x1080 p120 RGBA, 1 video, 2 audio channels. Imported 1920x1080p50 yuv420 mp4 video. Rendering (H.264 vaapi) creates a 120 fps file, which plays fine quickly tested, but CinGG crashes at the end.
I tried without and with the ffmpeg "interpolate video" filter, both crash, but with interpolate filter file is 3 times bigger (and the picture has problems, but that is another issue). Sizes: original 50 fps: 313 MB, 120 fps without filter 1.1G, 120 fps with filter 3.8 G.
Lots of MotionHVScan error while rendering.
MotionHVScan::pixel_search 535 range fail range1=0.140625 ** segv at 0x7ffaa64cf032 in pid 8691, tid 10535 MotionHVScan::pixel_search 535 range fail range1=0.136719 MotionHVScan::pixel_search 535 range fail range1=0.343750 MotionHVScan::pixel_search 535 range fail range1=0.152344 MotionHVScan::pixel_search 535 range fail range1=0.136719 MotionHVScan::pixel_search 535 range fail range1=0.578125 MotionHVScan::pixel_search 535 range fail range1=0.292969 MotionHVScan::pixel_search 535 range fail range1=0.191406 MotionHVScan::pixel_search 535 range fail range1=0.132813 writing debug data to /tmp/cinelerra_8691.dmp MotionHVScan::pixel_search 535 range fail range1=0.148438 MotionHVScan::pixel_search 535 range fail range1=0.390625 MotionHVScan::pixel_search 535 range fail range1=0.425781 Segmentation fault (core dumped)
MatN -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Well, it's good I did not make BT entry out of it. The error message MotionHVScan only appears in the motion2 plugin. I did three different renders to mp4. a) motion2 removed, H.264 vaapi: rendered 32174 frames in 1604.302 secs, 20.055 fps, file size 1.1 GB. b) motion2 removed, H.264: rendered 32174 frames in 1902.344 secs, 16.913 fps, file size .39 GB ! c) motion2 restored. Time slow because machine went in standby, file size .39 GB. All three played fine. In all cases, I used a fresh start of CinGG from the bin directory, no effects in action anywhere. I could not understand yesterday why MotionHVScan would have anything to do with duplicating frames, but it doesn't apparently. I don't know what went wrong yesterday but it must have been something local. No updates were done to the machine. Now the files all play fine, and VLC says there are 120 fps, but are they really? I don't have a high-fps monitor (it is running at 60 Hz). I should expect that a movie at 120 fps when played at 60 Hz runs at half the speed, or maybe it is played indeed at 120 hz but I cannot see it because of the monitor/graphics susbsystem? What I also don't understand is why rendering not using vaapi makes the rendered file so little bigger at 120 fps than at the original 50. The original was 348 decimal MB, the 120fps one 407 . Finally, rendering was slow, and software rendering did not use 100% cpu, I guess on average about 50. Could be that if I were to use a local (same machine) render farm it goes much quicker. MatN
MatN Not sure I understood everything you said. I was confused by the MotionHVScan error message but then I checked the code base, and I saw that error is in motion-hv and motion2point both. So it looks like you were not even using those plugins? I am a little confused still but I guess the main point is that there is no BT here! On Sun, Jun 27, 2021 at 11:50 AM mnieuw--- via Cin < [email protected]> wrote:
Well, it's good I did not make BT entry out of it.
The error message MotionHVScan only appears in the motion2 plugin. I did three different renders to mp4. a) motion2 removed, H.264 vaapi: rendered 32174 frames in 1604.302 secs, 20.055 fps, file size 1.1 GB. b) motion2 removed, H.264: rendered 32174 frames in 1902.344 secs, 16.913 fps, file size .39 GB ! c) motion2 restored. Time slow because machine went in standby, file size .39 GB. All three played fine.
In all cases, I used a fresh start of CinGG from the bin directory, no effects in action anywhere.
I could not understand yesterday why MotionHVScan would have anything to do with duplicating frames, but it doesn't apparently. I don't know what went wrong yesterday but it must have been something local. No updates were done to the machine.
Now the files all play fine, and VLC says there are 120 fps, but are they really? I don't have a high-fps monitor (it is running at 60 Hz). I should expect that a movie at 120 fps when played at 60 Hz runs at half the speed, or maybe it is played indeed at 120 hz but I cannot see it because of the monitor/graphics susbsystem?
What I also don't understand is why rendering not using vaapi makes the rendered file so little bigger at 120 fps than at the original 50. The original was 348 decimal MB, the 120fps one 407 .
Finally, rendering was slow, and software rendering did not use 100% cpu, I guess on average about 50. Could be that if I were to use a local (same machine) render farm it goes much quicker.
MatN
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I am confused as well. I did not look into the code base, as it appeared too many times there, inclusive unused code. Instead, I searched for the string in the plugins with "motion" in the name in the bin/plugin/video directory. There the only one was motion2. I also did a no_vaapi h.264 .MP4 render test now using the renderfarm, because I was not getting 100% CPU. With 8 client renders on the same machine as the host, it rendered twice as fast and CPU was 100% all the time. Very likely 3 clients would have been sufficient. Anyway, the file size was also as small as without using the renderfarm. I am _guessing_ that witH pure software rendering, upscaling the frame rate from 50 to 120 has a lot of duplicate frames, which pure software rendering detect and therefore decodes as very small differences. I don't have high-fps source media, tried to find some but so far all raw or non-downloadable. And there are multiple raw formats, I wonder how to distinguish between them. I took a short look at the blank frame problem that the freelancer's patch should fix, but have not yet duplicated it. later. Also, I saw weird things using the interpolate video effect, later too. MatN On Sun, 27 Jun 2021 13:06:21 -0600 Phyllis Smith via Cin <[email protected]> wrote:
MatN Not sure I understood everything you said. I was confused by the MotionHVScan error message but then I checked the code base, and I saw that error is in motion-hv and motion2point both. So it looks like you were not even using those plugins? I am a little confused still but I guess the main point is that there is no BT here!
On Sun, Jun 27, 2021 at 11:50 AM mnieuw--- via Cin < [email protected]> wrote:
Well, it's good I did not make BT entry out of it.
The error message MotionHVScan only appears in the motion2 plugin. I did three different renders to mp4. a) motion2 removed, H.264 vaapi: rendered 32174 frames in 1604.302 secs, 20.055 fps, file size 1.1 GB. b) motion2 removed, H.264: rendered 32174 frames in 1902.344 secs, 16.913 fps, file size .39 GB ! c) motion2 restored. Time slow because machine went in standby, file size .39 GB. All three played fine.
In all cases, I used a fresh start of CinGG from the bin directory, no effects in action anywhere.
I could not understand yesterday why MotionHVScan would have anything to do with duplicating frames, but it doesn't apparently. I don't know what went wrong yesterday but it must have been something local. No updates were done to the machine.
Now the files all play fine, and VLC says there are 120 fps, but are they really? I don't have a high-fps monitor (it is running at 60 Hz). I should expect that a movie at 120 fps when played at 60 Hz runs at half the speed, or maybe it is played indeed at 120 hz but I cannot see it because of the monitor/graphics susbsystem?
What I also don't understand is why rendering not using vaapi makes the rendered file so little bigger at 120 fps than at the original 50. The original was 348 decimal MB, the 120fps one 407 .
Finally, rendering was slow, and software rendering did not use 100% cpu, I guess on average about 50. Could be that if I were to use a local (same machine) render farm it goes much quicker.
MatN
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I took a short look at the blank frame problem that the freelancer's patch should fix, but have not yet duplicated it. later.
It does not look like this is usable because it affects too many things from old projects, so I would not waste time looking at it.
On Sun, 27 Jun 2021, Phyllis Smith via Cin wrote:
Not sure I understood everything you said. I was confused by the MotionHVScan error message but then I checked the code base, and I saw that error is in motion-hv and motion2point both. So
Phyllis, Mat, the source files of the obsolete motion-hv plugin are still used in the motion2point and in the interpolatevideo plugin. I expect, all kinds of motion plugins and their friends may have problems when used in the same time with engines which increase frame rate. Frame rate per definition cannot be increased without either duplicating some frames or generating them in some even more intellectual way. But to work reliably, Motion requires access to all actual frames. Therefore it does matter if Motion is used before or after the other plugin which increases frame rate. And if frame rate is increased not via a plugin but via some project setting, then one has to figure out which frames Motion gets, the frames as they were at the source frame rate or that after shuffling. I personally am paranoid in this aspect and apply any plugins which, like Motion, can behave differently depending on the 'play every frame' setting, only at the source frame rate, and all the rest apply later. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
Uhmm... Since high framerates can cause problems with the code involving motion2point and interpolation, maybe we should do as IgorBeg and Pierre suggested: add an asterisk to non-standard resolutions and an explanation popup (or something similar). Plus we need to mention it in the manual with more in-depth details (basically, Georgy's explanations and advice).
On Mon, 28 Jun 2021, Andrea paz wrote:
Uhmm... Since high framerates can cause problems with the code involving motion2point and interpolation, maybe we should do as IgorBeg and Pierre suggested: add an asterisk to non-standard resolutions and an explanation popup (or something similar). Plus we need to mention it in the manual with more in-depth details (basically, Georgy's explanations and advice).
Andrea, the problem of Motion and other possible plugins which depend on feeding every video frame is not too high fps and not any nonstandard fps. There is no problem as long as the source fps, project fps, and destination fps are identical. I am almost sure, 120, or 144, or whatever fps will be just fine for Motion provided that source footage will have the same frame rate. But when project and source frame rates are different (or project and rendered fps), then the CGG engine (probably through ffmpeg libs) has to either duplicate (interpolate) some frames or throw some away. Because of this, the audio tracks and the timeline get out of sync with such accelerated (or slowed down) video. And to make Motion plugins to reliably calculate interframe changes, we have to ensure the consistent frame numbers and frame properties. How it appears in the actual code in CGG, I don't know, unfortunately. To my mind, best practice is to perform the following sequence of preparations to video editing. 1. Motion stabilization and may be some other preparations to improve the quality of the source video. This is best done under the properties identical to the properties of the original video (it may be different codec, but same frame size and same fps). 2. If one needs to alter frame rate (for example because different source clips have different frame rates), then recode all the necessary clips to the same future project frame rate. Here, frame sizes can still have any different sizes, but frame rates should better become all the same. 3. And then the whole editing. Of course, if one needs to change frame rate of some restricted part (particularly when smooth acceleration/deceleration is needed), it will be done here. But if frame rate has to be changed only due to different source fps - better do it during the preparation stage, it is much much more convenient! _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
On Monday, June 28, 2021, Georgy Salnikov via Cin < [email protected]> wrote:
On Mon, 28 Jun 2021, Andrea paz wrote:
Uhmm... Since high framerates can cause problems with the code involving motion2point and interpolation, maybe we should do as IgorBeg and Pierre suggested: add an asterisk to non-standard resolutions and an explanation popup (or something similar). Plus we need to mention it in the manual with more in-depth details (basically, Georgy's explanations and advice).
Andrea, the problem of Motion and other possible plugins which depend on feeding every video frame is not too high fps and not any nonstandard fps. There is no problem as long as the source fps, project fps, and destination fps are identical. I am almost sure, 120, or 144, or whatever fps will be just fine for Motion provided that source footage will have the same frame rate.
But when project and source frame rates are different (or project and rendered fps), then the CGG engine (probably through ffmpeg libs) has to either duplicate (interpolate) some frames or throw some away. Because of this, the audio tracks and the timeline get out of sync with such accelerated (or slowed down) video. And to make Motion plugins to reliably calculate interframe changes, we have to ensure the consistent frame numbers and frame properties. How it appears in the actual code in CGG, I don't know, unfortunately.
there was chapter about plugins in http://heroinewarrior.com/cinelerra/cinelerra.html#PLUGIN-AUTHORING describing 4.1 HV I think ==== The latest evolution in Cinelerra's plugin design is the pull method. The rendering pipeline starts at the final output and the final steps in the rendering pipeline are reading the data from disk. Every step in the rendering chain involves requesting data from the previous step. When the rendering pipleline eventually requests data from a plugin chain, each plugin requests data from the plugin before it. This is less intuitive than the push method but is much more powerful. Realtime plugins written using the pull method can change the rate data is presented to the viewer and the direction of playback. The pull method allows plugins to take in data at a higher rate than they send it out. ==== I also found another framerate table, but it probably only affect ffmpeg plugins: static AVRational best_frame_rate(double frame_rate) { static const int m1 = 1001*12, m2 = 1000*12; static const int freqs[] = { 40*m1, 48*m1, 50*m1, 60*m1, 80*m1,120*m1, 240*m1, 24*m2, 30*m2, 60*m2, 12*m2, 15*m2, 48*m2, 0, }; double max_err = 1.; int freq, best_freq = 0; for( int i=0; (freq = i<30*12 ? (i+1)*1001 : freqs[i-30*12]); ++i ) { double framerate = (double)freq / m1; double err = fabs(frame_rate/framerate - 1.); if( err >= max_err ) continue; max_err = err; best_freq = freq; } return max_err < 0.0001 ? (AVRational) { best_freq, m1 } : (AVRational) { 0, 0 }; } in cinelerra/pluginfclient.C guess we need to add 90*m2 there too?
To my mind, best practice is to perform the following sequence of preparations to video editing.
1. Motion stabilization and may be some other preparations to improve the quality of the source video. This is best done under the properties identical to the properties of the original video (it may be different codec, but same frame size and same fps).
2. If one needs to alter frame rate (for example because different source clips have different frame rates), then recode all the necessary clips to the same future project frame rate. Here, frame sizes can still have any different sizes, but frame rates should better become all the same.
3. And then the whole editing. Of course, if one needs to change frame rate of some restricted part (particularly when smooth acceleration/deceleration is needed), it will be done here. But if frame rate has to be changed only due to different source fps - better do it during the preparation stage, it is much much more convenient!
____________________________________________________________ ___________________
Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] ____________________________________________________________ ___________________
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrea
Uhmm... Since high framerates can cause problems with the code involving motion2point and interpolation, maybe we should do as IgorBeg and Pierre suggested: add an asterisk to non-standard resolutions and an explanation popup (or something similar). After reading Georgy's reply, probably the user's who use the high fps know more about it then we can put in the manual It also sounds like high fps is not really all that non-standard for gamers -- just ordinary people with reasonable monitors!
there was chapter about plugins in
http://heroinewarrior.com/cinelerra/cinelerra.html#PLUGIN-AUTHORING
This chapter was purposely left out of the GG manual because anyone who
wants to write a plugin can look at the other ones and see how they work as they will have to understand it anyway. Plus we did not want to have to review that chapter to make sure it was all still correct.
I also found another framerate table, but it probably only affect ffmpeg plugins:
static AVRational best_frame_rate(double frame_rate) { static const int m1 = 1001*12, m2 = 1000*12; static const int freqs[] = { 40*m1, 48*m1, 50*m1, 60*m1, 80*m1,120*m1, 240*m1, 24*m2, 30*m2, 60*m2, 12*m2, 15*m2, 48*m2, 0, }; double max_err = 1.; int freq, best_freq = 0; for( int i=0; (freq = i<30*12 ? (i+1)*1001 : freqs[i-30*12]); ++i ) { double framerate = (double)freq / m1; double err = fabs(frame_rate/framerate - 1.); if( err >= max_err ) continue; max_err = err; best_freq = freq; } return max_err < 0.0001 ? (AVRational) { best_freq, m1 } : (AVRational) { 0, 0 }; }
in cinelerra/pluginfclient.C
guess we need to add 90*m2 there too?
OK, I will make a note to make this table look the same BUT not until after Thursday.
On Tue, 29 Jun 2021, Andrew Randrianasulu via Cin wrote:
there was chapter about plugins in
http://heroinewarrior.com/cinelerra/cinelerra.html#PLUGIN-AUTHORING
describing 4.1 HV I think ====
The latest evolution in Cinelerra's plugin design is the pull method. The rendering pipeline starts at the final output and the final steps in the rendering pipeline are reading the data from disk. Every step in the rendering chain involves requesting data from the previous step. When the rendering pipleline eventually requests data from a plugin chain, each plugin requests data from the plugin before it.
This is less intuitive than the push method but is much more powerful. Realtime plugins written using the pull method can change the rate data is presented to the viewer and the direction of playback. The pull method allows plugins to take in data at a higher rate than they send it out.
OK, plugins are allowed to change frame rate and/or direction, but still not clear what happens with such plugins like Motion when project fps differs from source fps... _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
I think this is important information to put in the manual. I would like to look into it first to understand how CinGG works. As a further cue we can see Cinelerra-CVE by Einar Rünkaru. He implemented the PTS to be able to manage in timeline sources with different framerates, resolutions and sizes. In the readme of his Github is written (https://github.com/vanakala/cinelerra-cve): "- Another huge change implementation of pts based timing. This enables to edit media with variable framerate and get rid of assumption that audio and video start simultaneously." "- implemented pts based timing on video and audio making possible projects without constant framerate" To do this he had to rewrite much of the program losing compatibility with other versions of Cinelerra. So I don't think it's possible to implement it in CinGG; but it may be useful to do a comparison to see how it works in CinGG. Here instead is information on how Lumiera (a total rewrite of Cinelerra) is designed: https://lumiera.org/documentation/user/intro/intro.html Also interesting is the part about Cinelerra's (insurmountable) limitations that led them to do a separate project: https://www.lumiera.org/project/background/history/CinelerraWoes.html
I tried to put this info in the manual. See if there is anything to correct and improve the text.
Andrea, Thank you. I will be reading this and your changes to Plugins today too. I have a few small changes to add in other places. Maybe we need a section on Color Management? can start small and add to it later? On Mon, Jul 5, 2021 at 5:18 AM Andrea paz via Cin < [email protected]> wrote:
I tried to put this info in the manual. See if there is anything to correct and improve the text. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Maybe we need a section on Color Management?
Unfortunately, I'm not able to talk about how CinGG handles colors. There are too many points I don't understand and the few I do intuit are probably wrong. I've tried asking Adam Williams who also replied: "There is no color management workflow. They shouldn't sell it as a replacement for Davinci Resolve." Which, as you can see, doesn't clarify anything, other than his temper. :-) It's a problem we don't have experts who know the field because, especially in this days, it's a very important point.
On Monday, July 5, 2021, Andrea paz via Cin <[email protected]> wrote:
Maybe we need a section on Color Management?
Unfortunately, I'm not able to talk about how CinGG handles colors. There are too many points I don't understand and the few I do intuit are probably wrong. I've tried asking Adam Williams who also replied:
"There is no color management workflow. They shouldn't sell it as a replacement for Davinci Resolve."
Which, as you can see, doesn't clarify anything, other than his temper. :-)
It's a problem we don't have experts who know the field because, especially in this days, it's a very important point.
yeahhh... I can't wrap my head around even simple concepts.. And apparently fast enough (for FHD/++ videoplayback) color managment demand either VERY fast CPU or OpenCl (and free OpenCl drivers not in great shape.. no OpenCL <-> OpenGL interop, so I can't just bolt some ocl code on top of existing CinGg infrastructure..) https://littlecms.com/blog/2019/10/02/througput-babl/ times measured in seconds (for 32 bit per ch floating point image) definitely not great for sw playback of video... But may be we can write to Marti and talk about our little problem?
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (7)
-
Andrea paz -
Andrew Randrianasulu -
Georgy Salnikov -
Igor BEGHETTO -
mnieuw＠zap.a2000.nl -
Phyllis Smith -
Pierre autourduglobe