traverso-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Traverso-devel] Projects / Songs


From: Nicola Doebelin
Subject: [Traverso-devel] Projects / Songs
Date: Mon, 16 Oct 2006 23:12:51 +0200
User-agent: KMail/1.9.3

Hi Remon,

Am Freitag, 13. Oktober 2006 23:29 schrieb Remon Sijrier:
> >> 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?

I'm beginning to realize what bugs me with the current implementation. Suppose 
I'm recording several songs for a CD. I would create a new project with 1 
song and start recording and mixing. For the next song I would add a new song 
to the same project, record and mix it, add another song and so on. When 
working on song no. 10, am I loading 10 songs each time I open the project? 
Since recording and mixing a song takes at least several days, I would not be 
interested in the other songs while working on song 10, but still I would 
load them every time.

The implementation should be more transparent, and a song manager widget, as 
you plan to add, is the first step in the right direction. Here's my idea on 
how to make the implementation a bit more intuitive (IMO):

- all songs of a project should be listed in the song manager, but they should 
not be loaded unless the user explicitly does so. (Think of it as 
the "File -> Recent documents" menu in many other programs.)

- It should be very obvious from the song manager which songs are loaded. And 
it should also be possible to close a song.

- When a project is loaded, it should either load no song, or restore the last 
setup. (Could be an option in the preferences.)

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

The songs could be rendered and inserted as clips into a new song. After some 
fine adjustment one could export the arrangement for cdrdao. 

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

It sounds weird indeed. The only example that comes to my mind at the moment 
is Lightwave3d. The pan/zoom/translate functions work exactly as described 
above, and it can happen that you have to re-position the mouse. But still I 
find the function very intuitive.

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

Sure, <space> was just an example that is easily reached from all keys.

Cheers,
Nic




reply via email to

[Prev in Thread] Current Thread [Next in Thread]