[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Traverso-devel] Re: audio clip selection behavior
From: |
Peter Hoppe |
Subject: |
[Traverso-devel] Re: audio clip selection behavior |
Date: |
Sun, 18 Jan 2009 21:53:34 +0000 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20090105) |
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
- [Traverso-devel] Re: audio clip selection behavior,
Peter Hoppe <=
- Re: [Traverso-devel] Re: audio clip selection behavior, Remon Sijrier, 2009/01/19
- Re: [Traverso-devel] Re: audio clip selection behavior, ben levitt, 2009/01/20
- Re: [Traverso-devel] Re: audio clip selection behavior, Remon Sijrier, 2009/01/21
- Re: [Traverso-devel] Re: audio clip selection behavior, ben levitt, 2009/01/21
- Re: [Traverso-devel] Re: audio clip selection behavior, Remon Sijrier, 2009/01/21
- Re: [Traverso-devel] Re: audio clip selection behavior, ben levitt, 2009/01/22
- Re: [Traverso-devel] Re: audio clip selection behavior, Remon Sijrier, 2009/01/22
- Re: [Traverso-devel] Re: audio clip selection behavior, ben levitt, 2009/01/22