Chad Capeland wrote:I don't see how it being a database matters. What's it storing for time values? Four 8-bit integers (h:m:s:f) per entry? That's 32 bits. You could store that as a 32-bit float and represent a project timeline 76 hours long at 60fps timecode with exact integer precision.
I wish it were that simple. There are similar problems with other kinds of software, so this is not confined to just Resolve.
One key I think is to understand the limitations under which you have to work and then find a way to accomplish what you need to do. Otherwise, you're asking a boat to drive down a freeway. From my point of view, you'd be better off choosing a car instead of a boat and just using that.
I'm not a programmer, but I've used an awful lot of editing systems and color systems in 30 years, and frame rate is one of those lynch-pins that holds the entire structure together. The risk of tampering with that is that things can fall apart very quickly. If every frame of every shot could have 1000 different parameters (not impossible, when it comes to sizing, color, keys, composites, effects nodes, and so on), but now the rate at which these parameters change has changed, and relative number of frames has changed, then there's going to be a huge amount of math to be done.
It could be worse: in the early days of HD, where we were dealing with 1080i projects, 720p projects, 25fps projects, 24fps projects, 29.97 projects, and 30fps projects, and then people wanted to use several of these kinds of shots in a single project... it was invariably a trainwreck. At the least, horrible visual artifacts would result. Timings changed. It's always much preferable to make an informed decision on what speed you want at the beginning and then stick to it for that specific project. That's Workflow 101.