Ungrouping of video and audio clips after some edits
It'd probably be easier to just show what's going on. Here's a short video https://youtu.be/QOSCdSH4Szc. Would this be considered a bug? Maybe there's some way around it... but it shouldn't be the default behavior.
It is working as it was intended. The original hv version of cinelerra exhibits this behavior. That is, the drag selection is all armed tracks that are aligned under the cursor at the drag start. When a track is disarmed, it is not modified and the timeline association is lost. There is an editing function in the "edit" pulldown menu called "align edits" that I use to re-align edits, but I agree that it is not always easy or convenient to do that. Just yesterday, the latest build was pushed. It contains a new feature (that is still being engineered, and some changes may occur soon) which allows you to create temporary or more permanent clip associations as "groups". See Features5.pdf, section 47. If you do try this new version, and think you have any valuable suggestions, let us know since the new feature is still being finalized. gg On Tue, Jan 1, 2019 at 8:38 PM Xing Tu <[email protected]> wrote:
It'd probably be easier to just show what's going on. Here's a short video https://youtu.be/QOSCdSH4Szc. Would this be considered a bug? Maybe there's some way around it... but it shouldn't be the default behavior. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Oh shoot. If only I had RTFM'd. Thanks for pointing that out. I've only read the first few sections before exploring by trial and error, as one does. By the way, thanks for all the work you and everyone else has done. I remember using cinelerra-cv a few years ago and not being completely satisfied as far as stability was concerned. While it isn't -gg's primary focus, it seems to work pretty well. A good NLE was the only thing keeping me from away from Linux. On Tue, Jan 1, 2019 at 8:05 PM Good Guy <[email protected]> wrote:
It is working as it was intended. The original hv version of cinelerra exhibits this behavior. That is, the drag selection is all armed tracks that are aligned under the cursor at the drag start. When a track is disarmed, it is not modified and the timeline association is lost. There is an editing function in the "edit" pulldown menu called "align edits" that I use to re-align edits, but I agree that it is not always easy or convenient to do that.
Just yesterday, the latest build was pushed. It contains a new feature (that is still being engineered, and some changes may occur soon) which allows you to create temporary or more permanent clip associations as "groups". See Features5.pdf, section 47.
If you do try this new version, and think you have any valuable suggestions, let us know since the new feature is still being finalized.
gg
On Tue, Jan 1, 2019 at 8:38 PM Xing Tu <[email protected]> wrote:
It'd probably be easier to just show what's going on. Here's a short video https://youtu.be/QOSCdSH4Szc. Would this be considered a bug? Maybe there's some way around it... but it shouldn't be the default behavior. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I just played around with the align edits feature. It works as intended but not what I was looking for. It's helpful if, like is stated in the manual, the audio happens to exceed or is shorter than the video and is in sync from the start. However, I'm purposefully having the audio/video of one "clip" overlap that of another and using the feature to either truncate a preceding "clip" or add empty space is, in this case, making the audio/video out of sync. I made another video addressing the suggestion of using the new groups feature here https://youtu.be/YAt5SDCIhn8. Also, is there a way to view a list of undos? I wasn't able to find anything by searching for "undo" or "history" in the pdf.
Feedback:
I'm purposefully
having the audio/video of one "clip" overlap that of another and using
the feature to either truncate a preceding "clip" or add empty space is, in this case, making the audio/video out of sync.
I think that you are omitting the fact that all track streams must be independent. If they are always bound in the way you seem to describe, it would not be possible to create arbitrary alignments. This is essential, since the result must support all possible media placements. Unfortunately, there are several ways in which operations can be implemented and in order to have it work the way one person expects, than another way does not work. Case in point is BT issue #85 where the Shift key is discussed. You can still get what you want by switching from Arrow mode (Drag and Drop) to Ibeam mode (Cut and Paste). Switch quickly using the shortcut letter "e" in the main window. Now in Ibeam mode: 1) left mouse drag the area you want to cut, it will be white highlighted on ALL TRACKS to include audio 2) use the shortcut letter "x" to cut it out; you can use this method to easily add silence instead with letter "m" Even the above leads to preference differences because now you have to remember to arm/disarm tracks you DO NOT want to cut.
I made another video addressing the suggestion of using the new groups feature here https://youtu.be/YAt5SDCIhn8.
The undo is specifically for "edit" operations and grouping is not considered an edit but the state at the time of the undo edit is reverted to the last commit for an editing operation - this is what you show in your video.
Also, is there a way to view a list of undos?
There is no obvious way, but you can do a Ctrl-C from the terminal window where you started running cin and it will create a /tmp/cin...dmp file that contains the last 32 UNDO entries (I only tested when logged in as root and most importantly, you can only do this once per run because the second time, it stops cinelerra).
I think that you are omitting the fact that all track streams must be independent. If they are always bound in the way you seem to describe, it would not be possible to create arbitrary alignments. This is essential, since the result must support all possible media placements.
I think Good Guy made that clear in a previous message and it makes sense. However, when the video "stream" is *grouped* with the audio "stream", the only thing that's possible is moving them around (or performing the operations available in the middle click menu). It's counter-intuitve that when trying to extend or shorten the length of the video stream, the corresponding audio stream remains unaffected (and vice-versa) despite being grouped.
You can still get what you want by switching from Arrow mode (Drag and Drop) to Ibeam mode (Cut and Paste)...
I can see how this would work, but it comes back to the original problem of having to perform multiple actions. In addition to what you said about having to keep in mind which tracks are (dis)armed, the user would also be required to count the number of frames they removed (or added when using the "drag all following edits" action) from the video stream and do the same for the audio stream. It's clear that this is inefficient.
The undo is specifically for "edit" operations and grouping is not considered an edit but the state at the time of the undo edit is reverted to the last commit for an editing operation - this is what you show in your video.
That's what I thought after thinking for a bit... but can you explain why both groups were separated after the second "undo"?
There is no obvious way, but you can do a Ctrl-C from the terminal window where you started running cin and it will create a /tmp/cin...dmp file that contains the last 32 UNDO entries
Okay, so that's why ctrl-c has to be done twice to exit. It'd certainly be useful if you guys can figure this one out. Thank you guys again, though. It's really appreciate from some dumb user that you guys are even working on this project and have made all the improvements so far.
Am 02.01.19 um 20:50 schrieb Xing Tu:
I think that you are omitting the fact that all track streams must be independent. If they are always bound in the way you seem to describe, it would not be possible to create arbitrary alignments. This is essential, since the result must support all possible media placements. I think Good Guy made that clear in a previous message and it makes sense. However, when the video "stream" is *grouped* with the audio "stream", the only thing that's possible is moving them around (or performing the operations available in the middle click menu). It's counter-intuitve that when trying to extend or shorten the length of the video stream, the corresponding audio stream remains unaffected (and vice-versa) despite being grouped.
I also know it from CC PP. There it also works the following way. Probably you mean that. https://streamable.com/qqjni
You can still get what you want by switching from Arrow mode (Drag and Drop) to Ibeam mode (Cut and Paste)... I can see how this would work, but it comes back to the original problem of having to perform multiple actions. In addition to what you said about having to keep in mind which tracks are (dis)armed, the user would also be required to count the number of frames they removed (or added when using the "drag all following edits" action) from the video stream and do the same for the audio stream. It's clear that this is inefficient.
Since I am used to it from PP as well, it would surely be a significant improvement. The Group feature is relatively fresh, as Cinelerra lagged behind the other NLE's as far as the timeline feature was concerned. GG did an excellent job and improved many things in the timeline. I don't know if he could add this feature. In the long run I would welcome it and join this feature request because it is a very big relief. In PP it greatly facilitates the work. Sam
Yes, exactly. It was the only problem I stumbled upon when trying to do a basic project. If that gets implemented, then as far as basic editing goes, cin would be perfect. Actually, one more thing would be if "drag source only" would also apply to groups. In my opinion these features should be prioritized since cin is after all an NLE and these are key components in such a system.
I can confirm that in PP the Trim feature (roll, shift, source, etc.) can also be applied to the group. It works like the Trim feature on individual clips, only that the associated other grouped clips are shortened or lengthened in the same way. By the way, in the Compositor window of PP, the clip in which the mouse pointer is located is displayed. Only one channel is displayed at a time, just like in normal Trim mode. I guess it's just applying the normal trim mode of one channel and synchronizing the shortened or extended frames to the other channels. In fact, Cin doesn't lack much to be on par with the other big NLE's when it comes to working in the timeline. With these improvements Cin is absolute great and reaches in my opinion the tipping point to become really popular. Am 02.01.19 um 22:15 schrieb Xing Tu:
Yes, exactly. It was the only problem I stumbled upon when trying to do a basic project. If that gets implemented, then as far as basic editing goes, cin would be perfect. Actually, one more thing would be if "drag source only" would also apply to groups. In my opinion these features should be prioritized since cin is after all an NLE and these are key components in such a system.
Xing Tu:
Okay, so that's why ctrl-c has to be done twice to exit. It'd certainly be useful if you guys can figure this one out.
You can now dump the undo stack and if you started cin from a terminal window, it will display something like the following there up to 32 undo-s with program addresses that it keeps also. UndoStack::dump 0 0x68e3af0 record patch 119 0004 * k 1 0x47b0080 record patch 37413 0004 2 0x68e0bb0 record patch 2802 0004 3 0x469f1b0 record patch 1529 0004 4 0x46c1700 split | cut 1529 0011 5 0x46c1eb0 split | cut 1193 0011 6 0x45a8f10 split | cut 1193 0011 k 7 0x46c2060 split | cut 37076 0011 8 0x469e660 split | cut 2580 0011 9 0x68cf280 split | cut 1071 0011 10 0x46bc070 record patch 1071 0004 11 0x409b810 record patch 956 0004 12 0x45a8eb0 record patch 956 0004 13 0x45bf510 record patch 841 0004 k 14 0x7ffe3465ffc0 paste assets 36905 0001 15 0x7fff6c00b5e0 paste assets 4 0001 k 16 0x68eea70 add track 36205 ffffffff 17 0x409a610 add track 4 ffffffff k 18 0x40e7af0 add track 35677 ffffffff k 19 0x4599000 add track 34373 ffffffff k 20 0x7ffe4c4073a0 load 30481 ffffffff 21 0x7ffe4c01bc40 load 841 ffffffff k 22 0x46cd670 move edit 26271 ffffffff 23 0x45a2360 move edit 2937 ffffffff k 24 0x4698f10 load 26106 ffffffff k 25 0x65161e0 load 3768 ffffffff can you explain why both groups were separated after the second "undo"?
It is not really that both groups were separated after the second "undo" - what it really is, is just like an Oracle database "commit". As the program runs, a commit writes down the current state of the user's work; when you operate the first undo, you are just reverting to the state of the space when it was written down. With the 2nd undo, you are now reverting to what was written down before that. I have explained this as well as I could, but my field is computers and it is so automatic to me, that I have no better way to convey this (so my apologies). It's counter-intuitve that when trying to extend or shorten the length of
the video stream, the corresponding audio stream remains unaffected (and vice-versa) despite being grouped.
I will look at Sam's qqjni.mp4 steamable to get a better understanding of exactly what you are referring to so I can relay this to gg.
Actually, one more thing would be if "drag source only" would also apply to
groups.
By this are you referring to section 41.3 Trim Feature with Drag Handle, Button 3? Either way, it is now a little easier for me to keep track of what needs to be added to Cin, if it is added to MantisBT bugtracker. Thanks, Phyllis/gg
It is not really that both groups were separated after the second "undo" - what it really is, is just like an Oracle database "commit"... thanks for clarifying. it makes sense
are you referring to section 41.3 Trim Feature with Drag Handle, Button 3? yes. the operations of mouse buttons 1,2,3 with the drag handle should all apply to grouped clips
participants (4)
-
Good Guy -
Phyllis Smith -
Sam -
Xing Tu