Sorry for having so many wishes, but Christmas is approaching *g*
Anyway, due to the fact that video and audio events of one media file are not intrinsically linked to each other, but mutually independent (a concept that I personally favour as well), such events should nearly always be grouped together. Consequently, the GUI actually does so automatically. But it makes a lot of sense to group events for other purposes as well (like "freezing" certain event compositions for later moving around).
Unfortunately, if you group groups together, the interior group structure is lost and the group consists of the events the original groups consisted of, in a flat way. So, if you group together several clips you originally moved to the timeline (each consisting of one video and one audio event, actually seperate groups of "twin-events") , and later on "ungroup" this group again, you loose the original video-to-audio-event-binding, as you don't get back the original groups, but the separate events on the timeline.
The most consequent approach out of this problem would be to actually implement nested grouping (hierarchy instead of a flat structure). Of course this might be a complex extension (prevention of loops etc).
Another solution, less elegant but also useful, would be to memorize the original video-to-audio-event-linkage (the "twins") separatly, resulting in an additional internal data structure that is not directly accessible/modifiable by the user (unless maybe in scripts). Events only become "twins" if they are created together out of the same mediapool/explorer element (pointing to a file on disk), or if they are created by copying other twins. The user could use this twin-structures in several ways:
- projectwise grouping together of all twins of an event
- synchronize twins (movethem to same timecode and/or adjust lengths)
- re-create missing twins (=mediastreams of teh corresponding file), for example after removal of just the audio part
Of course using Takes somehow interferes with the concept. Either the linkage I mentioned should refer only to one take, and the active take of an event decides about the events binding, or - what I would do - stick the twin-property to the event itself. If you later on add several takes, the original linkage of the event remains unaffected, and it is the responsibility of the user not to mess with it.
Whatever mechanism is used, I would welcome it... and of course I'd also wish access to these structures (nested grouping, media file linkage) from within scripts.
Thanks, dust
Anyway, due to the fact that video and audio events of one media file are not intrinsically linked to each other, but mutually independent (a concept that I personally favour as well), such events should nearly always be grouped together. Consequently, the GUI actually does so automatically. But it makes a lot of sense to group events for other purposes as well (like "freezing" certain event compositions for later moving around).
Unfortunately, if you group groups together, the interior group structure is lost and the group consists of the events the original groups consisted of, in a flat way. So, if you group together several clips you originally moved to the timeline (each consisting of one video and one audio event, actually seperate groups of "twin-events") , and later on "ungroup" this group again, you loose the original video-to-audio-event-binding, as you don't get back the original groups, but the separate events on the timeline.
The most consequent approach out of this problem would be to actually implement nested grouping (hierarchy instead of a flat structure). Of course this might be a complex extension (prevention of loops etc).
Another solution, less elegant but also useful, would be to memorize the original video-to-audio-event-linkage (the "twins") separatly, resulting in an additional internal data structure that is not directly accessible/modifiable by the user (unless maybe in scripts). Events only become "twins" if they are created together out of the same mediapool/explorer element (pointing to a file on disk), or if they are created by copying other twins. The user could use this twin-structures in several ways:
- projectwise grouping together of all twins of an event
- synchronize twins (movethem to same timecode and/or adjust lengths)
- re-create missing twins (=mediastreams of teh corresponding file), for example after removal of just the audio part
Of course using Takes somehow interferes with the concept. Either the linkage I mentioned should refer only to one take, and the active take of an event decides about the events binding, or - what I would do - stick the twin-property to the event itself. If you later on add several takes, the original linkage of the event remains unaffected, and it is the responsibility of the user not to mess with it.
Whatever mechanism is used, I would welcome it... and of course I'd also wish access to these structures (nested grouping, media file linkage) from within scripts.
Thanks, dust