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

[Remon]

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.

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

> 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? 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?
And more importantly, how do we design the AudioClipGroup logic to deal with 
it :)

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

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

Greetz,

Remon