FR: Add File/Open Project from File...

I know this will be controversial but please try to hear me out.

There have been quite a few "database wars" threads over the years and, with Resolve opening itself up to a broader market, they seem to be getting more frequent. This request is coming from this thread in particular:
viewtopic.php?f=21&t=174906&start=100

There were 119 posts in this thread as I write this.

On the one hand, Resolve has a long tradition of running off a database and many users rely on this.
On the other hand, many users work on multiple machines and want to carry their drive from one machine to another, email their project from place to place, etc. Both of these workflows are quite reasonable.

While it's possible to do the latter workflow with Resolve as it stands, it requires essentially this sequence of steps to go from one computer to another and back:

1. Export a .drp of Project1 from Library1 (on computer 1)
2. Import the .drp into Library2 (on computer 2)
3. Name the project created in Library2 - lets say Project1 copy 1
4. Open Project1 copy 1
5. edit as needed
6. Export a .drp of Project1 copy 1 from Library2 (on computer 2)
7. Delete Project1 copy 1 from Library2 (on computer 2)
8. Import the .drp into Library1 (on computer 1)
9. Name the project created in Library1 - lets say Project1 copy 2
10. Hopefully merge Project1 copy 2 into Project1 so the user doesn't lose Project1's backup history

That's a lot. And that's all for one roundtrip. And it doesn't even attempt to preserve any backups made on computer 2.

In practice, those of us knowledgable enough to handle moving databases around just put the database/Library on a removable drive along with the rest of the project and carry that around, connecting the database as necessary.

BMD doesn't recommend this - and it's understandable as to why. If one isn't really savvy about how this stuff works one can easily end up "losing" one's database - as in not being able to connect it without resorting to pleading on the support forum.

There are other FR's, most notably this one:
that suggest some ways to make finding a database/Library easier. But a simpler, more familiar, less error-prone approach might be to automate the above steps so the user doesn't have to do them.

I suggest making an Open Project from File... command that imports a .drp into a hidden project in the database/Library and opens it in Resolve. No changes need be made to the core underpinnings of the db.

The Save Project command would, when invoked on one of these hidden projects, save (i.e. export) the project to the corresponding .drp. Resolve would delete the hidden project when the project is closed - but preserve any backups such that they'll remain accessible until explicitly deleted by the user or culled by the pruning algorithm.

With this new feature, the roundtrip process would be:

1. Export a .drp of Project1 from Library1 (on computer 1)
2. Open the .drp on computer 2
3. edit as needed
4. Save Project on computer 2
5. Open the .drp on computer 1 and continue using the .drp-based project, or
   Import the .drp into Library1 (on computer 1) and deal with merging or replacing the old project.

I'm sure there are details I haven't thought of but, on the whole, this feels like a workable solution that gives both database/Library and "more traditional workflow" users what they need without requiring much new in the UI or the Resolve codebase.

+1

Not downvoting the request Joe, just clarifying that you realise that the first list is a bit exaggerated. List 1 step 2 + step3 + step 4 is really just one action, 'double click' ... double clicking the project file launches Resolve, imports the project (named per the drp) and opens it ready for editing. So 1, 2, 3, 4, 5 is actually just 1, 2, 3 (per the second list). Still find it a little odd that step 6 (list 1) is proving the contentious one, but judging from responses, folks certainly don't seem to like the idea of having to press Cmd/Ctl-E to save their project file externally vs pressing Cmd/Ctl-S. That said, though your suggestion is as good as any, I suspect folks who really don't want to deal with databases would rather just have an option to hide that aspect altogether vs an option to hide-open a specific project.

Regardless of design (or even with existing design), it would be great if every project had a unique project ID that could be preserved between computers/databases ie a .drp exported on one computer would contain the unique project ID such that if the project were opened on a second, third or forth computer etc that ID would be referenced/maintained ... on open/import, whenever an extant project ID was found in the target database, an automatic option to merge / update and/or 'backup and replace the existing project' could be presented.

Or just use the modern cloud based project sharing solution that BMD are actively developing.

Not downvoting the request Joe, just clarifying that you realise that the first list is a bit exaggerated. List 1 step 2 + step3 + step 4 is really just one action, 'double click' ... double clicking the project file launches Resolve, imports the project (named per the drp) and opens it ready for editing. So 1, 2, 3, 4, 5 is actually just 1, 2, 3 (per the second list).

Andy you're right! I was thinking of the Project History restore workflow which really does require the extra two steps.

Still find it a little odd that step 6 (list 1) is proving the contentious one, but judging from responses, folks certainly don't seem to like the idea of having to press Cmd/Ctl-E to save their project file externally vs pressing Cmd/Ctl-S.

I'm thinking the multiplicity of projects created by this approach might be what irks people the most. Though I could be wrong.

That said, though your suggestion is as good as any, I suspect folks who really don't want to deal with databases would rather just have an option to hide that aspect altogether vs an option to hide-open a specific project.

Regardless of design (or even with existing design), it would be great if every project had a unique project ID that could be preserved between computers/databases ie a .drp exported on one computer would contain the unique project ID such that if the project were opened on a second, third or forth computer etc that ID would be referenced/maintained ... on open/import, whenever an extant project ID was found in the target database, an automatic option to merge / update and/or 'backup and replace the existing project' could be presented.

I love your guid idea. It could as you say ameliorate the multiply of projects. They may even already have a project guid in there.

Or just use the modern cloud based project sharing solution that BMD are actively developing.

All depends on what people accept. Resolve is a big enough learning curve already. If you can tell people they have to set up a network service just to edit on their PC and their laptop and they're happy about it... that's Apple level mojo.

On the one hand, Resolve has a long tradition of running off a database and many users rely on this.
On the other hand, many users work on multiple machines and want to carry their drive from one machine to another, email their project from place to place, etc. Both of these workflows are quite reasonable.

I don't move databases between different systems and I still prefer managing my own project files over the database.

I prefer being able organize project files how I want on my system and even create shortcuts to project files on the desktop for quick access, Windows Explorer is much better than the Resolve project manager for managing files and folders, the database creates a single point of failure so that when something goes wrong with the database you lose access to all of your projects (I haven't had this happen yet myself), when a Resolve update also modifies the database then I have to manually export the entire database and also export each project individually (just to be safe) before updating Resolve, etc.

I love the idea of an internal "hidden database" that we would never have to interact with. It would basically behave like RAM, which only holds open projects and then it would be cleared when Resolve is closed and individual projects would be removed from the hidden database when they are closed. When a Resolve update modifies the database and it requires updating project files, the update process could be handled at the time the project is opened. Then when an old project file is opened, show a dialog window which explains the project needs to be updated to be compatible with the new version of Resolve, then create a copy of the project file (automatic backup) and update the project to be compatible with the new database. This would automatically preserve the old version, just in case they need to go back. All of this could happen inside Resolve's "black box" and we would be totally oblivious to it, which would be ideal.

While the database is certainly is not one of my top priorities (I'm far more concerned about editing features and customization options) the database is a bit of an annoyance that doesn't exist in any of the other editors I've used.

Or just use the modern cloud based project sharing solution that BMD are actively developing.

Yup, this.

the database creates a single point of failure so that when something goes wrong with the database you lose access to all of your projects

Even forgetting that you'll of course have database and .drp backups, that's like saying storing all project files in one folder is a "single point of failure" (which it is, if there are no backups). And note that unless there's catastrophic failure, and every folder in the database somehow gets zapped, you can still go in and rescue your project files if they're undamaged. Copy and paste can work wonders.

the database is a bit of an annoyance that doesn't exist in any of the other editors I've used.

And how many of those other editors allow for collaborative work --- and cloud and network based projects? If you don't need it, the current design may be a nuisance. But the software does have obligations and ambitions beyond home users....

Or just use the modern cloud based project sharing solution that BMD are actively developing.

Yup, this.

That would just be yet another workaround that the growing number of solo content creators are forced into.

But the software does have obligations and ambitions beyond home users....

The solo content creators (who you call 'home users' in what I read as an attempt to belittle any of their claims) are going to outweigh the old user guard more and more every year, so it's advisable to adapt to that target group. Obvious improvements in usability can be made without changing Resolve's fundamentals. Ultimately BMD will have to decide where they see Resolve in the future.

The solo content creators (who you call 'home users' in what I read as an attempt to belittle any of their claims) are going to outweigh the old user guard more and more every year, so it's advisable to adapt to that target group.

You read my intention incorrectly, but the vast majority of new "solo content creators", to use your term, are non-professionals in the industry sense, and the vast majority of those are using the free version. By disappointing these users, not all of whom will find libraries anathema, I'm not sure what BMD stands to lose. While it may lose a great deal by adapting the product in ways at odds with facility practices.

Obvious improvements in usability can be made without changing Resolve's fundamentals. Ultimately BMD will have to decide where they see Resolve in the future.

I don't think that anyone's disputing that improvement is possible and desirable. But how is it you know what you want can be accomplished "without changing Resolve's fundamentals"? You've seen the code:? You've talked to the developers? You've assured yourself that the resources needed to make the change are the best use of the developers' time and consistent with where they want to take the product?

But never mind, this one won't be settled here by us. It's just that you'd think, reading these comments, that local databases are insuperable obstacles, destroyers of hours, joys and careers. It's such a simple matter, and does actually have attractions if you stop fighting and give it a chance.

While it may lose a great deal by adapting the product in ways at odds with facility practices.

Argh. You keep assuming that improvements in usability for new users would worsen user experience of old ones. They don't have to.

I don't think that anyone's disputing that improvement is possible and desirable.

Then why are you constantly campaigning against it? You keep helping everyone who has database trouble, shouldn't you be welcoming any even slight improvement?

You keep helping everyone who has database trouble, shouldn't you be welcoming any even slight improvement?

For all the thanks I get for it, the answer must be masochism.... And yet it annoys the hell out of me that something so simple (and useful) provokes so much -- to my mind, ill-informed -- discontent.

Consider the aggravation on the Edit page, fighting small shortcomings all day -- it could be so much better, and no need for invention, they can get it all from the competition. There's stuff from FCP 1.26 that Resolve *still* can't do, simple things like just ordering the bins and files however you want. The haste of development, I guess....

But libraries? They actually *are* convenient, and it's so easy, with a little effort, to make the accommodation, in the interest of consistency with their facility working model and the ambitions of the Resolve project in general. But folks just refuse, it simply must be the old way....

But whatever..... that's it for me on this subject.

Here's a video of what I think the .drp workflow looks like at present - that is if someone wants to pass .drp files around to either share an edit or edit on multiple machines without setting up a networked solution:

that's like saying storing all project files in one folder is a "single point of failure" (which it is, if there are no backups).

How many database related problems have you seen here on the forum vs operating system folder related problems?

I don't think that anyone's disputing that improvement is possible and desirable. But how is it you know what you want can be accomplished "without changing Resolve's fundamentals"?

Because the suggestion is to preserve the current database structure but have one internal database hidden inside Resolve that is abstracted away from the user to work with project files. All of the database management tasks can be automated.
Open (and double-clicking a project file): imports the project into the database and opens it in Resolve
Save: exports to your currently open project file
Save-as: exports a new project with a new name
Close project: removes the project from the internal database
Close Resolve: removes all projects from the internal database (like RAM)
There is only one instance of your project that you need to manage because the internal database is cleared when the project is no longer in use.

From the user's perspective, this would behave just like any other application because open, save, save-as, and close all behave just as you'd expect. You can move these project files around as you like, put them anywhere on your system, you can create shortcuts to them, launch them from external hard drives, share the projects with other users, etc. all of the database management is done automatically by Resolve and hidden away from the user.

For anyone who needs the database collaboration features, all of that is still there and accessible. The internal hidden database simply will not be used if you are working with projects from another database.

Everyone is happy!

...[It] does actually have attractions if you stop fighting and give it a chance.

Speaking for only myself, but it doesn't for me. Not at all. All of the attractions are for collaborative features, which I do not need and it only takes away things I actually used (like shortcuts for example) and adds more time to upgrades to export the database and individual projects, etc. None of these things are attractions.

And yet it annoys the hell out of me that something so simple (and useful) provokes so much -- to my mind, ill-informed -- discontent.

It's only "useful" if you need the collaborative features, if you don't it's not useful. And I'm sure it is "simple" for you after years of use and dozens (or more) of replies to people helping them with their database problems. I was a brand new user myself about a year ago and I wasted a lot of time futzing around with the database to make sure I knew how to handle it. While I feel I have a good handle on it now, it was certainly time wasted when I wanted to focus on Resolve and particularly Fusion... but I wanted to makes sure I knew how to manage my projects first. This can be done so much simpler without breaking any of the collaborative features.

Sounds good, lezz go!

Up to BMD! They see all these requests so we can hope!

There are two problems with the cloud based solution

1) It costs $5 a month. Although thats pretty cheap, it's still a bit unnecessary just to move a project between machine

2) It involves having to relink media

Although I think there are some really good ideas here, it could be just as simple is making the databases simpler to use

Since my issue arose from databases going missing and projects not updating on an External hard drive here are some additional thoughts

1) simplify the project and database directory trees and keep them in the same root folder.
2) Eliminate the "guest" and "admin" folders. I'm an admin, why is my project in the guest folder? see screen shot from one project library that has multiple directory project paths. This is an insane layout. Cleaning this up reduces a ton of confusion. "Project" and "Project Library" as separate folders?? come on man....

Screen Shot 2023-02-12 at 9.27.39 AM.png (666.7 KiB) Viewed 1192 times

3)Heres a screen shot of a project backup folder. Theres no easy way to determine which project.db file is the one to connect to if restoring a back up is necessary. File names are listed by time not by project or database.

Screen Shot 2023-02-12 at 9.33.25 AM.png (383.25 KiB) Viewed 1192 times

Just some basic house cleaning at the directory level would be extremely helpful. I know it irritates some users to invoke other NLE's but think about how Premiere creates a new project. It provides one window where the user enters project name and where the project should be located. Once its set up you can forget about it. The resolve directory tree is just way overly complex.

Screen Shot 2023-02-12 at 9.39.39 AM.png (456.6 KiB) Viewed 1192 times

Contrast that to resolve where once the database is created, the user has to go into setting menus to direct resolve where to place project and database backups. and even then its tough to know if youve covered everything until you lose work.

Ultimately the main objective though is to make Resolve a portable NLE, that can plug and play easily on different machines. Resolve grants 2 seats when purchasing a license. So moving databases and projects between those 2 seats shouldn't be complicated.

Hi George
Here's where there is a disconnect between your understanding and what's intended by BMD.
The db/Library is everything under Resolve Projects. It's supposed to be a black box that we don't look inside of. They totally reserve the right to change any of it. Looking inside it is like looking inside a project file. Really they should make use of the package feature on MacOS so that it looks like a single file and you have to use the "Show Package Contents" Finder command to peek inside.

[Peter Chamberlain]

The incorrect assumption here is that a drp can be opened. It can only be imported into a project library.
It can’t be written into as a incremental update so no live save, will be slow to save manually, just look at export time, and fundamentally breaks the “projects live in libraries “ operation.

I don’t think I quite understand your post Peter. I’m not sure if I’m misunderstanding what you’re saying or I haven’t been sufficiently clear in what I’m suggesting as a feature request.

I haven’t found an assumption here that drp’s can be opened. The FR is to add an Open command that simulates opening a drp in the same way that double-clicking on the drp appears to open it, and a Save command that knows the project was “opened” from a drp and Exports to the drp in that case.

As to save speed, doesn’t auto backup just export a drp? If so then save should be the same speed as an auto backup.

I certainly wouldn’t expect Live save to save to the drp. I would expect that to save to the db just as it does now.

I haven’t found an assumption here that drp’s can be opened.

Yes, in my early comments I was also talking about drp's having the appearance of being opened to the user, while internally Resolve would create a db file and import it into the database/library. Resolve could provide open, save, save-as, and close options for drp's and then automate everything under the hood in order to get it in and out of the database/library.

Regarding live save, the incremental saves could be done to the internal hidden db file and then automatically saved to the dpr when the project or Resolve is closed. If Resolve is forced closed outside of normal close operations (power outage, crash, etc) then when Resolve is opened again it would still have the internal db file in its internal database/library (only the normal close operations would remove it), so it could prompt that Resolve was closed unexpectedly and provide an option to save the internal db file.

Was recommended here from another thread. I’m not an expert on exactly how the database system works, or whether or not it’s absolutely essential to the code of how Resolve functions. But I’m wondering, would it be possible to create a parallel system that co-exists with the database system? Meaning, something like a Davinci Resolve standalone project, with a different file extension. For example, call it a .drps. Users would have the option to save their projects to this .drps file, and read directly from it. The database system would still exist, and the standalone project would not be without its flaws, but could exist for those who need it.

My idea is similar to the idea of a “phantom database” suggested earlier, though I’m wondering if it wouldn’t make more sense to just skip the concept of a database altogether. Again, not an expert on how resolve handles read/writes, so maybe it wouldn’t. Either way, I certainly think a separate file type would be necessary to avoid confusion, that way the new “standalone project” system could coexist alongside the current project database system.

There’s no need - as far as I can see - for a different file type. A drp can currently be imported into Resolve. My suggestion adds an ability to open the same drp.

Why would you want another file type? That would reduce flexibility as you’d be able to do some things with one file type and others with the other.

+1