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

[Nicola Döbelin]

Hi Remon,

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

Yes.

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

Fades, Plugins: Yes, apply to all clips in the selection. If that behaviour is 
not desired, the user is not supposed to use a group or selection of several 
clips.

Curves: That one might need special treatment if applied to a group. But on the 
other hand, if the user selects multiple clips and then adds a curve node, what 
behaviour does he expect? 

Setting a name: One could argue about that, but again I think if someone 
selects several clips and changes the name, he WANTS the command to be applied 
to all selected clips.

Split: All clips should be split at the absolute position of the command. If 
the position is outside the clip, ignore it, else apply it.

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

Hmmm, some kind of hirarchical syste, where each AudioClipGroup can contain 
several AudioClips and/or AudioClipGroups and forwards whatever command it 
receives to whatever child members it has. But I'm not the right person to give 
advice here...

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

Generally yes, but I see some potential for confusion in multitrack projects. 
E.g. when you do [S] + <F>, but the next clip is on another track somewhere 
off-screen. If you zoomed to tracks 1-8, but you select clips on tracks 9-24 
without noticing, you may cause a horrible mess.

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

As mentioned above: Cut all clips that cross the absolute position of the cut. 
Add the fragments to whatever group they were in before the cut. But if a clip 
is NOT a member of some group, do NOT create a new group for the fragments. It 
should be possible to cut a single clip, and immediately drag away or delete 
one of the fragments without having to de-select something.

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

I don't really understand this, but it sounds reasonable :-P

Nic

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger