Splitting from scripts that works like "S" (only 5.0b)

dust wrote on 7/7/2004, 7:33 AM
I played with 5.0b's grouping support, and it seems to work flawlessly so far, which is great!!

One thing that has to be noted now though is that the Split-method of the API doesn't work like "S" (split command from keyboard) because it puts all events into only one group. This can now be handled better and because there are a few critical points about it, I thought it might be interesting to post the function I wrote here (I didn't check this against syntax errors, as it looks slightly different in the script I originally wrote - take it as a template). The function takes an event and a timecode as input and then splits all events grouped with the original event at this location; the "left" and "right" halves will end in their own groups:


...
import System.Collections;
...
function doSplit(evnt:TrackEvent, tc:Timecode)
{

var group : TrackEventGroup = new TrackEventGroup();
Vegas.Project.Groups.Add(group);

var evntsToSplit = new Queue();
if (evnt.IsGrouped)
for (var e in evnt.Group)
{
if (e.Start < tc && tc < e.Start+e.Length)
evntsToSplit.Enqueue(e);
}
else evntsToSplit.Enqueue(evnt);

for (var toSplit in evntsToSplit)
group.Add(toSplit.Split(tc - toSplit.Start));
}
...


One bug I originally had and you should be careful about is that if an event e is not grouped, e.Group will be empty. But of course an event is inherently always "grouped with itself". This is why I had to take care of the case that e.IsGrouped is false above.

One thing I miss is the ability to compare 2 groups. I didn't find a way... for example, if you want to find out if 2 events e1 and e2 are grouped, you can't say "e1.Group == e2.Group", this will always be false (as is the case with tracks). Something like "e1.Group.Index == e2.Group.Index" would work - if Group had an Index property (like Track does - you can compare tracks by comparing their indexes). The only way I found is using a function that returns a group index for an event, like (returning -1 for isolated events):


...
function getGroup(e:TrackEvent): int
{
if (!e.IsGrouped) return -1;
for (var gr = 0; gr < Vegas.Project.Groups.Count; gr++)
{
for (var e2 in Vegas.Project.Groups[gr])
{
if (e2.Track.Index == e.Track.Index && e2.Index == e.Index)
return (gr);
}
}
return -1;
}
...


...and then compare the 2 events getGroup(e)-results.

So, to find out if an event is inside a given group, I must compare it to all events of this group. To make it worse, you can only compare 2 events by comparing their track indices and their event-indices-within-this-track. This is quite tedious for something where a simple
if (grp.Index == e.Group.Index)
would suffice. Or did I oversee something simple..?

Comments

jetdv wrote on 7/7/2004, 9:12 AM
Surround the code in
 
(changing [ to < and ] to >) to get better formatting.
SonyPJM wrote on 7/7/2004, 11:03 AM

You point out why grouping is kind of a problem... when should
operations effect a single event vs. its entire group. For now, we
operate on a single object in the scripting API and with the exposure
of groups at least there's a way for a script to extend an operation
to the whole group when desired.

But, as you point out, there are still plenty of rough edges.

I'll try to override the IsEqual and GetHashCode methods of tracks,
events, groups, etc. in a future release so that regular "=="
comparisons between objects will work as expected. It also would be
nice to implement IComparable when it makes sense so objects can be
easily sorted.
dust wrote on 7/7/2004, 11:43 AM
Well, don't get me wrong, I'm happy about the new group access which I consider as big improvement in scripting! Yes, you're right, it's not easy to decide if actions should take place on a single event or a whole group, and if latter, in what way (for example if the events in a group are not below-each-other). I think part of the problem is that grouping is a tool that's used for 2 completely different purposes: knowing what streams "belong together" (verically, video-audio-lock), and structuring events "horizontally" in the time space, allowing to keep different clips together. I think it is a basic design bug to use just one tool for both purposes, as these are of completely different nature (horizontally vs vertically, stream space vs time space). Horizontal grouping would also make hierarchical groups useful, while they are of no interest in vertical grouping. The way grouping is implemented in Vegas, it is mainly for vertical grouping. Horizontal grouping would make tools like track-nesting or what I tried with ProxyEvents.js more useful.

Well, all I have in mind can somehow be done with the interface as it is now (would be nice if rippling modes could somehow be read from a script to adapt the script behaviour automatically to it, but that's more a nice-to-have). If we had direct read access to TrackEventGroup.myGroupID, it would make things much easier though (if I interpret myGroupID correctly - looks as if it is an integer unique to each group). Then we'd not need to compare all events of a group with each other just to see if 2 TrackEventGroup objects refer to the same group. Unfortunately this property is internal :-(

@jetdv: Thanks for the [pre] stuff, works great - I already edited my posting! :-)