Hi Nic,
I played a bit with the current CVS version, and I was a bit surprised how
many small glitches I suddenly found. Most of them are also found in the
0.40.0 release. I tested with the patched official 4.3.0 release of Qt
(except the first point) on Kubuntu feisty. It's mainly about inconsistent /
not intuitive behaviour:
OK
- Compiled with official Ubuntu Qt 4.2.3 packages: H-Scrollbar / Shuttle
doesn't work. I thought this was introduced with
4.3.0, but you can test it
with my Ubuntu binary, which was compiled with 4.2.3. Scrolling doesn't work
here with that one, either.
Works beautifull here, with both qt versions, and on linux/windows!
- Compiled with patched official 4.3.0 release: When zooming in horizontally,
the timeline suddenly disappears
Never seen before, sorry!
(It almost sounds like if you have a partial 0.40.x, and some old cruft that makes up the binary! Both issues have been there, either due a Qt bug or a limitation to the paiting framework in Qt, solved long time ago..)
- It is confusing how the different cursors work. E.g. when playing, zooming
centers on the playhead. When not playing, zooming centers on the work
cursor. I also have difficulties seeing what the work cursor is actually for?
Is there anything that couldn't be done with either the mouse cursor (as in
<X> for splitting clips) or the play head?
Well, if you would zoom on the position of the mouse cursor, the work cursor indeed is less usefull.....
Perhaps it's more intuitive to zoom to the position of the mouse cursor if not playing, and to the playhead when playing ?
- We should add an option to make the playhead jump back to the work cursor
when transport is stopped. (Or to it's last start position.)
Yeah, hmm, so in that case, it makes sense to keep the workcursor ? :D
But there is < V > to jump back to the last play position... I guess it depends on the type of work which of the 2 is preferable, either jump back to the last position after play stop, or as in 'pause here' ....
- Fades: The default values of "strength" and "bending" should be set to > 0,
otherwise switching mode <M> doesn't have an obvious effect, because if
strength == bending == 0, all shapes are linear.
OK ( ?)
- It should be possible to set a default shape (Mode, Bending, Strength) for
fade-ins and -outs individually in the settings dialog. (I for one use "long"
fades 99% of the time.)
Ah, had to read that twice, but yes, sounds usefull indeed.
Or to avoid massive amounts of config options, default to long fade, since that's what most users will use anyway ?
- When changing the length of a fade, a tooltip should display the value
(length), as when moving clips or markers.
Yes, I've also been thinking about showing the actual mode and perhaps bend/strenght value when changing the bend/strength value. RFC please!
(show them in a similar tooltip above the fade)
- IMO the transition from "Song" to "Sheet" is only half-way done. In many
places the option "do something with the current sheet" or "... all sheets"
doesn't make sense anymore. (That's my opinion, YMMV of course.)
Which places ?
- A tricky one: I often have a short fade-in at the beginning of a clip (to
smoothly fade in the background noise of a live concert before the music
starts, about 0.5 seconds length). At the same edge of the clip I usually add
a CD-marker. Since I want to have the marker exactly at the clip edge,
hitting <M> to add it sometimes accidentally changes the mode of the fade,
which is done by <M> as well. To make sure I don't change the mode, I have to
add the marker somewhere else, away from the fade, and move it to the edge of
the clip. This is not an elegant solution.
1) Point the mouse to the timeline ??
2) Create a new keyfact that's more unique, like < NM >, or CTRL+ M or something like that.
I would like to hear your opinion to the points above. Overloaded key actions,
as in the last point, will definitely become more important the more
functionality traverso has.
It's all your choice! That's what the keymap is for, so if certain actions need more powerfull and unique keyfacts, you should create them!
One solution could be to have modifier keys,
which bind the action to a certain layer. E.g. [SHIFT] + <K> always binds the
<K> action to the song, [CTRL] + <K> to the nearest clip, [ALT] + <K> to the
track etc. In the manual we mention that with the contextual key actions it
is not necessary to click on small buttons. But if we have a very narrow clip
snipplet or a short fade, it can be even harder to hit than a button.
What's the difference with a non contextual way of working ? I mean, if the clip is very small, there is no way to manipulate it, also in other programs!
Could you show me some kind of action that in other programs can be done with a button that applies to some clip in the clipview ?
About the ''binding a modifier key to a layer", I need to think about that one, it's obviously possible, but less in the spirit of contextual working....
And there aren't that many modifier keys after all....
If we
could bind an action to a certain level, we wouldn't have to actually hover
over the object. Just make sure the fade or clip you want to process is the
*nearest* to the mouse cursor.
It works like this allready actually! Nearby detection, which is used for both markers and curve nodes....
Also, how would you know which _clip_ would be the nearest ? A similar approach for clips (nearby detection) should have to be created then, but things like mute, gain, move won't work anymore, unless you indeed 'select' the active layer...
But then again, how many layers are possible ?
What do you think of these suggestions?
Hmm, well, I'm surpised you only find these issues now :D
Regarding the layered thing, it would be helpfull to create a set of examples, see how other applications deal with it, and ehm, you actually can create a custom keymap right now which binds certain actions to modifier keys, and see how it works out!
The best way to detect if something works is to try it out....
And can you confirm the problems with
the timeline in Qt 4.3.0?
Works fine here
I would also like to suggest to sort these things out in a 0.41.0 release
(after 0.40.1 Remon is preparing ATM) before we start adding new features for
0.50.0.
Sure, I'm looking forward to your experiences with layered keybindings!
Greetings,
Remon