Re: [Traverso-devel] Some glitches with 0.40.0

[Nicola Döbelin]

On Friday 22 June 2007 22.06:32 Remon Sijrier wrote:
> > - 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!

Ah, got that one: I had to disable the manually compiled 4.3.0 in the linker 
configuration completely. Just compiling and linking against 4.2.3 wasn't 
enough.

> > - Compiled with patched official 4.3.0 release: When zooming in
> > horizontally,
> > the timeline suddenly disappears
>
> Never seen before, sorry!

Probably also related to mixed 4.2.3 / 4.3.0. Can't test though, because 
uninstalling 4.2.3 would uninstall a whole bunch of other stuff, too.

> > - 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 ?

I think it is important to always zoom to the same element. I don't know which 
one is the best, but it should be consistent in all situations.

> > - 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' ....

I prefer the first one, but I can imagine that other users prefer the "pause" 
mode. That's why making it configurable seems like a good solution to me.

> > - 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 ?

The long mode is definitely the most useful for me, so at least for me this 
solution would be ok.

> > - 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)

Yes, I think that would be good. A tool tip next to the mouse cursor, showing 
whatever value is changed.

> > - 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 ?

I'm thinking of the export and cd burn dialog, and the "sheet selection" combo 
box in the marker dialog. (There's no point in showing the markers of a sheet 
other than the active one.) Also when creating a new project, it doesn't make 
sense to create more than 1 empty sheet, at least for the way I intend to use 
them.

> > - 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 ??

Sure, but the point was not that I'm not able to place a marker, but that I 
accidentally switched the mode of the fade without noticing it. I realised 
that no marker was added, and hit <M> again, but I didn't see the fade shape 
change because it was too narrow. So I messed things up without even 
noticing.

[...]

> 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 ?

In Samplitude I can select a small clip with a rubber band, and call many 
functions from the "Object" menu in the menu bar, even if the clip is only 1 
or 2 pixels wide.

[...]

> > What do you think of these suggestions?
>
> Hmm, well, I'm surpised you only find these issues now :D

Yeah, I couldn't really test before the 0.40.0 release, because the OS X port 
kept me busy.

> 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....

Ok, I'll give it a try. I have some more ideas related to key actions, but 
I'll think them out a bit more before getting on your nerves O:-)

Good night!
Nic