Groups Exceeding Screen Height Bug

I'm working on a longform narrative project where I've had to use a large amount of groups. The list is now taller than the screen height and while the UI shows a triangle scroll down at the bottom of the page, it doesn't scroll and I can't access the rest of the saved groups. This seemed to also exist in R11 as well. Does anyone know of a workaround to access these extra groups? Can this be added to a bug fix list?

Cheers

My workaround: use fewer groups. (Not being sarcastic.) I've done whole features with 6 reels and 3000 shots and never had more than maybe 25-30 groups, if that.

One thing I often will do to reduce save times is to split the project up into kind of a "first half" / "second half" thing. That way, there will be groups that only exist in one and not the other, which further reduces space. Of course, if you need that correction, you'll have to find a way to bring it over. Consolidating the group is one solution.

[Peter Chamberlain]

I'm working on a longform narrative project where I've had to use a large amount of groups. The list is now taller than the screen height and while the UI shows a triangle scroll down at the bottom of the page, it doesn't scroll and I can't access the rest of the saved groups. This seemed to also exist in R11 as well. Does anyone know of a workaround to access these extra groups? Can this be added to a bug fix list?

Cheers

Can you detail George the workflow that uses so many groups?
How are you defining the need for two or more clips to be grouped?
It may be there is a simpler way to get what you need.

My workaround: use fewer groups. (Not being sarcastic.) I've done whole features with 6 reels and 3000 shots and never had more than maybe 25-30 groups, if that.

One thing I often will do to reduce save times is to split the project up into kind of a "first half" / "second half" thing. That way, there will be groups that only exist in one and not the other, which further reduces space. Of course, if you need that correction, you'll have to find a way to bring it over. Consolidating the group is one solution.

It's just a 22 minute episode for broadcast, so compared to a feature, maybe I'll just have to pare down my groups. I'll look into the consolidating.

I'm working on a longform narrative project where I've had to use a large amount of groups. The list is now taller than the screen height and while the UI shows a triangle scroll down at the bottom of the page, it doesn't scroll and I can't access the rest of the saved groups. This seemed to also exist in R11 as well. Does anyone know of a workaround to access these extra groups? Can this be added to a bug fix list?

Cheers

Can you detail George the workflow that uses so many groups?
How are you defining the need for two or more clips to be grouped?
It may be there is a simpler way to get what you need.

It's a 22 minute episode for broadcast. We're adopting the established workflow that was already in place for the previous rounds of color at another facility, whereby a single 22 minute quicktime is sent along with an EDL to use as the cutlist. As a result, the normal benefits of remote linking aren't possible. In most if not all scenes, there's a color balance shift between the two main cameras at the source level, so I was hoping to group at least those two angles separately (not to mention a number of other angles that would be nice to do as well). The problem is the amount of scenes in the episode have just added up. Given the turnaround time for the job, I was trying to reduce time in propagating versions of grades/tweaks manually. Thanks for any insights.

if you know how much is the shift between the two cameras (as average) it could be doable to create a correction and select all that camera angle and rolls that correction through.

If it's just two cameras in the exact same scene, I would bet one node (not a pre/post clip correction) would fix it. The only possible exception would be if it was a vastly different camera with a grossly-different exposure, like a clipped GoPro vs. a perfectly-exposed Red Epic. That might need several nodes.

The only time I use Groups is for situations where I balance out a scene -- or a series of scenes -- and then in a trim pass, the director or DP says, "hey, I really wanted this darker and greener." Since we know every shot in the scene already matches, all you need to do is a Post-clip correction that adds the change the client wants. It'll probably still require touch-ups, but this will get you close.

I've had features with 25-30 groups, but rarely do I use more than 5 or 6 per reel. For a half-hour TV show, it can be a lot faster and simpler than this. We almost never have more than 4 hours to correct an entire sitcom, and those are done every day from 4 cameras. 3 hours of correction time, 1 hour to review and trim, and then hit the button and render.

yea,
adding one more similar voice, just finished;

- a 22 min/ep tv series 1/2day per ep = 6.5 days for 13 eps... 3 pre-clip groups in total, one for each camera
- feature, 94min, 15 days, 6 post clip groups in total.. for filmgrain based on camera iso

i am more likely to use the gallery and append node to add a common offset, easier to trim later

could help if the group function allow to use Metadata info like the camera you use?

feature, 94min, 15 days, 6 post clip groups in total.. for filmgrain based on camera iso

Yeah, I also had 2 or 3 different grain PowerGrades that I'd drop in as a Post-Clip correction in Groups. I'd select whichever grain effects seemed to work best for a given scene (day / night / interior / exterior).