Unable to break out nested layers when using nest as source

I'm going back to the previous version of Premiere because of this change. What a mess around!

As an AE having all the clips un-nested and unlinked is essential for prepping timelines how my editor wants it and allowing full flexibility. This was one of the last things stopping me from going over to Resolve... once BM finds an answer to productions its game over for Premiere. 

Hello @JOHN MONDO, @jasondecker, and @Dreamotion ®,
A product team member has marked this bug as fixed, so I can change its status.

Please let the community know if you still have trouble with this issue.

Thanks,
Kevin

@Ben Insler So I actually wrote a bug report about this the other day and was coming back here to update it with further broken functionality when a deep Google search turned up this thread. This answered not only this question but a few others about Multi-Cam that I didn't even know I had, so thanks for that. But I work with Multi-Cams literally all the time and getting this information from a comment thread on a bug report doesn't feel like the greatest way to learn these things.

Which is to say:

The Multi-Camera Follows Nest Setting option does appear to be live in the current version (24.2.1) but I've scoured the Release Notes to find out where I should have learned about these changes and can't find anything. Am I just missing it? Or is Adobe maybe in need of some better documentation when making deep structural changes to long-standing workflows that aren't necessarily the shiny new AI tools and Tiktok export functionality?

Your workflow suggestion about making a "holding" Multi-Cam sequence with the correct number of video and audio tracks and then creating a second one for the auto-sync which ends up with dozens of tracks that need to be collapsed down is completely new to me. Again... Adobe might want to look into clear, concise, and complete documenation on these things. We as users have been utilizing a multitude of workarounds over the years to get things to work the way we need them to, so if certain workarounds are probably fine and others aren't, it would be REALLY helpful to know exactly how Adobe thinks we should be using these things, step-by-step, with all potential use cases laid out... and not just in a comment thread on a bug post on the forum. Auto-sync isn't perfect. And field shooters and sound recorders are even less so. And, in Doc work, there are even times when we get another random camera of an event (often cellphone footage that we acquire from an outside source) that we'd like to add into an existing multi-cam. We need flexibility to manually adjust and tweak multi-cams to correct for these potentials and should probably know which ways of dealing with them are fine and which have the potential to break things down the line.

@Ben Insler Thank you for your swift reply and relative information regarding my similar post in another forum - this whole situation lost me and my colleagues a day of editing. Having to scour the internet to deep-dive and find a change Adobe has made to something essential to editing  AND didn't need chaning is the frustrating part of all this. But again, thanks for the swift reply and pointing me in the right direction. We just want to be able to work conistently and without facing hurdles like this.

Hi @Leapnlarry - please see the correct answer above.

Hey Ben,

thank god i finally found this thread.  I was going nuts trying to figure out why my multicams were not dropping as individual clips when nesting was off.  my work around has been to open in timeline, then copy and past the individual clips to the new timeline.

it is so much easier to just turn off nesting, and drop the multicam sequence on a timeline.

sometimes I want to see all the individual audio and video clips and choose them manually instead of doing the multicam workflow.  

Is adobe trying to find a way to re-enable the ability to drop the multicams into a timeline as individual clips, back to the way we used to be able to do it.

thanks

the full green multicam block in the top image is totally unweildy and hard to interpret.

At the risk of oversharing (and not at all intending to impose my own personal preferences), I disagree.  To me this acutally looks cleaner as it is clear that the audio and picture assets are associated together in the timeline while maintaining access to all the audio ISOs, and if track organization is consistent across the workflow, it's still relatively clear which track each subject lives on.  It also gives me access to the source audio at the source clip level rathre than having to rely explicitly on the stringout sequence.  As you mentioned though, this is more a case of expectation than functional limitation.  That said you do lose the subject labeling per track in the Multi-Cam, and I concede that this is nice to have from the Editor's perspective, sepecially if mic'd subjects are changing setup-to-setup.

@Ben Insler 

Ben - I'm going to point out a flaw in your logic. The great thing about seeing the source audio as discrete clips is you can tell where the camera started and stopped recording to the frame. You can't do that with a continuous green line. I've not heard a single editor complain about the previous functionality and plenty complain about the change. Users in this thread include a variety of very distinct and advanced workflows. Maybe consider reversing this decision as it doesn't seem too popular. It's not like you had users knocking down your door saying this nest multicam thing is a nuisance. I do appreciate all your input here but could you at least put it to a vote?

Sorry, no - I thought youor the mods could just break it out into a new thread.

@Ben Insler 

I will note here that you describe the Audio Channels Preset "Automatic" this way:

By selecting this option, Premiere Pro will examine the audio components of each clip being used to build the Multi-Cam, and then select a track routing option that best encapsulates all of your different sources. 

However, Adobe documentation describes it this way:

Automatic: Reads the audio type of the first clip and uses this mapping.

Which is correct?  @Kevin-Monahan (documentation issue)

R.