Since the Effect strips are using the full range at saturation level: 35, any new strip colors should not use colors with that saturation level to ensure unique colors for all strip types.
The source strips are at saturation level 46. (Scene strips and Mask strips colors must have been altered since this design was implemented and therefore have wrong saturations levels...)
Fully saturated elements are reserved for selection, so those elements stands out.
Sorry for noise, phabricator is bit confused...
So, maybe the two new header colors should properly be found in the saturation level of the source strips?
Reopening, because fix caused another issues, so it has been reverted.
Reopening, because fix caused another issues, so it has been reverted.
@Richard Antalik (ISS) , @Marcos Perez (pistolario) hi, i have a suggestion, if possible, why not let the user play with the range of Hz, so he can be confortable with his range and the curve ,so if he want to have to change another range he only need to add another Equalizer modifier
also i hope if we can select multiple points(handles) at the same time by shift + drag , thank you
@Richard Antalik (ISS) , @Marcos Perez (pistolario) hi, i have a suggestion, if possible, why not let the user play with the range of Hz, so he can be confortable with his range and the curve ,so if he want to have to change another range he only need to add another Equalizer modifier
Wondering if it's appropriate to bump this up here or if it's a RighClickSelect thing, I'm new :) But I would also love very much for DNxHR to be exposed as an encoding option. Without it, there doesn't seem to be a 4k video encoding option available in Blender that is suitable as a modern production level codec, if I'm not mistaken, and this makes using the VSE for final 4k video output kind of impractical for production. If it is indeed simple to expose DNxHR then it would be very helpful! Thanks for considering.
Oops! Too late. I didn't notice the commit.
I've looked into this one and the issue is caused because wm_draw_region_stereo_set is only called when stereo is in use, so multiview_eye is left as STEREO_RIGHT_ID after disabling stereo rendering.
this can be repeated with any video file, tested by another user.
Had a review a few days ago with Richard. Here is the feedback:
Please keep the lower channel and show an empty one on top. This should help with usability.
Indeed intuitively it sounds correct that anything playback-related is to be stooped in all scenes.
Having an empty channel on top is ok.
Would you also show it when you press the home key?
@Sergey Sharybin (sergey) This seems to happen, because stopping animation playback from different scene won't stop sound playback within the scene - see ED_screen_animation_play(). I think, that stopping playback should stop sound playback in all scenes. Would you agree?
@hamza.SMA (hamza.elbarmaki) VSE also has an option to preview all three modes and you can preview exactly what you have with this setting:
Thanks for the report, I can confirm the issue.
I also edited the description to make the problem clearer.
Seems that this has been resolved already, so will close.
Closing since this issue has been resolved.
Turns out I was not correct at all, the issue is float precision mainly in add_v2_v2(uv, user_data->add_x); in ScanlineProcessor::process(). There is Y "wobble" as well. I guess that double type could be used internally, but that just moves the issue further away. Also performance is in question. Will check fixes performance wise and discuss with @Jeroen Bakker (jbakker)
Makes me think of T90785. I need to update the patch and will check this report as well.
I am not sure we can put it as simple as whether this is on VSE side or on the render pipeline side. The OpenGL animation render uses special tricks to keep the dependency graph alive, since it knows that it renders single scene. The final F12 render with default configuration will re-create dependnecy graphs for every scene which renders, but with the Persistent Data option it is possible to reuse more data.
As it would be best if these two strip types get headers in colors not used yet, these are the colors currently in use in the VSE:
Design does support that, but it's currently prevented by UI
Please use const whenever possible, see https://wiki.blender.org/wiki/Style_Guide/C_Cpp#Const. This goes at least for new code that is being written.
Does this approach support reverse playing as the existing Speed effect does?
Sorry, I forgot to re-check on this. I have forgot to put this report on TODO list and browser crashed.
If I understand this report correctly, then this is caused by the current design of render pipeline and sequencer.
/* Sorry, scratch the reply, i accidentally replied to the wrong report*/
Just to continue with curve constant median line patch
I've recovered ISS's changes and added a little tweak in order to soften the borders of the EQ definition, in case of several curves.
Hi!
There is a vector with the equalization parameters initialized to 0. Then, it is overwritten with ONLY the range of the CURVE. So, there is no extrapolation. There could be a SHARP CUT, which we could try to soften in order to improve the quality of the result.
I am not sure extrapolation is the correct term to be used here. it is more like "overshoots". This is an important behavior for audio artists. So it is kind of blocking. Maybe same code from Richard can be applied here on in the D16157 (did not look into details of that change from Richerd, so not sure where it belongs the best) ?
@Marcos Perez (pistolario) Just checked on state of the patch and seems, that you have removed changes I have implemented - added argument default_handle_type in function BKE_curvemapping_set_defaults. See https://developer.blender.org/D14412?id=54663 for older state where these were implemented.
AFAIK for UI there is still outstanding issue, that curve can be extrapolated, which is not desirable.
Referencing comment https://developer.blender.org/D14412?id=54663#432277
@Marcos Perez (pistolario) Just checked on state of the patch and seems, that you have removed changes I have implemented - added argument default_handle_type in function BKE_curvemapping_set_defaults. See https://developer.blender.org/D14412?id=54663 for older state where these were implemented.
Will fix, also noticed, that when moving handles it makes the effect wiggle a bit, which is bit strange.
Can confirm, will check
Quite interesting issue, I would assume this is bug, but will have to investigate to understand what is going on.
@Richard Antalik (ISS), yes, can reproduce this.
A horizontal split by dragging from any corner seems to always result in a crash.
Vertical splitting seems to work correctly.
I agree that the header color could be better. I felt that the gray color also was a bit out of place for a transition, so I tried a more neutral shade of purple. Here it is compared to strips with a similar background color. They're used in different places, so I doubt they'll get mixed up easily.
