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

[Remon]

Hi Reinhard,

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

The whole idea of 'selecting' objects is to dispatch actions to all of the 
members of the selection. So if you prefer to the name Selection (all 
selected clips) over Group (all clips in the selection), sure. It's just a 
name.
But: no matter if the selected clips are made a Grouped one or not, the 
dispatching one action to a member of the group dispatches it to the whole 
group.

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

As long as it makes sense, sure!

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

Yes, makes sense.

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

Yes, I think so. I asked due it imposes a challenge for the implementation. 
The current 'hard selected' clips can contain both 'singular clips' and 'a 
clipgroup' in this scenario....

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

OK

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

No no, not really! I'm not thinking in code, perhaps pseudo-code. I'm thinking 
in ways of getting the 'big picture' of singular items vs items in a group 
that have the same nature of a singular item.
What right now is most important is to make clear what the preferred options 
and behavior are. Translating that into code is the simple part :)

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

OK, nice!

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

Yes, horrible typo, thanks for catching it :)

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

OK.

> btw - really cool stuff ;)

Yes, rather exciting indeed! And challenging, a wrong design decision can hurt 
badly in future developments!


Greetings,

Remon