[Richard Herd]

Premiere also makes subclips. And you can make those master clips and so on.

[Richard Herd]

[David Lawrence] “[Richard Herd] “X is wholly different. The clips are in projects. This is not simply nomenclature, as I tried to detail.”

Richard, I’m curious to hear more of your thoughts on this. How are FCPX projects not simply sequences with a different name?”

Well…crap. I really thought I wrote it down as logical subsets. My lack of rhetorical skills need honing apparently.

Here’s a place to start from, a data table notion. PP and 7 could be contained in a single table, where the uniqueID is the media. It gets imported and then the NLE assigns it a fancy number, the mediaID.

I will label this table Browser (because that’s what Legacy called it; PP calls it Project). The table I will use here has six fields: mediaID, in, out, sequence, in, trackID

I need to revise it to include audio, so I will add three fields audioIn, audioOut, audioTrack.

9 fields. We could continue to add fields for effects, loudness, opacity, etc.

A single table.

Let’s start with Avid, and although I don’t like the user interface, it’s database is topnotch. It seems to me that Avid has a relational Database where bins have a binID and the data in that can relate to sequenceID, and this is nuts and bolts of sharing bins without importing an entire project.

Now we arrive at X.

Events, Library, Projects are their own tables because they are shareable; we can get data out of it that is not bound like the table scenario mentioned above. From an editor’s point of view it makes sense to say “yeah the project and sequence are just a presto-magico change the name to win the argument.” But from a database point of view, they are actually separate. I guess we can ask “What data are in X’s project table.” And I think that table might/would look a lot like this: libraryID, eventID, projectID, mediaID, in, out, timeIn, Role.

I think it is important for Premiere to keep the data in a single table because it will need to “snap” into a superstructure called Dynamic Link. Which brings up a point about the FCP article, and why the author thinks a flat table is inherently worse. Well it isn’t. And for Dynamic Link it appears to be crucial! In effect, I get to decide how to link tables. In other words, I can make an AE project for titles and such and then “snap” that table into EVERY SINGLE premiere project I choose. In this way Premiere is a hub, the very tippy top of the superstructure.

Another interesting observation is that I can import PP sequences into other PP projects. I’m ruminatin’ whether it is necessary to have a second table or if the above mentioned data are sufficient.

Whew.

[Richard Herd]

[Franz Bieberkopf] “[David Lawrence] “It would be much more useful to coin a new term to describe an irreversible sequence of operations that alters a project. What else might you call it?”

David,

I can only think of “committed” vs. “uncommitted” decisions, or something along those lines.

Franz.”

How about a nice acronym, something that rings true as PIOPs does (pronounced pie-ops). ECTS (pronouces “ex”) for editor committed too soon.

[Richard Herd]

Nicely said.

[Richard Herd]

The guide along with Mr. Ebberts in the scripting forum have been big helps.

[Walter Soyka] “[Richard Herd] “The interesting part is where 7 and PP contain sequences whereas X projects contain clips (as timeline).”

I’m sorry, I don’t follow here.”

It ain’t so fancy. The Browser in 7 contains media and sequences. When the media are opened in the viewer, the IOPs create a clip. Those clips are inside of sequences.

X is wholly different. The clips are in projects. This is not simply nomenclature, as I tried to detail.

(And full disclosure, I haven’t used X in over a year — CS6 kind-of guy these days.)

EDITED for clarity.

[Richard Herd]

[Walter Soyka] “This looks like separate tables, relationally linked via unique keys”

It could be a single table with many fields, which may explain why/how Dynamic Link imports PP projects into AE, but AE comps (not folders) into PP. Why can’t PP import AE bins? (I’m on CS6, not CC, so maybe that’s changed.)

I’m arguing PP (perhaps) requires a single table in order for Dynamic Link to be the relational database. Hopefully, this also means lots more relational stuff for DL.

Last, sorry the long post was so opaque. Getting right to it, I attempted to analyze the data by its container. Sequences, for example, contain clips. The browser contains media. And so on. The interesting part is where 7 and PP contain sequences whereas X projects contain clips (as timeline). Well, if you get a moment to ruminate on that, I would be curious your thoughts regarding databaseyness (sic).

[Richard Herd]

[Walter Soyka] “This would enable two killer features, which I’d think belong under the “Producer” menu:
1. Split the difference
2. Wait, I changed my mind on that other thing I said two days ago”

That is funny!

[Richard Herd]

[Walter Soyka] “Can you illustrate why you think this?”

To be sure you don’t want me to illustrate!

Here’s David’s screen capture I was pondering: https://forums.creativecow.net/readpost/335/70073

The original article states, “Simple databases can’t store the same clip being in two segments. Relational databases can. They can also store multiple representations of the same segment.” This post focuses on the “multiple representations” only.

First let me state it properly. The way 7 handles media is a flat database with many duplicate entries, and the way X handles media is a relational database with many duplicate entries.

It appears to be entailment. Please note I cannot find the html symbols for subset

Media (M);
Clip (C);
Sequence (S);

M subset is C
S subset is C1, C2,….Cn, where n is some number

But this is incomplete, because Sequences can nest.

S subset is Sn-but-not-itself and/or Cn; this is generally accurate for X although there is plenty of room for refining it, and updating the nomenclature.

And now an attempt to redefine for X

X has

Clip (C)
Role (R)

M subset is C and/or R

Library (L)
Project (P)

L subset is P
P subset is M

via P, L subset M subset C and/or R

And now let’s return to the quote above, in part, “Simple databases can’t store the same clip being in two segments.” True, but it can hold a duplicate. But in X, since the entailment (and relation) follow, it can.

It’s not a very pretty illustration, but no one wants me to draw! Very curious for some rigor, critique, and review.

[Richard Herd]

[Jeremy Garchow] “it would take a mess of coding to make that work reliably and accurately”

It’s already stored as 99 undos on the wall, 99 undos, you take one down you restore the destructive edit…98 undos on the wall. 😉

[Richard Herd]

[Walter Soyka] “then lift could perfectly reverse overwrite.”

But it could. It just hasn’t been programmed.