traverso-devel
[Top][All Lists]
Advanced

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

Re: [Traverso-devel] AudioClip Grouping, how to deal with them


From: Reinhard Amersberger
Subject: Re: [Traverso-devel] AudioClip Grouping, how to deal with them
Date: Tue, 19 Feb 2008 10:55:50 +0100

> -----Ursprüngliche Nachricht-----
> Von: address@hidden
> Gesendet: 19.02.08 10:11:52
> An: address@hidden
> Betreff: Re: [Traverso-devel] AudioClip Grouping, how to deal with them


> 
> Hi Nicola,
> 
> > > In Traverso this was possible before by using < S > on a clip to add it
> > > to a Group, and some more actions are available to remove it from the
> > > Group, invert the Group, add/remove all Clips to the Group etc.
> >
> > I think a selection of several clips should not be the same as a 'group'. I
> > would expect the same behavour as for example in a drawing program:
> > - select several items in a volatile group, as it is usually done by
> > holding the CTRL key. The selection is cleared as soon as something else is
> > selected. - declare permanent groups, which have to be 'ungrouped'
> > explicitly. As soon as a member of the group is (soft-!) selected, all
> > members are (soft) selected, too.

hhmmm ... maybe we better should use the term "hard-selection" instead of 
"groups", since the soft-selection works implicitly and the hard-selection 
works explicitly, but temporary, right?
"groups" might be a different behaviour as described by Nicola, where it should 
be possible to group and un-group a hard-selection...

btw - actually you are just talking about hard-selecting clips...but I also 
think about hard-selecting nodes, maybe fades and other things too, to drag 
them simultaneous... ;)

> 
> Hmyeah, but basically the behavior on a 'selected group of clips' or a 'group 
> of clips that is permanent' is the same, right?
> The only difference that the first one is a 'temporary' selection, and the 
> second is permanent.
> In other words, from an implementation point of view a permanent group or a 
> selected group (temporary) is the same.
> 
> > > From a contextual point of view however, how do we look at an AudioClip
> > > Group? E.g. when pointing to an AudioClip that is part of a Group, and
> > > opening the context menu with < Q >, what are you expecting to see?
> >
> > [...]
> >
> > > * Or just AudioClip, and somehow hope that 'some' or 'all' of the
> > > AudioClip actions like Drag [ D ], Remove << R >> and Gain [ G ]
> > > implicitly are applied to all Clips in the Group?
> >
> > Since it should be possible to apply all actions of a clip also to a group
> > or selection of multiple clips, I would say this would be the way to do it.
> 
> To be able to apply _all_ clip actions to a ClipGroup... Moving, Gain, 
> Normalize and stuff, that's not a big deal... But what about Fades? Plugins? 
> Curves? Setting a name, Split ( < X > I mean)....

yep, _all_ actions should affect the hard-selection/group.
when a user want to do individual actions they has to un-group, so the 
group/un-group action should be easy to perform ;)

> 
> > Maybe a new "group" context menu showing "create group" (= make a permanent
> > group of a selection of multiple clips) and "ungroup" will be necessary.
> 
> Yes, that would be very handy feature, like in 'glue clips'. Important you 
> mention this, as it is very important from an implementation pov. 
> E.g. what happens if you select clips, and one of the clips is member of a 
> Group? 

hhmmm...the whole group, where the clip is a member of, should be selected, 
right?

> The 'selection' which is a Group itself now operates on clips with one 
> clip member of a ClipGroup, and we do << R >> (remove).
> Now what is supposed to happen?

remove the complete hard-selection...

> And more importantly, how do we design the AudioClipGroup logic to deal with 
> it :)

ups, sorry, can't help you due to still lack of coding skill :( , so that's up 
to you ;)

> 
> > > And up to what I've in mind to do with the S key:
> > >
> > > S actions are NOT un/redoable (they are now, hence the mess)
> > >
> > > < S >             : Add / Remove pointed Clip to/from the Group
> > > << S >>           : Add / Remove all Clips to/from the Group
> > > [ S ]                     : Start a jog-create-group to create a Group.
> > > [ S ] + F         : Add next Clip right from the Group to the Group
> > > [ S ] + A         : Add previous Clip left from the Group to the Group
> > > [ S ] + rightarrow        : Add all Clips right from the cursor to the 
> > > Group
> > > [ S ] + leftarrow : Add all Clips left from the cursor to the Group
> > > [ S ] + downarrow : Extend group with all clips from track below the
> > > selection area spanned by the selections range
> > > [ S ] + uparrow           : Extend group with all clips from track above 
> > > the
> > > selection area spanned by the selections range
> 
> Do you guys agree with the proposed behavior and key actions?

yeah, cool - I like it.
Just one typo?
Shouldn't ...
[ S ] + F               : Add next Clip right from the Group to the Group
be...
[ S ] + D               : Add next Clip right from the Group to the Group
???

> 
> > > * Splitting an AudioClip Group: now we have 2 Groups? Do we need to be
> > > able to create multiple AudioClip Groups at a given time?
> >
> > Not sure what you mean by splitting a group. 
> 
> < X > on a Group. (either permanent or temporary)
> 
> > But with the permanent groups 
> > it should of course be possible to select several groups, merge them into
> > one permanent group, etc.
> 
> Yes.
> 
> >
> > > * Locked Clip: currently if one Clip is locked, the whole Group is locked
> > > (won't move).
> >
> > That's what I would expect.
> 
> OK
> 
> > I hope what I suggest is not overkill... ;-)
> 
> Not at all, I'd actually like much more! :D
> 
> 
> My current idea is to let AudioClipGroup inherit AudioClip, and make all the 
> functions that deal with setting gain, normalize, name, getting length, start 
> location and so on virtual.
> That way it's possible to provide the Command classes MoveClip, Gain, 
> MoveEdge, SplitClip etc. with either a 'real' AudioClip' object, or an 
> AudioClipGroup object. In the first case AudioClip will do it's work as 
> expected, in the second case, the re-implemented functions of AudioClip in 
> AudioClipGroup will deal with the 'multiple clips' logic, and dispatch the 
> action in a proper way to all the clips in the group.
> 
> What this means is that once a Clip is in a Group, there is _no_ way to 
> dispatch actions to it, the action will always dispatch to the whole group.

yep, this makes sense to me.

btw - really cool stuff ;)

greetings
reinhard

> 
> Greetz,
> 
> Remon
> 
> 
> _______________________________________________
> Traverso-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/traverso-devel
> 






reply via email to

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