It's also easy to replicate with the following steps:

1. Create two scenes with the same settings (scene1 and scene2).
2. Select scene1.
3. Create 2 color strips which are on top of each other and group them into a metastrip (Ctrl+G). Use a box select to select both strips.
4. Create a third color strip and place it in front of the metastrip.
5. Select the third color strip and the metastrip; it doesn't matter which is the active one.
6. Copy (Ctrl+C)
7. Select scene2, put playhead at frame 0 and paste (Ctrl+V). The metastrip is pushed up 1 channel. If there are strips above the group, they stay in place and the metastrip is moved up further.
8. Apparently, this issue does not occur if the playhead is positoned at frame 5 or further.

Yes, you're right. Before the export they sound indeed the same. Perhaps I wanted to hear the difference because I knew about the profiles. So, I did the test and recorded the sound (with volume set to 5) with a microphone. The waveform looks identical in Audacity. So, it's a problem of the render (to video). The render audio can do it right, if accuracy is set low.

I included the original sound-file (bounce.wav), a blend-file with the sound-strip + 2x duplicated. You can hear the difference between the swooshes (but not very clearly). I included also the wave-form of the render (of the three (identical?) soundstrips. You can clearly see that the waveform of all three has small differences. After rendering the audio only, in which case you can set the accuracy (low value = high accuracy), the differences disappear. I included also the Audacity-profile of this audio-only output..

Will this patch be incorporated with version 2.92?

@Richard Antalik (ISS) Hi Richard, I still can't open the test-file (my blender version 2.91.0 Alfa - Windows 10 crashed immediately). I've done the following. Is this correct? 1) From the menu at the top right, Download Raw Diff (I should not look at the 10578 build in DIFF detail, I suppose). 2) Apply the command git update xxx.diff (downloaded diff), 3) rebuild with make.bat (on Windows 10). I'm in the impression that I don't have the latest version of the patch. Thanks for your answer. PS. I see now that there is a file versioning_290.c. Maybe, it has to do that i apperently use the 2.91 build?

@Richard Antalik (ISS) Hi Richard, I wanted to try the patch with the supplied test-file, but when I try to open the the grand_unified_test.blend file from the supplied transform_test.zip, Blender crashes immediately. May be, I didn't install the patch correctly (cfr. your comment about bump subversion). Can I check this? Also, as I mentioned earlier, on reopening a saved project, some previous changes (eg scale and position) are reversed. Thanks for the great improvements of the VSE.

@Sergey Sharybin (sergey) Hi Sergey, many, many, many ... thanks for this super patch. This is so much needed! I followed the development quite a while and finally decided to enter unknown territory (for me) and try to download the blender source code, apply the patch and rebuild the binaries. It took me a while and some effort but … man, was it worth it! Not only do I have a clearer view how Blender works internally; the patch is also working superb. I use a Windows 10 machine; so if you should like to do some testing in this environment, don’t hesitate to ask. I will be more than happy to do something in return for your great work.

Will this patch be integrated in version 2.91?

I tend to disagree. Even if (?) Blend modes are ‘basic’, they should be properly explained, be it by a non-expert. In my view, the Blender manual should be the first and most important information source for the Blender user. I don't know if there are any statistics but it's my gut feeling that when a user encounters a problem, he or she will not open the manual first (if at all). There is a reason why there are so many tutorials on YouTube and the internet.

Thanks for the feedback.

• Blend modes are used quite a lot at several stages in production. I don’t think they are out of scope in Blender and therefore they should be properly documented, even only as-is.
• The GIMP documentation is OK but they have lesser/different modes (e.g. dissolve) and use different terms (burn vs color burn, linear burn, ...). This is the same for other software (Krita, Photoshop, Nuke, …). The additional difficulty of display/scene referred environment remains.
• A separate section (instead of VSE) looks indeed better. Integrating this in the glossary is in my opinion not feasible and also does not serve the purpose of a glossary.
• I do think that a theoretical foundation (incl formulas) is necessary (there is nothing so practical as a good theory :-). The documentation in the manual is at the moment insufficient to get a clear understanding and the info outside (tutorials, etc) is most of the time along the lines of “click this”, “try that” or a few screenshots of the results.
• That said, of course, it remains a complex matter. Maybe someone/ expert is interested in working together on this topic? I’m certainly willing to do the preparatory work.

Corrected the text according to the remarks;
Not sure about the requested blank lines.

The comments of Tobias are integrated.

I see now that in the diff file there is a section of a text I'm working on. (at the bottom) Please disregard them. I have not figured out how I can make a diff-file for a single rst-file or to build the html-page for that file alone (I keep the revisons in a separate folder). Do you know about any info or tutorial about this workflow?

Here the pictures in the standard UI.

I've addedd the container tag and also uploaded the pictures in the standard UI.

Hereby a new version of the example image.

Hi Eitan,
Sorry for all the additional work on this update. I'm rather new on the Restructured Text and Subversion thing.
Concerning the Node Wrangler tab. The idea was in fact to add such a tab to indicate that there can be additional tabs. But, you also had a case that this is not the standard Blender UI.
So, If you would like, I can remake all of the pictures without the Node Wrangler tab and make them at the same time smaller. But, can you then tell me what a preferred size would be? Or can I test it myself to see if there are no misalignments? Rebuilding the html locally?

The text is updated with the correct links to the images. I have also changed the image size from 331 * 419 to 267 * 338 px (cfr remark Eitan). The width of 267 px is the same as the width of the original image in the old text (was not sure about how small the images should be). I've added the resized images in this comment.

I've made the required changes (italicized) but also took advantage of the opportunity to elaborate on some points.

I've added the remark "[here about figure xxx: Sidebar with the View tab selected.]" to indicate where the figures should be placed.
In a previous patch I've tried to add the images myself (apparently not in the correct way). Thereupon you have asked to put them in the comments.
So, I did this also with the current patch. To indicate where the new figures should go, I've added the above sentence.
It would be easier for me and for you if I could add the images myself. Is there some info about how to accomplish this?

Hereby the image-files.

Yes, that's OK. Thanks.

In attachment, the following files are included in a zip-file:

• modeling_modifiers_deform_simple-deform_intro.png
• modeling_modifiers_deform_simple-deform_bend-1.png
• modeling_modifiers_deform_simple-deform_bend-2.png
• modeling_modifiers_deform_simple-deform_bend-3.png
• modeling_modifiers_deform_simple-deform_bend-4.png
• modeling_modifiers_deform_simple-deform_bend.png
• modeling_modifiers_deform_simple-deform_stretch.png
• modeling_modifiers_deform_simple-deform_taper.png
• modeling_modifiers_deform_simple-deform_twist.png