[Traverso-devel] Re: audio clip selection behavior

[Peter Hoppe]

> Hello again,
And hello back! I haven't been very active on traverso dev recently, because I'm learning C++ at the moment and working 
on another KDE/C++ project that slipped in. It's a steep learning curve, but that's what I expected it to be.


> clip selection no longer is un/redoable
Very good idea. Actions that should be un/redoable are those that change the sound of the particular session, e.g. 
splicing a track, moving clips etc. Anything else would clutter up the undo buffer.

However, selection could be redone in conjunction with other undoing actions. For example, if the user moves a clip and 
then un-does the move, should we have the clip selected when it's back in it's original position?



> when removing a clip that is part of a selection, the whole selection is removed, and de-selected. 
This is what I as a user would expect when selecting and deleting. Take a text editor as example - if you select a text, 
wouldn't you expect that the selection gets removed when you hit the DEL key? In the same way I'd expect that Traverso 
deletes all my selected clips, not only the one beneath my cursor.

/However/, some users may find it useful if only clips under the cursor get deleted; it could be implemented as an 
option in the preferences. This option would be switched off by default, but could be enabled via check box. But this 
would be way down the priority list IMO, and it'd appear to be one of those off-the-wall ideas (probably also hard to 
implement).

> When un-doing the remove action, the selection is not restored, maybe it should 
> be ?
Generally, the undo feature promises to the user that a certain action is undone in such a way that the previous state 
is restored. So, when an entire selection got removed, as user I'd expect that the entire selection gets restored when 
undoing the removal. So, in my opinion, the entire selection should be restored (and maybe even selected).




> Keys used to select and de-select audio clips:
Here some radical, spoil-your week[end] ideas: How feasible would it be to model selection behaviour on the lines of 
what's already done in the file browsers in Windows (Explorer) and KDE (Konqueror)? It seems that other apps have taken 
this selection behaviour on as well - I think, Cool edit in its multitrack editor for example (except that they use the 
shift button for multiple clip selection). Generally, selection is one of the all-pervasive features, so to decorate it 
with special shortcuts seems somewhat strange to me (if I put my user's hat on). In particular, how feasible would it be 
 to implement the following features:

* Map "Select clip" to the left mouse button

* Offer a 'rubber band' selection method: user moves mouse to a point and then drags the mouse whilst holding the left 
mouse button. This then draws a rectangle and every clip tpouched by the rectangle gets selected.

* Map "Add clip to selection" to ctrl-leftMouseClick.

* Have a clip removed from a selection by ctrl-leftMouseClicking a selected 
clip.



> The idea is that 'hard selecting' clips always means we want to select more
> then one, to perform an action on multiple clips at the same time.
> This way selecting multiple clips can be done fast and without a worry to
> accidentally deselect the selection, which often happens in other software
> when clicking the mouse outside the to be clicked object's region, or when
> not holding the CTRL key firm enough :-)

I found that the CTRL key usually works fine (e.g. in Cool edit). The problem of a non-functioning CTRL key is located 
within user space, not within developer space (Oops, sorry, sounds too scientific :) ) I mean - the solution to the 
non-functioning CTRL-key isn't something we can do something about. Only the user can remedy it by aquiring another 
keyboard or pressing the CTRL key harder. Sounds unfriendly, but any other key could fail just as much as the CTRL key 
(e.g. the 's' key). One of the best keyboards I have has a non-functioning '1' key. I wouldn't dream of asking the app 
developers to develop a solution around that.

However, this brings me to the issue of mapping in general: The last time I changed some mapping I found that I had to 
recompile the application. Would it be possible to make this mapping customizable at runtime, i.e. as part of the 
preferences (We'd just offer some default mapping as part of the settings delivered with a Traverso installation)? I 
think it's better this way, because often users have their own key combinations to do something. It would be more user 
friendly.




Just some ideas, hope they haven't spoiled your next week! Thanks again for all 
your work and have a good 2009!

P