Re: [Traverso-devel] Re: Hi Nicola ;-)

[Remon Sijrier]

Hi Nicola,

> (Moved the discussion to the mailing list, as it is getting technical
> again ;-)

Nice, thanks. It indeed became quickly a technical conversation, bad
habbit, sorry hehe.

>> Well, the Project -> Songs concept was allready there when I jumped on

<snip>

> When you say there are advantages in such a concept, I believe you of
> course.

Well, I'm not entirely sure, but I also don't see a good reason why it not
should work?
You could think of the concept as a MDI (multiple document interface) but
with just one type of document.
All the information 'views' and windows display information and are
relevant for the current displayed song, like if it is a workspace.
Although you say, you see a Song as your project, since they don't have
shared information, if your 'project'is about creating a CD, they do have
at least one thing in common, right?
Just thinking loud here ...

>
>> Rendering a CD can be done from Project level, no need to do it by
>> 'importing'
>> multiple 'session's' on a timeline or something like that....
>
> Here I disagree. CDs have to be compiled carefully, e.g. by adjusting
> silence between two tracks in order to let the listener 'take a breath'
> before the next song starts. Or when mixing live concerts I often use
> cross fades between two tracks, to blend the background / audience noise
> of the previous track into the next track without a gap in between.

Sure, good point. I was more refering to the fact that it's less
userfriendly to first render your 'songs' to some location, and for the
'creating cd' step, you have to import those rendered songs again. Or
doesn't that make sense?
Using the Project -> Songs concept, it should be easier to create a 'CD
arrangement mode', which automates the job for you as much as possible?
Like for example, you can give each Song a 'CD track number, name etc'
Ideally, the whole thing then can be rendered into an iso image at once ;-P
Nah, it's quicker to render the songs, and create a ehm, not sure how it
is called, queue sheet, toc or something for k3b, cdrdao or whatever
program accepts those.

>
> A CD-arrangement-mode should not interfere with the current concept of a
> Project/Song hierarchy, and I think implementation would be easy. How
> about adding this point right on top of the TODO-list for version 0.50.0
> ;-) ? (The reason for me pushing this feature a bit is that it's one of
> the basic functions I use in almost every project.)

Definately, let's came back to this asap, that is after 0.40.0 :-)
We need to think out a 'cd arrangement mode'like you say, and how it would
work the most easy, convenient and flexible way.

>> Oh, and what about this nice little one:
>> http://vt.shuis.tudelft.nl/~remon/uglyfonts/uitwerking18.png
>
> Nice! The new interface is really flexible.

Yeah, at least the green look is gone, wanted to do that for a long long
time.
Apart from that, it's mostly about moving the views into dockwidgets,
which you can show/hide/arrange as you like.

>> 1. I don't like dark themes
>
> Who uses dark themes anyway these days? O:-)

Haha


> Anyway, take my suggestions with a grain of salt, since I think you have a
> better feeling for user-friendliness than I have. I'm usually impressed
> with the solutions you come up with.

Well, it's just that if it feels 'natural' and is easy to use, I go for it!
Sometimes you just have to try, like the Fade Dialog and accept it's a fun
thing, but sub-optimal.
It's very important you say this, wether or not a lot of work was put into
it. If something didn't work the way I or you thought, bad luck, then we
try something different :-)
And your view is as good as mine, different people have different ways to
work, so if it works for me doesn't mean it's the optimal way to work for
you....

>
> Two more things for the long TODO list:
>
> 1. I still think it would be useful to distinguish between 'move actions'
> (e.g. dragging clips, clip ends, fade lengths), which work as usual, and
> 'value change actions' (e.g. gain, bending of fades). For the latter, the
> motion of the mouse should change the value, but the cursor should not
> move. This has the advantage of not colliding with the border of the
> screen (which forces you to go back to the clip and restart the action),
> and the mouse would still be positioned on the clip after the action. From
> the ergonomics point of view your attention would always be focused on the
> clip rather than follow the mouse, particularly when the action has
> finished and the mouse pointer is somewhere at the top of the screen and
> you first have to 're-orient'.

Hmmmm.
On the one hand, you have a point. There is however a problem with this
aproach, and that's the reach of the 'real' mouse.
Take for example the 'gain' action, if you move the gain value up, you
move the physical mouse also upwards.
After you finish that action, the mouse cursor gets it's normal shape
back, and you can start another action on the audioclip without moving the
mouse, thats your idea, right?
However, the physical mouse is still far away from you, so to make it
usable again for your right hand, you have to move it 'downwards' to
retain 'center' position.
The effect is that the mouse cursor goes downward, and could position
itself quite a distance 'below' the audioclip you just edited, _unless_
you drag the physical mouse from your desktop, so the mouse cursor doesn't
move, and place it into a comfortable position again for your right
hand.....
Now, thats not a friendly thing imho...?


> 2. Numerical input: Sometimes it would be useful to be able to enter
> values numerically. So how about the following:

Yes, there is a feature, 'number collection' which has been forgotten a
bit, but it still works.
For example, if you have loaded 2 songs, and you're in song 1, enter 2 on
the numerical pad, and < S > (don't do it when the mouse is upon a Clip of
course)
You will now switch to Song 2.
Perhaps, it can be used too for numerical input to set for example gain
values...?

Like:
n.. < G >

Reads as "input some number, then press G"
Of course, the current number that is 'collected' should be displayed
somewhere.

> Suppose you want to set the gain of a clip to exactly +3 dB. You would
> press [g] as usual, but instead of moving the mouse, press <space> while
> holding [g]. A lineEdit would open, you would enter '3' and <enter>. This
> should work for any numerical parameter, so it should be implemented
> 'globally'.

Hmm, see explanation before, thats another way to do it.
This one makes sense too, though maybe not with the <space> one, don't
know. I would prefer using the <enter>
But some day this will be configurable, so you can choose the way you like
it :-)

(Since you have to move your right hand, to the numerical pad, it perhaps
makes more sense to use the <enter> then the <space>, at least thats my
reasoning about it. Or you just start typing on the numerical pad, which
'triggers' the lineedit, combox, other...)


> Good / bad ideas?

Nice ideas, let's see if it works in practice too!


Thanks and have a good evening,

Remon