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

[Nicola Döbelin]

Hi Remon,

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

> Well, the Project -> Songs concept was allready there when I jumped on the
> then Protux bandwagon.
> I think it's mainly ease of use, one can do a project as he likes, be it 
> one 'song' at a time, or all songs for a CD into one project.
> 
> It's also faster and hopefully more userfriendly.....
> When you do a (live) recording, there is no need to (if I understand 
> correctly) for example like ardour open lot's of sessions.
> Just create for example one Song, set it up correctly and make it a
> 'template' 
> (needs to be implemented of course). Now  adding new Songs to your project
> with this template makes things much easier and faster, or did I miss 
> something?
> 
> It's also more integrated. You can mix stuff down in one Song, and record
> it 
> in another (don't know if it makes sense, but it's possible, at least in
> the 
> future it must be ;-) )

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

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

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

> Oh, and what about this nice little one:
> http://vt.shuis.tudelft.nl/~remon/uglyfonts/uitwerking18.png

Nice! The new interface is really flexible.

> > 1. Sounds trivial, but how about painting the background of audio clips
> > with a slight vertical gradient? It would look more 3D. You could use
> this
> > effect to mark selected clips by inverting the gradient and switching
> from
> > convex to concave appearance.
> 
> This one is knew for me, sounds good!
> 
> Actually, I'm thinking to change the Track background color to a very
> light 
> one. The AudioClip background will be either non existend, or transparent
> and 
> slightly darker then the Tracks background color to make it 'visible' and 
> distinguish it from the Track.
> The reason is quite simple. 
> 1. I don't like dark themes

Who uses dark themes anyway these days? O:-)

> 2. AudioClips which are upon eachother need very special painting code to
> make 
> the parts that collide transparent, else one clip gets behind the other
> one 
> and become invisible.
> If an AudioClip doesn't have a backround, or a light transparent one, 
> audioclips which collide keep visible...
> 3. PluginViews for one are transparent, but due this they are less visible
> on 
> dark backgrounds. When in Plugin 'viewmode' the idea is to make the 
> pluginviews brighter and less transparent as to place them more on the 
> foreground.
> 
> >
> > 2. If the colour of the clip/track beneath the cursor would change a
> bit,
> > the user would recognize that the object is 'active' without having to
> > select it. The optical effect should be very faint, though, so as not to
> > cause a lot of flicker when moving the cursor across the screen.
> 
> Of course, forgot about this one. Thanks for reminding!
> 
> >
> > 3. I'm not so fond of the fade dialog anymore. The dialog works nicely,
> but
> > I realized that it distracts my attention from the audio clip quite a
> bit.
> > I 'lose contact' to the audio, because what I usually do is modify the
> fade
> > curve, listen to the effect, change again, listen again etc., until I'm
> > satisfied. The fade dialog focuses too much on technical stuff like the
> > spline control points, numbers for bending, strength etc. I would prefer
> if
> > this stuff was hidden from the user and the fade would directly be
> > manipulated in the audio clip.
> >
> > What do you think about that?
> 
> 
> OHH NOOOOOOOO!
> 
> All the work we've done!
> 
> The fadedialog is more a proof of concept, it would make more sense for
> the 
> equalizer one?

I don't think the work we've done is obsolete now. I would just prefer to set 
all parameters directly in the audio clip. This applies for fades only, because 
they are very position sensitive. The parameters used to adjust fades are i) 
the end of the clip, ii) the length of the fade, and iii) the shape. Since two 
of these parameters are set on the audio clip, it doesn't make sense to open a 
dialog for the third one (shape related stuff) IMO.

Plugins (EQ etc.) are a different story, because they are not position 
sensitive. So dialogs are necessary for EQ, dynamics etc.

> Anyway, I had this idea last week.
> Merge the FadeDialog and FadeView into one, just like you suggest now. So
> you 
> can edit the fade on clip like you can do it in the fadedialog.
> However, you need a rather large area to work on, that is, you need to
> zoom 
> into the audioclip quite a lot, to make the jmb concept work for editing 
> fades.
> 
> What about this. You do < e > on a Fade, it 'zooms out' as a ViewItem,
> placed 
> below/besides/above the fadeview (depending on how much screen space there
> is)
> So you don't have another dialog, the 'modeless' design will work again,
> and 
> you can 'zoom into a specific viewitem' in the ViewPort.
> Of course with some nice animations hehe

Why would I need a large area to work on? As long as I hold the key I can leave 
the fade area with the mouse cursor without losing the action, can't I? What 
you suggest will probably lead to the same distraction as the current solution 
with a dialog. But since this is highly fade-specific, we should keep the 
'modeless' concept in mind for other applications, maybe the EQ dialog?

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.

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

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

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

Good / bad ideas?

Regards,
Nic


-- 
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl