Sync in Timeline

A better workaround imo, is to use the cut page for this scenario.

If all your clips have time code and the appropriate meta data to determine angles, then as soon as you open the cut page the new clips will show up in the sync bin properly synced and ready to be cut into the timeline.

In a lot of ways the cut page makes the multi-cam functionality redundant unless you have 10+ angles.

I've tried the Cut Page and although it has some powerful features, there are some issues and it doesn't quite fit my use case. The issues I have found are below

I have camera A with native timecode (from BM Ursa Broadcast), and Camera B & C with LTC timecode recorded on audio tracks (+ 10 channels of sound recorded on external recorders, but I have left the external audio aside for now).

In the media page, Camera B & C I have right clicked and selected "Update Timecode from Audio Track" and this has indeed done that.

1. Timecode sync option in cut page doesn't seem to use just the timecode from Camera B&C (LTC timecode track) and presents just one camera in the left hand box, and effectively does nothing when clicking the sync button. Syncing in traditional MultiCam does respect the updated timecode from LTC. On further inspection, the cameras with LTC (recorded on Atomos Samurai), had the wrong file creation date on the file, but note that the embedded LTC Timecode is sample accurate, so it appears that the SYNC window, when selecting timecode, is basing it's decision on more than just the actual timecode. There is no way to modify the creation date in Resolve, but using the Unix touch command to set the correct date of the file, will then enable them to sync as expected.

2. The Sync bin function, awesome as it is, doesn't appear to have a live cut function like the traditional multicam workflow. So you can't watch and press the selected camera to cut. This is how I generally cut theatre / live performances.

It looks like under the hood, Resolve is creating a multicam clip for use by the cut page for angle selection, then creating effectively, a flattened view in the timeline. It's a different workflow with many advantages, but not a one size fits all solution to multicam .... yet!

Another thing to note, if you do have LTC in an audio channel of one of your cameras and don't mute it via clip attributes before you sync, when using the sync bin, you will hear the LTC channel! This is because the clip is actually embedded in a multicam clip used by the cut page, so if that clip was created before you mute the channel, it will be present. Just something to watch for.

The material I am cutting is made from 1 hour long theatre performances. If the cut page did have live switching it would have the added advantage of being able to see the footage from all cameras ahead of making the cut, but the current implementation seems to be geared for stop / cut / trim workflow, rather than live angle selection. Very nice functionality in the cut page and has many advantages / speed improvements, but would be so nice to have the live angle selection feature from traditional multicam workflow.

We need to continue wishing!

This has been going on since at least 14.

+1

+1 to this as well. This is a feature my team and I used often when we were all using Premiere.

We're using a clunky workaround right now by making a multicam clip them copy and pasting it to another timeline, but it has lot more unnecessary steps.

+1 for sync in timeline... missing so much after Premiere...

This is absolutely imperative for workflow and ease of use. For any video I make that has any external recording in it, I can not use Davinci Resolve because I can not figure out how to sync audio for my workflow. Syncing and appending tracks or using multi-cam timelines DO NOT work for my workflow and do not allow the type of flexible editing that editing in the main timeline affords.

Right-click selected tracks, synchronize. It's as easy as that.

Let's see this in the next Davinci Resolve please.

I think what BM has been developing is for an ideal world.

But nothing is ever ideal, e.g. if the sound man messed up on set and have multiple files for each track instead of a multitrack file. Or maybe it was shot at high speed but now needs to sync back to normal speed, both of the examples mentioned would need to sync in timeline, as the way it syncs right now doesn't work for these cases.

I think along with this sync in timeline problem, the other problem is exporting aaf with full metadata, which it still can't at the moment. It might be two side to the same problem.

+1

+1

This would have been super useful for me on my current project.

When I tell people what I miss most about Premiere its syncing on the timeline. Or in general. Even plural eyes xml files don't work.

I get why someone would want this but I don't understand why this would be preferable way of syncing clips. It's far messier and error-prone way of syncing thing. If you accidentally overwrite or delete a clip and you would lose syncing information. Syncing in the bin allows them to more reliably maintain sync throughout the edit.

Right-click selected tracks, synchronize. It's as easy as that.

Doesn't change the fact that keeping sync relationships within your editing space is a bad idea. I have the same problem with Fusion Compositions existing within the timeline. Both have the potential for someone to inadvertently undo previous work.

if the sound man messed up on set and have multiple files for each track instead of a multitrack file. Or maybe it was shot at high speed but now needs to sync back to normal speed, both of the examples mentioned would need to sync in timeline, as the way it syncs right now doesn't work for these cases.

That doesn't remotely require syncing in the timeline. There really isn't any rule about how Media Pools should work in NLEs that says that videos can't be synced to multiple audio files. There's also things like the Cut page's Sync Bin which could be modified to fix this problem if it were only available on the Edit page. #CombineTheTimelinePages

I think what BM has been developing is for an ideal world.

Having to record audio and video separately is already unideal. The end goal of syncing these things should be to make it feel like they weren't recorded separately. Syncing in the timeline wouldn't do that, it would just be hacky solution to a problem just like pancake editing is.

Syncing in the bin...

...doesn't suit all needs. The ability to select clips in a timeline and sync via the standard methods would give editors an additional option that it seems quite a few folks would find useful.

...doesn't suit all needs. The ability to select clips in a timeline and sync via the standard methods would give editors an additional option that it seems quite a few folks would find useful.

Same problem I have with all of your posts: lack of examples. You said it doesn't suit all needs... like what?

Here's one:

viewtopic.php?f=21&t=116815

Other editors may have their own ideas about how it would help them edit faster/easier.

Here's one:

viewtopic.php?f=21&t=116815

Other editors may have their own ideas about how it would help them edit faster/easier.

That doesn't require syncing on the timeline. In fact it doesn't look like that guy would even want that.

His issue could be solved by adding more audio options to multi-cam clip and it's possible that the Sync Bin would suit his needs, too.

+1

That doesn't require syncing on the timeline.

It's not about a work flow that 'requires' syncing on the timeline. The point is to add the option for those who wish to use it, such as myself and all the other +1's in the thread.

It's not about a work flow that 'requires' syncing on the timeline. The point is to add the option for those who wish to use it, such as myself and all the other +1's in the thread.

Your whole gimmick is rejecting other people's ideas based on what you think will take up development time. Not only would it waste that but it's not a good solution to the actual problem. I'm not gonna back bringing in one programs sloppy-ass ideas just because a bunch of people +1 it. I don't care that editors coming from one program want to be able to continue bad habits in another.

I love how you outright dismissed adding the option to interweave audio and video tracks even though it would be simple to implement and has timeline navigation and organizational benefits then you advocate for a feature that could potential make timelines messier just so that you could edit something out of sync and then sync it later.

Syncing in a bin is a matter finding sync points between media and linking them. That's difficult enough, now you want a behavior that does that then has to try to figure out how to best re-edit your timeline.

If the cut page did have live switching it would have the added advantage of being able to see the footage from all cameras ahead of making the cut, but the current implementation seems to be geared for stop / cut / trim workflow, rather than live angle selection. Very nice functionality in the cut page and has many advantages / speed improvements, but would be so nice to have the live angle selection feature from traditional multicam workflow.

I agree. That's one of the reason I wish they would combine all the sequencing pages. There's random separations of functionality that hold things back. If they were merged then multi-cam and Sync Bin would undoubtedly be merged. I can go on an on about features disabled from the Edit page just to make the Fairlight page look less redundant. There's also instances where Edit has audio functionality that the Fairlight page doesn't and plenty of instances where people have suggesting improving one page by adding features from the others. It's ridiculous.

Your whole gimmick is rejecting other people's ideas based on what you think will take up development time.

That's one of three possible responses I offer.

I might agree, I might offer an improvement to the original idea, or I might vote no to the idea.

You're free to do the same here.

you advocate for a feature that could potential make timelines messier just so that you could edit something out of sync and then sync it later.

That actually wasn't my thinking here. The idea is to add the media to a timeline, sync it first, then edit it.

Your point about syncing after editing is quite valid.

That actually wasn't my thinking here. The idea is to add the media to a timeline, sync it first, then edit it.

Your point about syncing after editing is quite valid.

I apologize then. I figured your reasoning was to get started on the edit as soon as possible and worry about the sound later. I hadn't considered that you hadn't considered someone using such a feature after the edit.

+1
Davinci please you guys software is amazing and ALMOST there. But timeline audio sync to me is crucial. Switched over to Resolve about a year ago and I just can't get over missing that feature

I also don't feel like the existing audio sync algorithm is good in anything less than ideal situations. It really can't be that hard given what you guys have already pulled off

+1
Davinci please you guys software is amazing and ALMOST there. But timeline audio sync to me is crucial.

-1

See: the last few posts.

Yes! Please. Make syncing audio as easy as select and right-click.

+1


Sent from my iPhone using Tapatalk

I'll add another vote for this. It's definitely not an impossible-to-implement feature. I'm a developer too and if a feature had to cover every edge case and be totally idiot-proof it would never ship. What you do, of course, is cover the primary use cases, feasible edge cases, and fail gracefully for the rest. If someone tries to do something bone-headed you just give them a simple, friendly message like "I'm sorry, Dave. I'm afraid I can't do that."

I don't see a feature like this being likely to fail or prone to problems though. Messy timelines wouldn't make any difference. When you sync selected clips it would just move them in the timeline. There could be an option to either ripple the timeline or overwrite any clips in the way. Make it undoable in case you accidentally overwrite something you didn't mean to or you get unexpected results. Simple. Edge cases covered, graceful failure implemented; easy peasy, lemon squeezy.

"I'm sorry, Dave. I'm afraid I can't do that."

I'll add another vote for this. It's definitely not an impossible-to-implement feature. I'm a developer too and if a feature had to cover every edge case and be totally idiot-proof it would never ship. What you do, of course, is cover the primary use cases, feasible edge cases, and fail gracefully for the rest. If someone tries to do something bone-headed you just give them a simple, friendly message like "I'm sorry, Dave. I'm afraid I can't do that."

I don't see a feature like this being likely to fail or prone to problems though

No it's not impossible. It's just a bad idea that only complicates a process.

Messy timelines wouldn't make any difference. When you sync selected clips it would just move them in the timeline.

Does the audio move under the video or does the video move over the audio? Sure, either one will successfully sync those clips but because they're on the timeline AKA in the context of an edit, that behavior needs to be determined because Resolve wouldn't know what clips are placed purposely and which are placed for the edit. Would you just require that the user choose that behavior?

There could be an option to either ripple the timeline or overwrite any clips in the way. Make it undoable in case you accidentally overwrite something you didn't mean to or you get unexpected results.

In other words, its sloppily re-editing the timeline. Or are we going with the assumption that this timeline isn't representative of an edit at that point anyway? In that case, wouldn't the timeline just be working like a bin anyway? Why not just sync within a bin?

Simple. Edge cases covered, graceful failure implemented; easy peasy, lemon squeezy.

If that's the edge case then what's the primary case for this feature?

Syncing in a bin instead of the timeline creates a stronger sync between clips, can be done before or after the edit, and keeps it separate from the edit which means it has far fewer ways of giving people undesirable results.

It's just a bad idea that only complicates a process.

It would actually simplify the process of syncing clips in a timeline, which can only be done manually at the moment.

Does the audio move under the video or does the video move over the audio?

Some method would need to be decided on by BMD. Ideally the editor would have the ability to choose which clip stays put. (That part of it even Premiere Pro can't do.)

My own idea, proposed in the original post, is that the first clip selected would be the one that doesn't move, with the other clips adjusting accordingly.

It would actually simplify the process of syncing clips in a timeline, which can only be done manually at the moment.

The process isn't "syncing in the timeline" the process is "syncing". Whether you're syncing in the timeline or in the bin, you're doing it in hopes to get the same result.

Syncing in bins just makes more sense and simplifies the process because that syncing relationship will ripple to the clips in the timeline without needing to moving their place in the timeline and is a more fixed sync.

Some method would need to be decided on by BMD. Ideally the editor would have the ability to choose which clip stays put. (That part of it even Premiere Pro can't do.)

My own idea, proposed in the original post, is that the first clip selected would be the one that doesn't move, with the other clips adjusting accordingly.

That would work if your intent is just to sync multiple cameras on a timeline without using a multi-cam sequence. That's the exact same scenario that Sync Bins were made for. They sync clips in the bin, present them to you as a timeline of clips that are locked in sync with each other. If it messes something up, you can manual fix it the Sync Clips window. This allows you to keep your edit and project management separate.

I know that most people in this topic are talking about syncing for weddings and concerts but you have to consider that there's other ways an editor might think to use a sync in timeline feature. If you're asking for the feature just to sync multiple cameras for a wedding video, then something like this might seem simple, straight forward, maybe even ideal but you wouldn't think of the scenarios that a film editor might think to use the same feature. Blackmagic would have to consider that though.

When I first started editing films, I used Premiere Pro and I would sync things in the timeline manually because an automated method didn't exist yet. It wasn't uncommon that I would make a rough edit of a scene and then go back and look for the associated audio and manually sync it to the clips in the timeline before refining it further. I always found it annoying when I had to change a take because it meant I had to look for the new takes audio file and manually sync that and hope we didn't decide to go back to the original take because I would have lost the original takes syncing information.

In all cases, syncing in the timeline is a "soft" sync. They're in-sync in the sense that the audio and video are positioned in a way that they play back in-sync but the software isn't creating any locked relationship between the external audio and the video that it's synced to.

If I were still editing in Premiere Pro, I would still need to look for the audio clips that relate to the video clips in the timeline before I'd be able to sync them. By syncing in the bin in Resolve, I wouldn't need to do that as I'd already have the audio and video from a certain scene within the same bin.

You could say "Well then you can sync stuff in bins and we'll sync in the timeline." but with what Resolve has in terms of syncing within a bin, you have one method of syncing that doesn't need to consider 20 different ways that it might be used that would add more pages to Resolve 3500+ page manual.

Messy timelines wouldn't make any difference. When you sync selected clips it would just move them in the timeline.

Does the audio move under the video or does the video move over the audio? Sure, either one will successfully sync those clips but because they're on the timeline AKA in the context of an edit, that behavior needs to be determined because Resolve wouldn't know what clips are placed purposely and which are placed for the edit. Would you just require that the user choose that behavior?

There are lots of ways it could work and none of them are complicated. Off the top of my head, it seems like the start of the earliest selected clip would be a logical edit point and then you just give the user the option to ripple or not. The existing track targeting features would probably cover the rest. No problem.

There could be an option to either ripple the timeline or overwrite any clips in the way. Make it undoable in case you accidentally overwrite something you didn't mean to or you get unexpected results.

In other words, its sloppily re-editing the timeline. Or are we going with the assumption that this timeline isn't representative of an edit at that point anyway? In that case, wouldn't the timeline just be working like a bin anyway? Why not just sync within a bin?

I don't see any need to make assumptions about anything or value judgements about other people's methods. All we're talking about is moving clips in a timeline; it doesn't matter what the timeline does or does not represent. And any feature can be used in a sloppy way. Are we going to remove all editing options because some people might be sloppy with them? And anyway, it seems like automation would help a sloppy editor be more neat vs doing the same thing manually.

Simple. Edge cases covered, graceful failure implemented; easy peasy, lemon squeezy.

If that's the edge case then what's the primary case for this feature?

Syncing in a bin instead of the timeline creates a stronger sync between clips, can be done before or after the edit, and keeps it separate from the edit which means it has far fewer ways of giving people undesirable results.

Ad hoc clip syncing in the timeline is the primary use case. Syncing in a bin is great but there are times when one simply needs to sync up a couple clips on the spot.

It would actually simplify the process of syncing clips in a timeline, which can only be done manually at the moment.

The process isn't "syncing in the timeline" the process is "syncing". Whether you're syncing in the timeline or in the bin, you're doing it in hopes to get the same result.

"Syncing" is the process and "in the timeline" is where the process is being done. The point of the thread is the "where" part.

I know that most people in this topic are talking about syncing for weddings and concerts but you have to consider that there's other ways an editor might think to use a sync in timeline feature. If you're asking for the feature just to sync multiple cameras for a wedding video, then something like this might seem simple, straight forward, maybe even ideal but you wouldn't think of the scenarios that a film editor might think to use the same feature. Blackmagic would have to consider that though.

I've never worked on a feature film but I don't see how it makes any difference. Syncing is syncing. But either way, no, Blackmagic wouldn't have to consider that. If there is some situation where syncing in the timeline wouldn't work or wouldn't make sense then you simply don't use it in that situation. There's no requirement that every feature be usable by every editor in every situation.

In all cases, syncing in the timeline is a "soft" sync. They're in-sync in the sense that the audio and video are positioned in a way that they play back in-sync but the software isn't creating any locked relationship between the external audio and the video that it's synced to.

Yeah. So what? In situations where syncing in the timeline would be useful a "soft sync" is all that's needed.

You could say "Well then you can sync stuff in bins and we'll sync in the timeline." but with what Resolve has in terms of syncing within a bin, you have one method of syncing that doesn't need to consider 20 different ways that it might be used that would add more pages to Resolve 3500+ page manual.

I don't think it would be as complicated as you're trying to make it sound and I'm not aware of anyone being worried about the page count in the reference manual PDF. I can't imagine that explaining it would take more than a paragraph anyway; certainly not "pages."

There are lots of ways it could work and none of them are complicated. Off the top of my head, it seems like the start of the earliest selected clip would be a logical edit point and then you just give the user the option to ripple or not. The existing track targeting features would probably cover the rest. No problem.

It doesn't sound complicated because you're over simplifying it. There's someone in this thread who stated that they want this feature for music videos so that they could effectively send video down the timeline while the remains static. Others might use it to replace on camera audio with external audio in a film edit which means the audio moves to static video. Some want to sync between up different cameras and audio sources like in a multi-cam set up which requires audio and video to ripple.

So saying that things should just ripple to the first clip sounds simple because you're only accounting or the way you would use it.

I don't see any need to make assumptions about anything or value judgements about other people's methods. All we're talking about is moving clips in a timeline; it doesn't matter what the timeline does or does not represent.

Actually, yes it does. It absolutely does.

And any feature can be used in a sloppy way. Are we going to remove all editing options because some people might be sloppy with them?

Have you seen how many topics on this forum are people asking for patchwork solutions to problems they got themself into do to sloppy use of features? Have you seen any of my topics that are about cleaning up Resolve so that people don't have to use sloppy, error prone solutions to do simple things?

And anyway, it seems like automation would help a sloppy editor be more neat vs doing the same thing manually.

We're not using sloppy in the same way. Also, when did this conversation become an automated sync vs manual sync discussion? Last I checked I was pushing for further refining the automated syncing that Resolve already has they can already fulfill 95% of the use cases of people in this topic.

Ad hoc clip syncing in the timeline is the primary use case. Syncing in a bin is great but there are times when one simply needs to sync up a couple clips on the spot.

That doesn't require timeline-syncing. You can sync things in the bin on the spot as well.

It's not like syncing in the bin means that you need to select the ins and outs for the clips again and drag it back into the timeline. The sync relationship propagates as all clips on the timeline are instances that link back to that clip in the bin. That's actually one of it's benefits. It's very common that bits of one source clip are used throughout a timeline. Timeline syncing requires the audio to be synced per-clip-instance, bin syncing only requires syncing per-source-clip.

"Syncing" is the process and "in the timeline" is where the process is being done. The point of the thread is the "where" part.

And my question is the "why" when Resolve already has bin-syncing which can be expanded upon and "what" is the advantage of implementing something that gets you to same place as bin-syncing but is slightly more complicated and more error-prone.

Keep in mind that automated-syncing of any kind is already more error-prone than manually syncing, it's just much much faster. Why someone would add unneeded variables to the situation is beyond me.

I established the "why nots", I'm still waiting on the "whys".

I've never worked on a feature film but I don't see how it makes any difference. Syncing is syncing. But either way, no, Blackmagic wouldn't have to consider that.

Yes, "syncing is syncing" and there's already multiple methods of syncing built into Resolve and all are within the Media Pool. Those method of syncing currently suit film, interviews, and live event scenarios very well. I have heard people mention that "Auto Sync Audio" lacks the ability for two audio clips to sync to one video clip and I agree, that should be added but that's not an inherent restriction of syncing in a bin, the Sync-Bin even demonstrates that.

If there is some situation where syncing in the timeline wouldn't work or wouldn't make sense then you simply don't use it in that situation.

You're missing the point. It's not that there's a lot of things that timeline syncing can't do. There's nothing that's stopping an NLE from providing options to Timeline syncing that allow someone to just drag all the contents of a bin to the timeline and have it sync audio to video and lay them out like a Selects timeline. The timeline essentially works like a bin in that situation. The issue is that it just needs to consider more variables since it's being done further downstream of the editing process.

I already mentioned some of those variables as they relate to the sync prompt, but what about syncing to a clip with time remapping? It's not impossible by any means, but having to take that into account does complicate things to some degree.

There's no requirement that every feature be usable by every editor in every situation

No there isn't but can you even guarantee that your "simple" implementation would even appease all the people that upvoted this feature in this two page topic?

Yeah. So what? In situations where syncing in the timeline would be useful a "soft sync" is all that's needed.

So what's the advantage of a soft sync? lol

I don't think it would be as complicated as you're trying to make it sound and I'm not aware of anyone being worried about the page count in the reference manual PDF. I can't imagine that explaining it would take more than a paragraph anyway; certainly not "pages."

Have you read the manual?
This information-

Undo and Redo in DaVinci Resolve
No matter where you are in DaVinci Resolve, Undo and Redo commands let you back out of steps you’ve taken or commands you’ve executed, and reapply them if you change your mind. DaVinci Resolve is capable of undoing the entire history of things you’ve done since creating or opening a particular project. When you close a project, its entire undo history is purged. The next time you begin work on a project, its undo history starts anew.

Because DaVinci Resolve integrates so much functionality in one application, there are three separate sets of undo “stacks” to help you manage your work.

• The Media, Edit and Fairlight pages share the same multiple-undo stack, which lets you backtrack out of changes made in the Media Pool, the Timeline, the Metadata Editor, and the Viewers.
• Each clip in the Fusion page has its own undo stack, so that you can undo changes you make to the composition of each clip, independently.
• Each clip in the Color page has its own undo stack, so that you can undo changes you make to grades in each clip, independently.
• In all cases, there is no practical limit to the number of steps that are undoable (although there may be a limit to what you can remember). To take advantage of this, there are three ways you can undo work to go to a previous state of your project, no matter what page you’re in.

To simply undo or redo changes you’ve made one at a time:

• Choose Edit > Undo (Command-Z) to undo the previous change.
• Choose Edit > Redo (Shift-Command-Z) to redo to the next change.
• On the DaVinci control panel, press the UNDO and REDO buttons on the T-bar panel.

TIP: If you have the DaVinci control panel, there is one other control that lets you control the undo stack more directly when using the trackballs, rings, and pots. Pressing RESTORE POINT manually adds a memory of the current state of the grade to the undo stack. Since discrete undo states are difficult to predict when you’re making ongoing adjustments with the trackball and ring controls, pressing RESTORE POINT lets you set predictable states of the grade that you can fall back on.

You can also undo several steps at a time using the History submenu and window. At the time of this writing, this only works for multiple undo steps in the Media, Cut, Edit, and Fairlight pages.

To undo and redo using the History submenu:

1. Open the Edit > History submenu, which shows (up to) the last twenty things you’ve done.
2. Choose an item on the list to undo back to that point. The most recent thing you’ve done appears at the top of this list, and the change you’ve just made appears with a check next to it. Steps that have been undone but that can still be redone remain in this menu, so you can see what’s possible. However, if you’ve undone several changes at once and then you make a new change, you cannot undo any more and those steps disappear from the menu.

Once you’ve selected a step to undo to, the menu closes and the project updates to show you its current state.

To undo and redo using the Undo window:

1. Choose Edit > History > Open History Window.
2. When the History dialog appears, click an item on the list to undo back to that point. Unlike the menu, in this window the most recent thing you’ve done appears at the bottom of this list. Selecting a change here grays out changes that can still be redone, as the project updates to show you its current state.
3. When you’re done, close the History window.

- takes up 13 pages. The quoted bit is actually just two pages but's repeated for the sections for each of Resolve's pages.

Many features in Resolve that are repeated between pages are cover separately for each page. The Media Pool, for example, is covered for each page. Now there's some small differences between the Media Pool in each page so it's not all redundant but sections like "Bins, Power Bins, and Smart Bins", "Showing Bins in Separate Windows ", "Filtering Bins Using Color Tags", are copied word-for-word three times in the manual.

Some features like Compound Clips are explained in 3.5 pages in the section for the Edit page and are brought up again for half a page as "Audio Compound clips" in the Fairlight section before pointing people back to the previous section.

To be fair, the manual contains all the information for syncing audio and video in Chapter 13: Syncing Audio to Video and it's explained in 5 pages. Adding timeline syncing would obviously add more on top of that, but considering there's three timelines pages where BMD can decide to implement it differently, who really knows.


__________________________________________________________

Btw, if you're not familiar with what I meant when I mentioned "selects", it refers to when someone will go through clips for a project, picks the good takes, trims them down, and possibly syncs and color codes them on a timeline that would be called the Selects timeline. The intended use-case is to be used like a bin for another timeline.

What advantages does that process have compared to making sub-clips, placing them in a bin, color coding, and syncing them in the Media Pool? Only one. Having them in a timeline allows you to scrub through footage like a tape to find shots quickly.

Both Media Composer and Premiere Pro allow editors to open their Selects timeline in the Source Monitor, set ins and out points, and drag that into a new timeline as source clips. It's pretty clean way of supporting that workflow and since you're using it like a bin, viewing and selecting clips through the Source Viewer makes a lot of sense. After all, it was made to clip and move source media to the timeline.

Resolve actually has a better solution for it called the Source Tape view but BMD only allowed it to be used the Cut page for some reason. It's very simple. It's just a view for the Source Viewer that displays any bin as if it were a continuous tape. You can color code and sync them in timeline and place all the good takes in a bin. If you need to make several clips per-source clip, then just make sub-clips. It's a very small feature that manifests in the interface as just a small icon but has all the benefits of the aforementioned methods without having to create another timeline while still allowing you to navigate the bin as you normally would. It's a great example of solve a problem instead of treating its symptoms.

Premiere Pro didn't always support that functionality though. Instead Premiere Pro users used "pancake editing" or the practice of stacking two timelines on your screen: one for selects and one for the edit. To my understanding, that wasn't use case that Adobe thought of specifically, it just allowed sequence panels to moved around separately and that's just a way Premiere users decided to use it.

Is there any advantage to it over the previous two methods? No. It just uses more screen real-estate and creates another timeline. To my knowledge, Media Composer, Final Cut Pro X, Vegas, and Edius don't even support it because it's so inelegant.

So how did Resolve support using Selects before the Cut page and how does it currently support that workflow on the Edit page? Stacked timelines... otherwise known as pancake editing. Why support pancake editing when there were better ways to do it? Premiere Pro users who are stuck in their ways.

Why do I bring it up? Because that's basically this topic.

It doesn't sound complicated because you're over simplifying it. There's someone in this thread who stated that they want this feature for music videos so that they could effectively send video down the timeline while the remains static. Others might use it to replace on camera audio with external audio in a film edit which means the audio moves to static video. Some want to sync between up different cameras and audio sources like in a multi-cam set up which requires audio and video to ripple.

So saying that things should just ripple to the first clip sounds simple because you're only accounting or the way you would use it.

No, it doesn't sound complicated because it isn't complicated. I'm accounting for the way it would be used without regard for irrelevant details like whether the project is a feature film, an interview or a music video. The only question is which clips move and which clips don't--the same question already involved with any kind of edit.

I don't see any need to make assumptions about anything or value judgements about other people's methods. All we're talking about is moving clips in a timeline; it doesn't matter what the timeline does or does not represent.

Actually, yes it does. It absolutely does.

Actually, no; no it does not.

Have you seen how many topics on this forum are people asking for patchwork solutions to problems they got themself into do to sloppy use of features? Have you seen any of my topics that are about cleaning up Resolve so that people don't have to use sloppy, error prone solutions to do simple things?

No, I haven't and it doesn't matter.

And anyway, it seems like automation would help a sloppy editor be more neat vs doing the same thing manually.

We're not using sloppy in the same way. Also, when did this conversation become an automated sync vs manual sync discussion? Last I checked I was pushing for further refining the automated syncing that Resolve already has they can already fulfill 95% of the use cases of people in this topic.

The conversation has always been about providing a way to automatically sync up clips in the timeline so we don't have to do it manually when it's needed. What do you think the conversation is about? Also, sloppy means "careless and unsystematic; excessively casual." What do you mean by it? Automation is inherently systematic; i.e., less sloppy.

Ad hoc clip syncing in the timeline is the primary use case. Syncing in a bin is great but there are times when one simply needs to sync up a couple clips on the spot.

That doesn't require timeline-syncing. You can sync things in the bin on the spot as well.

It's not like syncing in the bin means that you need to select the ins and outs for the clips again and drag it back into the timeline. The sync relationship propagates as all clips on the timeline are instances that link back to that clip in the bin. That's actually one of it's benefits. It's very common that bits of one source clip are used throughout a timeline. Timeline syncing requires the audio to be synced per-clip-instance, bin syncing only requires syncing per-source-clip.

So if I've got a video clip and separately-recorded audio from an interview together on a timeline that, for whatever reason, are out of sync, there's something I can do in the sync bin that will move those two clips in my timeline to make them sync up?

"Syncing" is the process and "in the timeline" is where the process is being done. The point of the thread is the "where" part.

And my question is the "why" when Resolve already has bin-syncing which can be expanded upon and "what" is the advantage of implementing something that gets you to same place as bin-syncing but is slightly more complicated and more error-prone.

If your question was "why," saying "The process isn't 'syncing in the timeline' the process is 'syncing'" is a confusing way to ask it. Kinda like using "sloppy" to mean something other than sloppy. But if your question is genuine, I suggest re-reading this thread. It's full of answers to the "why" question.

I established the "why nots", I'm still waiting on the "whys".

You appear to have ignored the "whys" and your "why nots" look like straw to me.

The issue is that it just needs to consider more variables since it's being done further downstream of the editing process.

Not really. Syncing is syncing whether it's in a bin or in a timeline. The only extra variable is what might have been done to the clip in the timeline, like remapping, and then either Resolve can deal with that or it can't. If it can, great; if it can't, pop a friendly error message and we're no worse off than we were before. Simple. Shuffling clips after the sync is complete does not impact the syncing process in any way and would use existing functionality.

I already mentioned some of those variables as they relate to the sync prompt, but what about syncing to a clip with time remapping? It's not impossible by any means, but having to take that into account does complicate things to some degree.

That may complicate things for BlackMagic's dev team, were they to implement this, but it doesn't complicate anything for the user.

There's no requirement that every feature be usable by every editor in every situation

No there isn't but can you even guarantee that your "simple" implementation would even appease all the people that upvoted this feature in this two page topic?

No and I don't need to. Can you guarantee that the existing sync bin features will work in every situation?

Yeah. So what? In situations where syncing in the timeline would be useful a "soft sync" is all that's needed.

So what's the advantage of a soft sync? lol

Speed and simplicity, of course.

Have you read the manual?

No, I just use it as a reference when I need to look up something specific. But okay, so it probably would take a couple pages to explain. Again, so what? Who's worried about the page count in the manual?

Why do I bring it up?

To confuse and complicate the issue? lol

The conversation has always been about providing a way to automatically sync up clips in the timeline so we don't have to do it manually when it's needed.

No. The feature request was about automatically syncing clips in the timeline. My conversation with you and Simon, was never manual syncing vs automated syncing.

What do you think the conversation is about? Also, sloppy means "careless and unsystematic; excessively casual." What do you mean by it? Automation is inherently systematic; i.e., less sloppy.

You're talking solely about people using a feature in a sloppy way. I'm talking about the implementation being sloppy and causing code and feature bloat.

As I said before, automation isn't inherently less sloppy and it's not always reliable. There's tons of times when an automated process can cause a much bigger mess than if someone to do something manually, but when automation works, it's faster.

That apples to audio syncing as well. If the on-camera audio and is too dissimilar to the external audio, then automated may very well sync it to the wrong place in the clip or even the wrong clip altogether.

So if I've got a video clip and separately-recorded audio from an interview together on a timeline that, for whatever reason, are out of sync, there's something I can do in the sync bin that will move those two clips in my timeline to make them sync up?

You're a little to stuck on the concept on timeline syncing here but I get it. If you're not used to the idea of syncing in the bin and you're used to timeline syncing then that makes sense. Okay, lets say you're syncing based on audio. That video clip is going to have embedded audio that came from the camera.

Before even making a timeline, you can select those two clips in the bin and select Auto Sync Audio > Based on Waveform or Auto Sync Audio > Based on Waveform and Append Tracks. Resolve will attempt to automatically sync that external audio to the audio embedded in the video clip and link them.

If you chose Based on Waveform then the external audio will be set as the primary track for that video clip. When you drag it onto a timeline the external audio will already attached to the clip as if it were the embedded audio. If, for some reason, you need to use the actual embedded audio again, you can right click the clip in the timeline and select Clip Attributes, go the audio tab and switch the audio back without breaking the syncing relationship.

If you chose Based on Waveform and Append Tracks, then it will do the same thing except it will add the external audio as additional tracks to the clip. When you drag that clip to the timeline, it will have two audio tracks connected to it: one is the embedded audio, the other is the external audio.

You can also do this same process with an entire bins of clips (but it will be more error prone), you can sync based on timecode instead, and this can be done in either the Media Page or Edit page. The Media Page also has additional tools for setting these bin-level sync relationships manually if Auto Syncing fails or if a video clip has missing audio or incorrect timecode.

If you already started editing with just the video clips and on-camera audio, you can still select the clips in the bin and select Auto Sync Audio. The clips in the timeline will still have the embedded camera audio. Just select the clips on the timeline, right click, and choose Clip Attributes again. You can then select the Linked Channels and all the timeline in your audio will be replaced with the externally recorded audio. Any additional clips that you add to the timeline will automatically drag in with the linked audio connected.

Since this process actually links audio clips to video clips, if clips tracks are out-of-sync with each other, it the clips will give you a red indicator to tell you how many frames out of sync they are.

None of that has to do with the Sync Bin though. The Sync Bin, the name of a specific feature in the Cut Page, is a view of the Media Pool that syncs all the media in a bin relative to each other based on timecode, audio, in-points, out-points and/or manual syncing and displays it as a timeline. It's a non-realtime multi-cam editing alternative that allows you to scroll through the footage in the bin as if it were a multi-cam clip.

If your question was "why," saying "The process isn't 'syncing in the timeline' the process is 'syncing'" is a confusing way to ask it. Kinda like using "sloppy" to mean something other than sloppy. But if your question is genuine, I suggest re-reading this thread. It's full of answers to the "why" question.

The only "whys" that people have been answering is why the want the feature, not why it's needed when bin-level syncing syncing already exists and can be expanded upon if it doesn't suit the someone's needs.

You appear to have ignored the "whys" and your "why nots" look like straw to me.

I expected you would understand what I'm talking about since you apparently have experience with programming. It's strange because I constantly think things like "What would be the best way to implement this feature? Does that make sense in the context of the whole program?" when I program whether its web or desktop programming.

Actually, no; no it does not.

At the feature level, no it does not. At the application level, yes it does. Keeping a consistency across the application makes it easier to learn and can keep code cleaner.

Not really. Syncing is syncing whether it's in a bin or in a timeline.

Yes, syncing is syncing. I know that and I said as much. If you knew that then we wouldn't be having this conversation.

Seriously, I just had to explain how syncing in the bin works to you. You asked me how it would work in an interview scenario when that's probably one of the simplest uses for it. I even had to explain that the Sync Bin is a specific feature and tell you what it does! You're using the program that has these features. If you don't know how they work then why not at least mess with them when you're having a conversation about them so you're not going in blind?

No and I don't need to. Can you guarantee that the existing sync bin features will work in every situation?

Confirming again that you're not really familiar with what Resolve already has available to it. I can't confirm it would be useful for every situation. I already mentioned ways that it could be expanded upon. However syncing in a bin can do all the stuff you claim to need timeline-syncing for.

Btw, the whole thing I mentioned with speed ramping being an issue for timeline-level syncing, that was me testing you to see how critically you're actually thinking about any of this. Speed ramping likely wouldn't be an issue for timeline-syncing because that ramping keyframes would be known to Resolve already. It would just apply those ramps to the new audio.

Speed and simplicity, of course.

It's literally no faster or simpler. Timeline-level syncing actually can requires more manual work on the editors part especially when switching between takes or bring back in footage that was previously cut.

No, I just use it as a reference when I need to look up something specific. But okay, so it probably would take a couple pages to explain. Again, so what? Who's worried about the page count in the manual?

People attempting to learn the software. I'm not saying a lot of people read it front to back, I definitely haven't but it's easier to find things in a 2000 page manual than in a 3500 page manual.

Sure, an additional few pages won't make it vastly more difficult to look through but a bunch of small little redundant features add up.

To confuse and complicate the issue? lol

People who constantly think things are simpler than they are generally miss of a lot of things around them.

WE GOT IT!!!!!!!

WE GOT IT!!!!!!!

I knew this was gonna happen. The dumber the feature, the higher the chance BMD will add it. Ultimate redundancy is king apparently.

That's the way to poop on a party, Mark. Good job!

That's the way to poop on a party, Mark. Good job!

Gladly, Jim lol And you can't wait until you understand feature bloat as it happens over the next few years.

I expected you would understand what I'm talking about...

And you were correct. However, there's a difference between understanding and agreeing that you've come to a reasonable conclusion.

And you were correct. However, there's a difference between understanding and agreeing that you've come to a reasonable conclusion.

I'd buy that if your last post didn't constantly conflate two features and if you didn't ask about bin syncing works after dragging files to the timeline. You could just be honest lol

can't wait until you understand feature bloat

Have no fear. I'll keep fighting the good fight against those features I consider 'useless'. (As I'm sure you will also.)

So here's the design BMD ended up using.

"You can only select one clip per video or audio track to align, and they all will align to whichever clip is on the lowest-numbered video or audio track. Clips selected that have no overlapping timecode or audio waveform will not be moved and left in their original position on the Timeline."

I find that entirely workable.

WE GOT IT!!!!!!!

Amazing! I've been waiting for this for years, I finally made the full transition from Premiere to Resolve as a result. Here's a quick tutorial:

This thread generated a lot of... lively discussions, but suffice to say there were a lot of people who wanted this feature, myself among them, and I'm very glad it's arrived. I just find it to be a very simple and intuitive method and I like how clips can easily be manually/independently nudged and adjusted in the timeline. Thank you BM!

Syncing in the timeline wouldn't do that, it would just be hacky solution to a problem just like pancake editing is.

Mark, just a quick one, I'm genuinely trying to learn here: why do you think that pancake editing is "hacky" and not a proper workflow?

In today's day and age, tutorial on anything film.making can be found except on a proper editing workflow (or a paradigm so to speak). I tried pancake editing and it helped me massively cut down on time spent scrubbing through the dailies and construct various "sub-timelines" which later helped me create edit drafts. Coming from software background, I almost considered these as "snapshots" which could easily be compared visually (both in the viewers and stacked timelines), copied from one to another, etc.

What is the proper way to edit then? Use additional V tracks to put selects into these or simply watch everything in the source viewer, mark IN/OUT and insert into draft timeline?

Regarding sync bins - how should I go about doing "partial" syncs, where a different number of video and audio clips exists and some parts of some videos correspond to parts of audio tracks?

Many thanks in advance!

What is the proper way to edit then? ...simply watch everything in the source viewer, mark IN/OUT and insert into draft timeline?

A bit off topic here, but...an ACE editor talked about his system in an interview.

Watch everything twice - outside of the editing suite - taking notes the second time around for 'selects'.

Mark, just a quick one, I'm genuinely trying to learn here: why do you think that pancake editing is "hacky" and not a proper workflow?

The whole advantage of pancake editing is that you can group only the good takes or footage and few them linearly (like a tape) instead of needing to look for clips in your bin. That allows you to very quickly search for footage without clicking through clips. It also means you lose the ability to view your selects as a bin. You're picking to do one of the other.

You're also using the timeline as a bin which isn't something the timeline UI was designed for and it means the Media Pool and Source Viewer are being under-used or not used at all. The latter part means you can't easily have source footage side by side with the program monitor. It also means that any hotkeys or buttons for inserting, overwriting, etc. from the Source Viewer to the timeline can't actually serve their function. Not to mention that having two timeline open isn't space efficient.

So pancake editing is A solution to problem and that works but its a hacky one because it was devised in the absence of any other solution.

Premiere Pro did one better improved on it by allowing you to open a selects sequence in the source monitor and to insert clips from that timeline into a new timeline as source clips. That solves the problem of not being able to use your Source monitor to trim and insert but that still means you're losing the ability to view those clips as a bin.

That's why I feel the Cut page's Source Tape View better solves that problem. You can place clips or sub-clips in a bin and look through them as if they were one continuous tape or you can skip to specific clips in the bin. It's an actual proper solution to the problem that pancake editing was supposed to fix.

In today's day and age, tutorial on anything film.making can be found except on a proper editing workflow (or a paradigm so to speak). I tried pancake editing and it helped me massively cut down on time spent scrubbing through the dailies...

Which is precisely what Source Tape view does.

...and construct various "sub-timelines" which later helped me create edit drafts. Coming from software background, I almost considered these as "snapshots" which could easily be compared visually (both in the viewers and stacked timelines), copied from one to another, etc.

But having an actual snapshot feature would allow specific versioning and comparison features to be built around that.

I'd compare it to saving a files. You could always save older versions of a file, name them different, and keep in mind that they're snapshots of the same project and it'll work just fine but there's a reason that OS's have file versioning features and snapshotting software exists. With specific versioning features you can have your computer automatically save those older backups to different locations, allow you to wipe the old versions in an automated way, the old versions can store as just the changes from the current version and comparisons potentially more detailed comparisons can happen.

I won't act like I've developed a bunch of software but I have programmed my own blogging and forum software for my old site and I've written some game code. Most of the my suggestions for Resolve factor in thinking of it the program as a whole and I like features that fix problems at their cause instead of adding patch work features that fix the symptoms of the problem.

What is the proper way to edit then? Use additional V tracks to put selects into these or simply watch everything in the source viewer, mark IN/OUT and insert into draft timeline?

I'm not sure what you're describing here.

Regarding sync bins - how should I go about doing "partial" syncs, where a different number of video and audio clips exists and some parts of some videos correspond to parts of audio tracks?

Many thanks in advance!

Just to be clear, Bin Syncing and Sync Bins are two separate but related things.

Bin syncing is when you have audio clips synced to videos clips in the bin so that you can drag them in as if the external audio was part of the video clip. If you have two video clips for two takes but the audio kept on rolling through both then Bin Syncing will pair that one audio clip to both of those clips but with different in and out points so the audio matches up. I don't think it can currently associate two audio clips with one video clip though there's no reason it could be expanded to be able to do that.

Sync Bins are for multi-cam sequences. All of the selected audio and video clips will be synced exactly like a multi-cam clip. The difference is that the sync bin is always synced to the top most clip in your timeline.

You're also using the timeline as a bin which isn't something the timeline UI was designed for and it means the Media Pool and Source Viewer are being under-used or not used at all. The latter part means you can't easily have source footage side by side with the program monitor. It also means that any hotkeys or buttons for inserting, overwriting, etc. from the Source Viewer to the timeline can't actually serve their function. Not to mention that having two timeline open isn't space efficient.

Yes I get this but, having tried both "workflows", I really strongly feel it is mUCH easier to have them side by side, insert (copy) from one timeline to the other and move from there.

I gave it an honest shot to try it differently in Davinci today. Literally spent the whole day going through the clips organised into various bins, watched them in the source viewer, pulled good "takes" as subclips and when done, assembled it all in a timeline on the EDIT page. Felt WAY clunkier, stumbled upon many obstacles (like subclips getting thrown in the master bin instead of a proper footage bin).

Perhaps Media pool and source viewer have found a better, more human-friendly use? Two small monitors, preview in one, insert into timeline2 and watch in monitor 2... I don't know. Seems friendlier and quicker to me.

What is the proper way to edit then? Use additional V tracks to put selects into these or simply watch everything in the source viewer, mark IN/OUT and insert into draft timeline?

I'm not sure what you're describing here.

There's a stringer timeline (all the days shots) and there is another timeline - selects. From selects, you create a third timeline, edit 1. THen another one, edit 2, and so on... each time you sort of sift through the previous timeline and insert into the next one, always having the ability to go back to the previous one(s) and pull more footage, to change something, etc.

If not doing it this way, by means of "many timelines", how else is an editor supposed to work? Do they go through all the footage in the media pool, in various bins, watch it in the viewer, then what? Do they create subclips, do they directly insert into a "selects" timeline? I don't get it how are we supposed to pull what's good, where do we temporarily put it and how do we easily manipulate it around... With an ease of always comparing different versions, adding to what has been assembled, etc?

Just to be clear, Bin Syncing and Sync Bins are two separate but related things.

I kind of figured this one out - I dump all the footage and audio into a "temp" bin, select, auto sync and finally put everything back into appropriate bins (footage into days > cameras > cards, audio into source).

Yes I get this but, having tried both "workflows", I really strongly feel it is mUCH easier to have them side by side, insert (copy) from one timeline to the other and move from there.

I gave it an honest shot to try it differently in Davinci today. Literally spent the whole day going through the clips organised into various bins, watched them in the source viewer, pulled good "takes" as subclips and when done, assembled it all in a timeline on the EDIT page. Felt WAY clunkier, stumbled upon many obstacles (like subclips getting thrown in the master bin instead of a proper footage bin).

There's tons of things that are clunky about the current implementation and some just come from the fact that the Cut and Edit page's are separate. The Cut page has source monitor that allows you to trim more precisely but it won't let you create Sub-clips. You need to go into the Edit page to do that. Then when you want to view a bin in the Source Tape view, you need to go back the Cut page. That's annoying.

If you create a sub-clip by right clicking the transport area of the Source Monitor and selecting Create Sub-clip or by using a keyboard short cut, then it puts the sub-clip in the same bin as the source clip. You can alternately create a sub-clip by dragging the video from the source monitor to a bin but, unless you have both bins open at the same time with a Dual-pane Media Pool, it navigates you to the new bin and you have to back out to get back to your original clip. That's not an issue if you're creating your Selects in the Media Page (another advantage of actually using the Media Pool and Source Viewer) but it's kind of pain if you're doing them in the Edit page.

I'm not saying the current implementation of anything is perfect but these issues won't get solved if workflows that don't use most of the interface are embraced. Combining the two pages (and the Fairlight page) would do so much to make things less annoying while increasing the discoverability of features in Resolve.

The small sub-clip issue you had could be solved with a keyboard modifier that lets you drag sub-clips into a bin without navigating to it. A more interesting idea, at least in my opinion, would be to be able to temporarily set bins as targets/destination for certain operations. That would allow you to use a macro or button to quickly create a sub-clip and store it in a particular bin but that target could also be used to quickly move or copy clips. That could be really useful in projects with a lot of bins that got out of control.

Perhaps Media pool and source viewer have found a better, more human-friendly use? Two small monitors, preview in one, insert into timeline2 and watch in monitor 2... I don't know. Seems friendlier and quicker to me.

The way you're describing it makes at sound like you think it would be easier to have multiple Source and Timeline viewers for different timelines. How would that more more human-friendly? What's not human-friendly about what I described?

There's a stringer timeline (all the days shots) and there is another timeline - selects. From selects, you create a third timeline, edit 1. THen another one, edit 2, and so on... each time you sort of sift through the previous timeline and insert into the next one, always having the ability to go back to the previous one(s) and pull more footage, to change something, etc.

That sounds intensely messy and over-complicated.

If not doing it this way, by means of "many timelines", how else is an editor supposed to work? Do they go through all the footage in the media pool, in various bins, watch it in the viewer, then what? Do they create subclips, do they directly insert into a "selects" timeline? I don't get it how are we supposed to pull what's good, where do we temporarily put it and how do we easily manipulate it around...

There's no Selects timeline, it's a Selects folder. The whole point of a Selects timeline in pancake editing is to store only the good takes, clips, or parts of clips in a way were the editor can just scrub through those clips to find what they need quickly. Sometimes the clips will even be color coded for notations purposes. A Selects timeline is not an actual edit, it's a timeline being used as a bin.

When you have the ability to make sub-clips and store them and other clips in a bin, color code them, and scrub through them as if they were all contiguous on a tape, then you don't need a Selects timeline. Another bonus of actually being able to use the Source View to trim and import clips into your edit is that you can create ins and outs that span multiple clips without actually effecting the ins and outs of your sub-clips. That even applies to Premiere Pro's way of opening a Selects sequence in the Source Viewer.

With an ease of always comparing different versions, adding to what has been assembled, etc?

My point was that pancake editing is a hacky way of editing, not that it's bad method of comparing timelines, but it's not quite as informative as the actual feature that Resolve has for timeline comparison. Open a timeline, then right click on a second one in the Media Pool and select "Compare with Current Timeline". A new window will show up that juxtaposes both timelines with lines showing you where clips have moved. You also have the option of viewing the Diff Index which shows you a list of the different ins and outs, you can keep the playheads synced with each other and change the base video tracks being used for comparison. You can even scrub through both at the same time with the current Timeline displaying in the Timeline Viewer and the other displaying in the Source Viewer.

The way you're describing it makes at sound like you think it would be easier to have multiple Source and Timeline viewers for different timelines. How would that more more human-friendly? What's not human-friendly about what I described?

No, either I did not express myself clearly or you misunderstood me . At any given time, the most we are working with is 2 timelines, so two "monitors" are more than plenty. The option to load various timelines into these monitors and quickly switch/insert/overwrite between them is terrific!

There's no Selects timeline, it's a Selects folder.

That's it, NOW you've basically answered my initial question . If I got this correctly, the proper (or one of the proper workflows) could look like this:

• import media;
• organise it into proper bins;
• sync audio;
• sort out metadata, flags;
• scrub through the complete footage, pull selects AS SUB-CLIPS into GOOD TAKES bin (instead of "SELECTS" TIMELINE;
• scrub the GOOD TAKES bin, compose edit timeline(s);
• lock picture;
• audio and color post;
• export for delivery;

Does this look right? Let's disregard revisions for this time. Cheers!

No, either I did not express myself clearly or you misunderstood me . At any given time, the most we are working with is 2 timelines, so two "monitors" are more than plenty. The option to load various timelines into these monitors and quickly switch/insert/overwrite between them is terrific!

Oh I see. That feels to me like solving a problem downstream and then adding something upstream to justify keeping the downstream solution.

There's no way I'm describing that well so let me explain lol

If there's only two monitors and both are meant to be pointed to either a clip in a bin, an entire bin, or a timeline, then they're generic monitors. That means that you would have to manually route them all the time. If you wanted to preview a clip that's in a bin, you currently just double click it and it shows in the Source Viewer. If the monitors are generic and both are routed to display a timeline then you wouldn't be able to preview a clip in the bin until you tell it which monitor to display in.

Also think of the implications for the interface. There's are already two timelines, two monitors, and maybe two bins open but now any buttons that allow you to do inserts, overwrites, etc. would have to be doubled since the operations would now have two different directions. That doesn't even take into consideration whatever needs to be added to facilitate the routing or how many new hotkeys that would require to facilitate that process.

The process you seem to be describing honestly sounds less like a selects or versioning workflow and more like actually editing two timelines at the same time.

Now, it's possible that when said " quickly switch/insert/overwrite between them is terrific!" you weren't infering that the edits would happen in both directions. If the intention is just to have one timeline act as a source and the other as a main, then it sounds like it would exactly what Premiere Pro does except with a manual routing step.

That's it, NOW you've basically answered my initial question . If I got this correctly, the proper (or one of the proper workflows) could look like this:

• import media;
• organise it into proper bins;
• sync audio;
• sort out metadata, flags;
• scrub through the complete footage, pull selects AS SUB-CLIPS into GOOD TAKES bin (instead of "SELECTS" TIMELINE;
• scrub the GOOD TAKES bin, compose edit timeline(s);
• lock picture;
• audio and color post;
• export for delivery;

Does this look right? Let's disregard revisions for this time. Cheers!

Yep. That's correct