Fascinating article on FCP.co today…

[Franz Bieberkopf]

[Marcus Moore] “The idea of narrative story structure begin represented in the edit software for the purpose of segmentation and collaborative editing is very interesting.”

Marcus,

Having had time to read this properly now, I do think the underlying ideas are important, but they can essentially be reduced to “grouping” and “versioning”.

I think he over-dresses the concepts by calling them “Scenes” and “Acts” etc. and it makes them sound like they have more functions than they actually do, and further skews the importance of narrative vs. non-narrative structures – they’re just groups. It’s a bit like calling a timeline a storyline – if it’s just nomenclature, well sure if you like that flavour, but it doesn’t really address storytelling.

I suppose one aspect of “narrative structure” (and/or non-narrative structure) is being represented in the timeline via groups. (Premiere’s implementation seems alright on this but I do hope they develop it more.)

Versioning (aka “auditions”, “stacks”, “playlists”) is a great concept at both the clip and group level – I’ve yet to see a full implementation though FCP X goes further here than anything else I’ve seen.

Franz.

[Marcus Moore]

You’re right those are the two basic concepts at play here.

In the TV show I’m working on now, I’m using Auditions way more than I have before. It’s just too easy to have a few versions collected for review with the director- different lengths, different overlaps to preceding and following shots. being able to version “scenes”- whether you’d call them a compound, storyline, or whatever- the same way would be very nice.

[Franz Bieberkopf]

… also I’ll ask again, if only to demonstrate Walter’s patience, if not my own incomprehension.

There’s this in the article:

“Simple databases can’t store the same clip being in two segments. Relational databases can.”

I think there’s something he’s not quite saying there, but I’ll try to draw it out with a question. First – clearly, in FCP7 you can have the same clip in two segments, so I’m not sure of the distinction he has made in the first instance (assuming that FCP7 is not a relational database, which I guess should be established even firster).

But, to the point: why not? or why?

Or perhaps to rephrase it simpler (and yet again) – what’s the difference between relational databases and, uh, non-relational databases (which can clearly still relate data)?

Franz.

[Walter Soyka]

[The article] “”Simple databases can’t store the same clip being in two segments. Relational databases can.””

This is correct. A flat database could hold two unrelated, coincidental references to the same clip, but not the same literal clip reference.

[Franz Bieberkopf] “also I’ll ask again, if only to demonstrate Walter’s patience”

I grinned at this!

[Franz Bieberkopf] “what’s the difference between relational databases and, uh, non-relational databases (which can clearly still relate data)?”

I really like Margaret Rouse’s description of a database:
“A database is a collection of information that is organized so that it can easily be accessed, managed, and updated.”
https://searchsqlserver.techtarget.com/definition/database

And a relational database:
“A relational database is a collection of data items organized as a set of formally-described tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables.”
https://searchsqlserver.techtarget.com/definition/relational-database

There’s a pretty good demonstration of the difference here:
https://www.dummies.com/how-to/content/knowing-just-enough-about-relational-databases.html

(Please forgive the intelligence-insulting URL.)

[Franz Bieberkopf] “assuming that FCP7 is not a relational database, which I guess should be established even firster”

Going back to the original quote, my problem is the implication that other NLE databases are flat. I would need to be convinced that were true.

The fact that FCP, for example, had the idea of of master clips [link] suggests that it is in fact a relational database (sorry, Bill); a flat database would require an enormously complex and highly inefficient implementation to support something like this.

I would also suspect Media Composer has been organized relationally since its inception. Unless someone here thinks they can represent the Avid data structure in a single Excel sheet…

Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive   |   RenderBreak [blog]   |   Profile [LinkedIn]

[Franz Bieberkopf]

[Walter Soyka] ” A flat database could hold two unrelated, coincidental references to the same clip, but not the same literal clip reference.”

Walter,

This begs the question – what is the difference between a “coincidental reference” and a “literal reference”?

That intelligence insulting URL was pretty good.

For a broad overview, this is the history as I understand it (via wikipedia):
https://en.wikipedia.org/wiki/Database

“The Oxford English dictionary cites a 1962 report by the System Development Corporation of California as the first to use the term “data-base” in a specific technical sense.”

1960s – navigational databases (including Hierarchical and network databases)
… a sort of “linked list”

1970s – relational databases (later including “entity-relationship” models)
… using tables, the entries of which could be related to one another

By the late 70s, SQL (structured query language) answered some of the needs apparent in the structure and use of relational databases.

1980s – object-oriented databases (including object-oriented relational databases)
… allowed “for relations between data to be relations to objects and their attributes and not to individual fields”

2000s – post-relational databases (including XML databases)
… seem to answer design problems of speed, scalability, distributed systems and data interoperability

Franz.

[Walter Soyka]

[Franz Bieberkopf] “what is the difference between a “coincidental reference” and a “literal reference”?”

I would guess that we all already think about NLEs relationally.

Consider this very basic sequence:

SEQUENCE
First shot: Clip A
Second shot: Clip B
Third shot: Clip A

Along with a very basic bin:

BIN
Clip A: Media file filename_01.mov, frame rate 29.97
Clip B: Media file filename_02.mov, frame rate 24.0

That’s organized relationally, in two tables, where the items in the bins relate to the items in the sequence by means of a key (in this case, the unique clip name).

Now let’s represent it with a flat database:

First shot: Clip A, Media file filename_01.mov, frame rate 29.97
Second shot: Clip B, Media file filename_02.mov, frame rate 24.0
Third shot: Clip A, Media file filename_01.mov, frame rate 29.97

If we want to change a characteristic of Clip A, or if we want to add more information to it, that’s easy with a relational database; just change the Clip A item in BIN, and the SEQUENCE gets it for free by virtue of the key linking the two tables.

It’s much harder in a flat database: we have to iterate through the entire database, identically altering all the records with “Clip A” in them to match the new data (or even altering every single record in the case of a structural change, like adding color space metadata).

Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive   |   RenderBreak [blog]   |   Profile [LinkedIn]

[Walter Soyka]

[Franz Bieberkopf] “what is the difference between a “coincidental reference” and a “literal reference”?”

I failed to actually answer your question with my last post.

I am making up the term “coincidental reference.” In the flat database example, there are two entries that both happen to refer to Clip A, but changing one has no bearing on the other.

In the relational database example, the sequence literally refers to a single clip entity.

Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive   |   RenderBreak [blog]   |   Profile [LinkedIn]

[David Lawrence]

[Walter Soyka] “Going back to the original quote, my problem is the implication that other NLE databases are flat. I would need to be convinced that were true. “

[Walter Soyka] “The fact that FCP, for example, had the idea of of master clips [link] suggests that it is in fact a relational database (sorry, Bill); a flat database would require an enormously complex and highly inefficient implementation to support something like this.”

Bingo, Walter.

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
https://lnkd.in/Cfz92F
facebook.com/dlawrence
twitter.com/dhl
vimeo.com/dlawrence/albums

[Franz Bieberkopf]

B>[Walter Soyka] “The fact that FCP, for example, had the idea of of master clips suggests that it is in fact a relational database …”

Yes, it seems that “relational database” was just buzzword handwaving around the promotion of FCP X – it’s unlikely unique in this respect amongst NLEs … and technology from the 1970s at that.

Franz.

[Walter Soyka]

[Franz Bieberkopf] “Yes, it seems that “relational database” was just buzzword handwaving around the promotion of FCP X – it’s unlikely unique in this respect amongst NLEs … and technology from the 1970s at that.”

Indeed. That handwaving is why I get tablethumping whenever the topic arises.

FCP/Avid/Premiere/Smoke bins (and arguably sequences) look like spreadsheets, so the assumption that they are in fact flat databases is not totally unreasonable, but ultimately considering how the apps work in a little more depth suggests otherwise.

To bring this back around to NLE history, the way that FCP X rolls a DAM into an NLE is new, and I think its hierarchical timeline data structure is novel.

(Does the word “hierarchical” bother the relational database handwavers?)

Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive   |   RenderBreak [blog]   |   Profile [LinkedIn]