Re: [Traverso-devel] Fwd: Re: A small drag_clip / drag_edge implementation

[Remon]

Hi,

> > > For fun, I also added an HKEY2 entry for CTRL+LeftMouseButton to copy
> > > an AudioClip, since I'm used to using acid music, which allows this.
> >
> > Hmm, isn't that rather hard to perform ? You have to press them at the
> > (exact) same time....
> > Will try it out, and of course, you are free to add as much keyfacts to
> > the keymap as you like!
>
> You're right, it's not super easy.  Maybe there should be 2 new event
> types?  M_FKEY and M_HKEY?  For Modified Clicks and Modified Drags?
> Modified would mean key1 (the modifier) has to be pressed, and then
> key2 pressed while key1 is still down (but not necessarily at the same
> time, although that would have to work too).

Hmmm, well, the 'modifer key' concept allready is there, see for example [ G ] 
The menu for the modifier keys can be shown just like the other menus with 
the right mouse button, or < Q >

Using the CTRL key as start 'hold action', and dispatching the correct one 
when the modifier key has been activated... Not sure about that actually. 
It's at least an option that could work :)

The point is that just holding the CTRL key let's the input engine think it's 
a hold type of action..... And then it wants to dispatch it!
So, a M_FKEY type of actions would be hard to implement from a Input Engine 
pov.

Note that modifier keys for hold actions are directly delegated by the 
inputengine to the holdcommand after first keypress, so no < K > or [ K ] 
type of actions possible.
The lovely thing is that autorepeat _does_ work for the modifier keys, which 
you can see in action for up/down arrow for [ G ]

> Ooo! Then the cursor shape to show could be chosen based on what
> commands the keymap defines for the currently hovered object, given
> the currently held modifier if any.  Cool...

Yeah, there is the LRUD (Left, Right, Up and Down) hint, but you can also use 
the ViewPort's hold cursor to show information in an advanced way. ( by 
re-implementing the set_cursor_shape() in your hold command)

> > (Just popping into my mind, if you use the Plugin method, you could set
> > the 'edge width' as parameter in the arguments attribute! like
> > arguments="true;4" , just an idea... hmm, well, it's really just that
> > hehe)
>
> Ah, good point.  That would be way cooler.  :)  I'll convert it, and
> add a bug/patch.
>
> So, here's a question: Which command slots should be in the
> AudioClipView, etc. and which should be in the plugin?  Should they
> all be migrated to the plugin?

The idea is that one either uses a slot to create the Command object in, and 
return that to the InputEngine, or the request is send to the plugin you gave 
as parameter in the keymap, and the Plugin will create the Command object and 
return it to the InputEnigne.
Depending on the type of action, if is historable or not, one will create a 
Command class for a certain action or not.
If no Command class is needed, a slot is added to the object you want to 
dispatch the action on, do the stuff there, and return 0.

My idea is to move as much Commands into the Plugin as possible, based on the 
concept that:
Core objects should be used to abstract their data, and provide an api to get 
and modify that data
View objects should have all the function to properly reflect that data, with 
some convenience functions for other ViewItems or Command classes to retrieve 
information to perform some kind of layout, or moving the item, or.....

This way, the core and view classes are kept very clean, and one quickly 
detects what is common for multiple objects, so only one Command class is 
needed to perform some action on mulitple objects transparently!
(Gain is a good example, and CopyClip too, since it's merged now with 
MoveClip)

With this strategy, a clean core and canvas library is made, and it will be 
only a matter of adding new Command classes to the plugin.

Example:
I've been thinking on adding a DragWorkCursor command, just like the 
PlayHeadMove, which still is located in SongView.cpp)
Now, say, I don't have access to the canvas code to add a slot to return this 
Command from.... But no problem, I just add it to my plugin as a Command 
class (since I have to make the command class anyways)
So, say, [ SHIFT ] becomes the move work cursor keyfact. I apply it to the 
SongView, ask the workcursor from it in my command constructor, and start 
setting the new position of the work cursor in the jog() function....
Simple, clean, no need to mess with SongView code at all!

Now, if the plugin grows and grows, it's easily possible to split it into 
multiple plugins, and only load the one you need!
So, if certain actions won't be used by certain users, they can load a keymap 
that doesn't need Plugin X or Y, so the plugin won't be loaded!
Isn't it lovely? 
(this obviously is something for the future when there are much more Command 
classes....)


> > > I also want to make a command to drag the edge with the audio anchored
> > > to the edge that you're moving (so sort of combining moving the clip,
> > > while adjusting the opposite edge to keep it from moving in the scene.)
> >
> > (And if you don't mind a little more explanation, I don't get exactly
> > what you want to do...)
>
> So I was thinking that dragging an edge should move the edge the same
> way it works now, but dragging the edge with some modifier (shift?) or
> by using a new HKEY / HKEY2, could drag the edge while moving the
> audio along with it.  So if you dragged the left edge, the end result
> would be that the same frame of the audio would be the first frame
> that gets played of this clip, but it would start at a new location.
> Hmmm... I think this might be best explained through ASCII Art.  :)

Ah yeah, now I understand (thanks to the ASCII art hehe)

Well, there is the MoveEdge and MoveClip class. Not sure yet how they should 
co-operate to make this possible, but I think using both Command classes at 
the same time should make this possible ?

You can define a 'modifier' key for Command classes just like any other 
keyfact, see for an example how it works the Gain command class.

> I imagine that to do this, I should add a bool argument to the edge
> dragging command?  And then add a new slot to call the command in the
> non-default way?

Ah, I see. The MoveEdge is not in the Plugin right now. This would indeed be a 
nice way I think to make this possible.
MoveEdge constructor needs to be updated for this, and the code in 
AudioClipView::drag_edge() should be moved also into the constructor of 
MoveEdge.

Then it will be as easy as defining a new key fact for moving edge/clip, use 
the arguments to let the MoveEdge know what type of move is in order, and 
voila :-)


Hum, well, way to much talk lol.

CVS has been updated today, you can click now on the track panel 'led buttons'
For what's worth :D
Oh, and a small usability improvement for creating a new Project, you can now 
also set the amount of tracks for the to be created songs...

Greetings,

Remon