translating sequences (image strips, video, scene, or whatever) by accurate pixel offset is nice, but often you want to be able to get a "feeling" of your translation. Like in the 3D view, if you could only translate your 3D objects by setting numbers in x,y,z fields and no possibility of drag and drop by mouse, that would be very annoying. Same for the sequencer preview. So the attached patch implement this drag and drop translation.
You can initiate the drag and drop by:
- either clicking with your select mouse button: the feature takes into account your settings for left/right selection. It also takes into the "release confirms" settings, so that it works similar as other views according to user settings.
- or with a keyboard shortcut (default "g" for consistency with defaults on other view, again).
This first version of the patch has no "selection" feature. You must first select sequences in the sequencer views. Maybe a future improvement could be to give possibility to select graphically your sequences, but not just now.
You can also select several sequences in the sequencer if you want to drag them all in the same time of the same translation value. I made so that it translate only what is visible at the current frame. That allows to select everything with "a" for instance but only visible sequences are translated (and you don't get bad surprise later).
Of course it drags only sequences where use_translation is set as well ("Image Offset" box checked).
Finally it takes Flipping into account, so that even though you flipped x, y or both, you get what you expect when you drag your mouse.
- after applying the patch and compiling, select a sequence in the sequencer, and set the current frame to one where this sequence is visible.
- ensure that "Image Offset" is checked in the "Strip Input" section of this sequence properties.
- go in the sequencer preview and click in it with your usual selection mouse button. You will be able to move the sequence offset (with instant screen preview) by drag and drop, just as you would for objects in most other views.
As a finale comment, I would suggest to commit first the patch for bug #34013 to fix translation and crop rendering which are broken in the current dev repository. Without this other bug fix, the current feature won't react as expected as well, obviously.
Thank you Jehan, this would be of great benefit to the user in their interaction with Blender . As you suggest it seems an appropriate way to extend basic conventions from other Blender components. Elsewhere you expect to be able to grab and interact with images directly on the screen.
I believe this concept is coming to the compositor, why not institute it in the Sequencer too?
I would like to voice my support in the strongest possible way.
geo: maybe you will find the attached patch sequencerpreview_translation_v2.diff slightly faster.
This said, the existing preview display code is pretty slow. Just change the "Image Offset" fields, there is always a small delay. And that's just for changing from 1 value to another, not even for a continuous move as this feature patch allows.
Obviously what is slow is the preview redraw. If you want a really smooth move, you need to redraw the preview as many times as possible (to show intermediate positions, hence providing moving effect). Well I guess that's normal it takes time especially if you have many objects on screen (this is after all a render on screen and explains the "Refresh Sequencer" button, I guess), same as the animation playback is not smooth when you play it. Of course the playback can be improved by attributing a lot of memory and as many frame prefetches as your memory allows (user preferences). Unfortunately that cannot apply here because the sequencer obviously cannot guess in advance where you will move your mouse.
There could be optimizations, like only updating the region which changed. But I could not find how to do this in blender code. Also not sure if it would improve fluidity that much. Especially as I said, the underlining implementation already seems quite slow to me, hence I believe that's a much deeper fix which is needed.
If a developer who knows better blender code sees a good way to improve this patch, please tell me. :-)
I'll conclude by saying I think this current proposition is a first step and better than nothing. No? In my tests it is indeed not very smooth, but still usable and nicer for image placement than by using offset fields.
On my system with Mint 14 it works very well and fast. Thank you very much, the feature is amazing.
I suggest adding the possibility to press x or y keys to lock to an axis while transformation, consistent with every other transformation in blender.
I thought about this (axis lock) too indeed, as well as other improvements. But I will wait for this first patch to be accepted first, I guess. I want to be sure blender team will make it in the dev tree before going further and work for nothing (and I would be sad). :-)
Yes lock is a good idea. I also thought that shift key to make fine adjustment would be very usefull too.
In some pro NLEs you can switch to a wire frame view of the asset, that is a box with an X through the middle, this speeds redraw and gives a rough indication as to location. It is often switchable or could be live, that is automatically switched when interacted with?
There is another issue, sometimes you can accidently nudge the asset by click and draging in the preview window with the wrong key. I often zoom in and then pan the image to the part I want to investigate. But if I choose the wrong mouse button I could end up translating the image instead. I really think that using G key should be a switchable default that the user could define as always active if they prefer.
david: shift key would be used for translating by step no? Like 10 by 10 pixels or such? That would be very easy to do too.
Wire frame view is a good idea too. I actually thought of something similar, with a grid or something. Maybe some day I would do it, if I feel the need myself.
For accidental drag and drop, I think the real solution is to have history working also with this operator (ctrl-z and other similar cancel/redo features). Apparently it does not. I would have thought that this would be a general feature working everywhere by default, but seems you have to set the OPTYPE_UNDO flag to this operator for it to push an undo event at the end. The attached patch sequencerpreview_translation_v3.diff now has this improvement.
If you make a mistake, you can just hit ctrl-z as usual, or any other method that you may use to undo (ctrl-alt-z will now show you the transform event in the history that you can do there as well, for instance).
As for using another key, well you can obviously, in the user settings "input" tab, search for the "transform selected sequences" operator in SequencerPreview, you can change the shortcut, unchecking the checkbox to deactivate it (or even just delete the shortcut alltogether).
the constraints along axis were very to add so I thought I could add this anyway. :-)
So now you can click X or Y during transformation to constraint along respectively the X or Y axis. And C to clear any existing constraint. Basically I just usual conventions. :-)
I actually thought about it. But even though right now only the position can be changed graphically, at term we can imagine being able to crop or do other transformation (scale? rotate? These are filters though) with a mouse.
So do we want a keyframe inserted from the preview window to only work for the position? Or for all possible value?
Have you seen this addon for attaching a transform effect to selected strips and interacting directly with the preview window? http://blenderartists.org/forum/showthread.php?280731-VSE-Transform-tool
david: no, I haven't seen it; but now thanks to you, yes I have. :-)
I think this transform-by-mouse feature really miss to core blender though, more than as a plugin. This plugin is more advanced than my core feature though (more functions already). But honestly if I don't write the other features now, that's only because I want to be sure that my patch is going to be accepted upstream (as I said in a comment above). If it is, adding all the same features as this plugin is quite easy, and just a matter of a few hours of code and test. But if it isn't, well I don't want to work for no reason. That's the advantage of plugins over core features: they don't care if they are upstream or not.
But I believe in contributing upstream, in particular for features as basic as being able to transform a sequence with a mouse, which any NLE should have.
The plugin is nice for now though, as long as this feature has not made it yet into a released version of blender. :-) So that's complementary.
Yes Jehan I absolutely agree. Your code should be built in so that broken addons don't just fail in future versions of Blender. The addon is great as a proving tool though, at the BA thread I have suggested approaches for adding a simple drop shadow soft/hard but they are difficult to implement due to the number of layers required. Oh well.
so, sorry for the long delay, I had finally some time to review the patch.
Could you please remove the pthread dependency? Direct use of pthread is something, Ton doesn't really like, since Blender has it's own
thread library which in turn uses pthreads. Also, I think, you shouldn't need it here:
As far as I can see, you do some reentrancy checks, which shouldn't be necessary IMHO, if the order of operations was correct.
At least, the other grab transform tools don't need thread locks, it looks all a little bit fishy to me (and might be the cause, why some users have a slow experience with the tool).
Thanks in advance and again sorry for the delay, I'm pretty busy right now with non-blender stuff, sorry.
Thanks for the answer! No problem for the delay, as long as there is an answer at some time. I understand! :-)
For the thread, yes I was unsure whether it was useful or not at all, because I don't know well blender architecture and how signals are processed. Anyway I'll review my code and propose another version.
Well in the end, I am the one who answers very late! Sorry for this too. :-)
So I checked again this code. Actually you are right. The thread code is completely unnecessary. I don't know why, for some reason, I thought that the event handling procedures could be concurrent, but actually they aren't.
So that's basically the exact same patch without any concurrency code. It seems to work still very fine. I hope it will make it to the tree. :-)
The UI team are working on a general overhaul of Blender interaction, and there was a good proposal on bf-lists recently. I hope that this patch can be included during that review. Anyway thankyou for your work on this tool. ;)
Well you are welcome. That's also for me. ;-)
About this review you are talking about, how can we make sure this patch is considered in? Is there some place (mailing list or else...) where we can have this patch noticed and voice interest? Because if the only reference is this report, well it may be lost inside hundreds of others.
If you are willing to push this on the review list for me, don't hesitate. I'm actually travelling, so I have no internet connection, nor home and my time is very limited (which is the reason also why I did not review this patch for a long time too). So it's hard for me to follow too closely until I'm settled again (likely next June).
When I'll have time again, I'll even want to improve even more the user interaction in the VSE.
Checking back what's the status after some time has passed. :-)
I see that the blender project has now passed to git! So I took a few minutes to recompile on git master, fix a few things which changed in between (s/FALSE/false/ s/TRUE/true/ and some updated callback signatures).
So attached is the updated patch, formatted with git format-patch origin/master.
Would be nice if it could be reviewed by someone and could make it to master branch. :-)
I made some fix. The right commit is the last 0001-VSE-implement-sequence-translation-in-sequencer-prev.patch.
I don't have edit rights to remove (or deprecate or whatever) previous patches unfortunately. Sorry for the long list of old patches. :-)