As Alex points out, though this patent was submitted in 2009, it clearly shows some elements like Timeline Index, Magnetic Timeline and Auditions which would eventually find their way into X 3 years later.

The idea of narrative story structure begin represented in the edit software for the purpose of segmentation and collaborative editing is very interesting. Scenic Auditions? Yes please!

Alex Gollner"Structure applies to feature films, TV shows, groups of corporate videos on an intranet, legal video depositions, architects’ video proposals or open-ended weekly web series. The more video applications can have these structures encoded in their projects, the better the tools they’ll be able to provide to a wider range of people all over the world."

I couldn't possibly disagree with this statement more. Since structure is fluid and dynamic what is required is a system that is totally open and pliable, able to be shaped to whatever structure can be imagined. Encoding structure into a system will inherently limit the structure to those imagined by the encoders.

"A story should have a beginning, a middle and an end, but not necessarily in that order."
Jean-Luc Godard

I think we should consider a differentiation between creative structure and nuts and bolts delivery structure.

I agree with you completely that structuring embedded in an NLE shouldn't inhibit creativity- absolutely.

But what if the structure is more to do with specifics of a broadcast delivery (commercial breaks), or even a TV series own internal, repetitive structure.

Pragmatically, any corporate video series, or commercial series, or TV series has repetitious elements. Making those things a known commodity in the structure of an edit- especially if these are things you can customize... that's interesting.

[Marcus Moore]"Pragmatically, any corporate video series, or commercial series, or TV series has repetitious elements. Making those things a known commodity in the structure of an edit- especially if these are things you can customize... that's interesting."

If when you start a project you have the option to start with a blank page or open a project template where you've defined segment lengths, commercial breaks, lower3rd and inter-title styles, broadcast safe parameters... I'd like to see that.

I would welcome some kind of story level range marking. I often cut docs with 'scenes' in mind, and the ability to quickly re-arrange those scenes to try out new story arrangements would be great, even if some finessing of the joins was needed later. It's kind of formalising my 'post-it note' method of working out the arc of the narrative.

_________________________________

Before you criticise a man, walk a mile in his shoes.
Then when you do criticise him, you'll be a mile away. And have his shoes.

[Marcus Moore]"If when you start a project you have the option to start with a blank page or open a project template where you've defined segment lengths, commercial breaks, lower3rd and inter-title styles, broadcast safe parameters... I'd like to see that."

That's called a project template. Since most of my work is episodic TV every series has a blank project template that contains the graphic styles, timeline and output styles, and every other standardized feature for the show. You start a new show by duplicating and renaming the template and away you go. If you wanted to include a timeline that had pre-determined commercial break bumpers and slates, no one would stop you. I've worked this way in every NLE I've used - what's missing?

To be fair, I think you could have made the same "what's missing?" statement about the bins and sub-clips structure in Legacy, until ranged key-wording and Smart Collections came along.

I too am working from a template project for this series, but it seems to me to be an analogue solution to what could be a more seamless experience. Theoretically.

This type of thing only makes sense where there's lot of repetition. Of assets. Of structure. But there's loads of scenarios like that. Like the 39 episodes of this show I'm cutting. Or the 70 quarterly fund manager updates I do.

If you could define what a project is (common assets, default transitions, graphic inter titles and lower 3rds), then common quick keys would apply those elements because FCP X knew they belonged to a particular job. COMMAND-T just doesn't give you a basic title, but a title in the right font with the right style and right build- because you've defined it.

[Marcus Moore]"To be fair, I think you could have made the same "what's missing?" statement about the bins and sub-clips structure in Legacy, until ranged key-wording and Smart Collections came along."

Yes, but that the point. Key wording and smart collections ARE new. defined templates are not. I will agree that it isn't a keystroke defined operation. But it's close. In legacy all my lower thirds, as well as slates, were motion templates. It wasn't CTRL-D, but it was basically 2 mouse clicks and the blank title was ready to be filled in; all fonts, colors, backgrounds, positioning and animation pre-defined.

What this patented software seemed to be interested in was the setting up of a hierarchy of structure so that you could easily assemble and re-arrange the different parts. Which is why so much of the patent had to do with joining the overlaps between 2 segments.

I think most modern NLE's have the tools to do this already. This software seemed to be designed for non-editors to be able to restructure a show - a way for the producers to avoid dealing with editors once the scenes were cut.

[Herb Sevush]"This software seemed to be designed for non-editors to be able to restructure a show - a way for the producers to avoid dealing with editors once the scenes were cut."

But they would still need someone who knows the NLE to do this 'restructuring', right? Are you saying they could use someone with less experience or no developed creative voice and the producer could just ask them to do this that or the other? What to save a buck? Or am I not getting your point?

[Craig Alan]"But they would still need someone who knows the NLE to do this 'restructuring', right?"

Why would an editor need that software to do the restructuring. It's easy enough to move sections around with any existing NLE. For instance I had just had a producer ask me to move a "quick tip" segment, including graphic bumper, lower third, music sting and multiple audio and video edits, from the break between 2 recipe segments to a spot in the middle of the first recipe. Took me about thirty seconds to do it in Ppro, would be the same in any NLE I've worked with (Bill Davis might say that X could do it in :05). So why would I need specialized software to do that? I was just guessing that the software was created to let non-editors mess around with structure, or else who is the market for it?

[Herb Sevush]"Why would an editor need that software to do the restructuring. It's easy enough to move sections around with any existing NLE."

Herb what you said was:

This software seemed to be designed for non-editors to be able to restructure a show - a way for the producers to avoid dealing with editors once the scenes were cut.

They wouldn't need any given NLE. Hell they edited movies before there were computers. But unless the templates were applied from a list, you would need someone to create them and then someone to use them.

[Herb Sevush]"I've worked this way in every NLE I've used - what's missing?"

This is more than a template, at least it seems that way to me.

Have you made a compound clip in FCPX, and then opened that compound clip? That's how I see this working.

You are working in segment 1, I'm working on segment 2, and someone else is working the third. Our timelines are part of a whole timeline, and our timing is locked (just like the ins and outs of a compound clip in FCPX today).

All of our work is then stored in a master timeline that a fourth editor could master, add interstitials, or other.

The X timeline structure is absolutely suited for this. I'm not saying other NLE's couldn't do this, I'm sure they can on some level, but X already has the foundations to do this today. Now, we just need a true collaborative way for multiple people to work on a Library at once. nyuk nyuk nyuk.

[Jeremy Garchow]"Have you made a compound clip in FCPX, and then opened that compound clip? That's how I see this working."

If you look further up the thread I specifically asked about compound clips. I'm not surprised that they would work well for this purpose - although I might find the absolute length thing a bit of a straight jacket to work in, often I need to expand in order to contract - I'm just questioning the need for this new patented Apple software. If, as you say, X can do all this already - then what's the big whoop-de-doo - story structure diagrams?

The difference between what I'm suggesting is the same as the difference between changing individual clips in the timeline and existing Audition clips.

Select a group of clips that make up the sequence you want to version. Right click and MAKE SEQUENCE AUDITION.

Immediately your current cut of those clips is saved and a duplicate version is created. Now you can edit away at those clips any way you like, not in a compound but right in the Project timeline. They'd have to be bounded somehow, like with a Storyline container or colour or something to signify the clips that make up the sequence. It can be longer or shorter. With different A/V bleed in/outs. Different music.

Then when you want to bounce back and forth between the versions just use the same command key CTRL+OPT+arrows.

You're right there's a lot of stuff in this patent that's hard to see how it plays out.

Before any of this though, I'd like to see a better connection between media in the Project and the Event. Have new metadata that's added to Event clips filter down to parts already in a Project, or have metadata (like Roles) you add in the Project filter back up to the Even (and all subsequent instances).

Again, it's not that these things can't be done in other NLE's, it's that FCPX's particular (peculiar?) structure lends itself to this style of working. Many editors working on a Project (and I mean Project in the FCPX definition of the word), but staying separate in their own timeline interface.

It reminds me of that article where the editors were saying that they don't have enough time to edit the entire film by themselves because they can't even get through all of the footage, so they have multiple groups of editors working simultaneously on one film. Now, I can't find that article.

[Herb Sevush]"although I might find the absolute length thing a bit of a straight jacket to work in, often I need to expand in order to contract "

Eh, details...

[Herb Sevush]" I'm just questioning the need for this new patented Apple software. "

That's why this forum was created, and it's why Apple made FCPX so they could patent it. You want a reason why they changed all the terms and conventions? There it is.

[Herb Sevush]"I'm arguing that FCPX has most of the good features in it already and this other software is not very necessary - what are you arguing?"

The building blocks of these features are in FCPX, and apparently Apple just won a patent that sort of relates to some of the ideas that seem to be somewhat present in FCPX, but currently you can't do. If it quacks like a duck...

[Herb Sevush]"Except this patent was applied for in 2009. It preceded X, not the other way around."

I don't think this patent and FCPX have to be mutually exclusive. Why can't this patented technology become a part of X, or why can't it be a part of X already even if was applied for in 2009? Wouldn't that disprove that Apple is walking back the design of FCPX, but rather, had this plan all along?

Then it could be a duck... that Apple will keep locked up behind bars forever. ;)

I had some high hopes when Apple purchased what would become Color and FCP Server and all of those hopes crashed and burned pretty quick. Looking at what Apple has shed in the past (Shake, Color, FCP Server, DVD SP) and, to me, one thing they all have in common is a lack of broad user appeal. If it doesn't apply to the majority of their targeted user base then I don't think Apple's wants to put much muscle behind it.

[Jeremy Garchow]"It reminds me of that article where the editors were saying that they don't have enough time to edit the entire film by themselves because they can't even get through all of the footage, so they have multiple groups of editors working simultaneously on one film. Now, I can't find that article."

Multiple editors working are different sections of the same TV show or film is common enough that we don't need the link as supporting evidence. ;)

One show I worked on would typically have 3-5 editors working on each episode (each one gets an act) and this was on Avid and ISIS. Everyone would work in the same project but each editor would have their own timeline (one for each act) and whenever an output needed to be done the AE would take all the individual acts and put them into a single timeline that had the proper slates, blacks, etc., and calculate all the timing information.

If FCP X eventually had a multi-editor ability so that each editor could work inside a compound clip and all the compound clips where in the same timeline (which would have all the proper blacks, slates, etc.,) that would making doing outputs much faster and easier. There still would be some prep time (calculating running times and updating slates) but it would be much more straight forward than what has to happen currently.

[Andrew Kimery]"ne show I worked on would typically have 3-5 editors working on each episode (each one gets an act) and this was on Avid and ISIS. Everyone would work in the same project but each editor would have their own timeline (one for each act) and whenever an output needed to be done the AE would take all the individual acts and put them into a single timeline that had the proper slates, blacks, etc., and calculate all the timing information.

If FCP X eventually had a multi-editor ability so that each editor could work inside a compound clip and all the compound clips where in the same timeline (which would have all the proper blacks, slates, etc.,) that would making doing outputs much faster and easier. There still would be some prep time (calculating running times and updating slates) but it would be much more straight forward than what has to happen currently."

[Craig Alan]"Do you create these templates or do the producers/head writer (show runner) give it to you?"

Craig, I'm guessing your asking me this question. AS a suggestion, on this forum, especially with long threads, its advisable to refer to a name, or quote the original post so we know who you are referring to.

In any case if this is a response to my post then the answer is I create the templates as part of my job as post supervisor. The graphic packages are given to me by the producers, along with theme music and any other standard elements for the series. Choice of post workflow is mine, I incorporate those elements into a generic project and send that project file to the editors, along with a folder of elements.

[Herb Sevush]"Craig, I'm guessing your asking me this question. AS a suggestion, on this forum, especially with long threads, its advisable to refer to a name, or quote the original post so we know who you are referring to.

In any case if this is a response to my post then the answer is I create the templates as part of my job as post supervisor. "

Yeah Sorry bout that. Since mine was a reply to yours and I mentioned template...but the way its displayed it is not obvious.

Thanks so much for your response. I wish we'd talk more about workflow and the craft of editing. There seems to be this new mantra that the broadcast/major film editors are such a small niche and that their needs are so rarified that why would anyone pay attention. But I think their practices were developed from years of trial and error and input from highly skilled creative people. I worked in broadcast as a writer and did get called into the edit bays by a director or producer. The editors would create "auditions" that were suggested so fast that I learned nothing of how they did them but did process some of the workflow.

Getting back to the discussion - this is what I remember. That someone, in this case you, would create the template. So pretty much after the test shows and the pilot, the pattern would be in place. This also mirrored the script writing in which you needed to write x number of pages with specific breaks for commercials. They called it an act structure but it was not for creative purpose.

Anyway, you're finding that compound clips in FCP X can provide everything that is needed in terms of this template that you hand off to your team of editors? Is your production team all in with FCP X? Or are you saying, "every NLE can create these and in FCP X its done with compounds? What more would you need?"

[Craig Alan]"you're finding that compound clips in FCP X can provide everything that is needed in terms of this template that you hand off to your team of editors? Is your production team all in with FCP X? Or are you saying, "every NLE can create these and in FCP X its done with compounds?"

The latter. I don't use FCPX, I'm aware of it's features and would think that compound clips for each segment, joined together on a master timeline, would make restructuring super easy. I am saying that any NLE I've worked with can handle this sort of workflow. I don't get the need for editing software that specializes in structure. It would be like designing spoons that specialize in soup - you can eat soup with any spoon, and if you can't then your not using a spoon.

[Herb Sevush]"I don't get the need for editing software that specializes in structure."

Assuming Apple has any intention of using what's in this patent… I'm more inclined to see it as utilizing something like iMovie's Trailer Templates… though not as "locked down". Say all your shows acts lived in template objects which could be edited individually at the same time, but also all be shared/contained in a "Master" timeline which could be assembled/fine tuned etc. And. Like iMovie templates, could be converted to movies (a regular timeline) if needed. Like compound clips with more features. Who knows. More likely it's just another patent that nothing will come of. ;-)

-------------------------------------------------------------

~ My FCPX Babbling blog ~
~"It is a poor craftsman who blames his tools."~
~"The function you just attempted is not yet implemented"~

[Herb Sevush]"It would be like designing spoons that specialize in soup - you can eat soup with any spoon, and if you can't then your not using a spoon."

Maybe the joke went over my head but there are soup spoons (which have a different size and shape than teaspoons). There are also dessert spoons, egg spoons, iced tea spoons, grapefruit spoons, tablespoons, etc.,.

Generally speaking any of the major NLE's can be used to edit, but each one is different enough that it may be better, or worse, at specific workflows. To some people those differences make a difference and to other people they do not.

[Franz Bieberkopf]"If nothing else, I like to think of this forum as one long demonstration on the weaknesses of analogy in argument. It never disappoints in that respect."

I like to think this forum often demonstrates that weak analogies and poorly chosen metaphors reveal lazy thinking; my latest attempt being a prime example. On the other hand metaphor and analogy are, in every culture I'm aware of, one of the primary tools of human communication, and while less accurate, in some ways, than mathematics and logic, are generally much more fun. When chosen wisely.

[Franz Bieberkopf]" re: "structure" in NLEs ... I wouldn't want to throw out the baby with the soup. From what I have seen, all of them could use more development in terms of "grouping" clips in the timeline."

As to story structure and NLEs - I'm not saying there isn't room for improvement, I'm merely saying I don't understand the need to develop software with that as the core interest. But then again, as my family reminds me on a near daily basis, I'm often wrong.

[Herb Sevush]" On the other hand metaphor and analogy are, in every culture I'm aware of, one of the primary tools of human communication, and while less accurate, in some ways, than mathematics and logic, are generally much more fun. When chosen wisely."

Herb,

I guess I think of analogy as a rhetoric tool (for argument) and metaphor as a literary device (form).

In that framing, analogy is useful where the audience is unfamiliar with the terms or subject at hand, but will inevitably fail under any sort of scrutiny, and thus requires both a charitable reading and that it be abandoned at some point.

I was about to say "Metaphor is fire metaphorically speaking," but I don't know that I've ever seen a metaphor in this phorum.

You used the word "analogy," but the word more closely twinned with metaphor is "simile," which is built around "like" and "as." And indeed, most of those posts begin, "It's like a car" or something similarly simile-esque.

[Herb Sevush]"The latter. I don't use FCPX, I'm aware of it's features and would think that compound clips for each segment, joined together on a master timeline, would make restructuring super easy. I am saying that any NLE I've worked with can handle this sort of workflow. I don't get the need for editing software that specializes in structure"

Ahhh. Got it. This is of interest to me.

So you feel that the glut of media that is taking place now, even compared to just a few years ago, can already be well managed/organized by any of the NLEs?

Isn't the first thing you do after production wraps or even before, is go through your clips (you meaning you and all the editors and assistants that work with you) and sort them out and label them in some form or other. You don't see any steps forward in how FCP manages this process? You do not find it helpful, as one of a ton of features like this, that now you can tag clips in the finder and its imported as a keyword collection?

I would say FCP X specializes in metadata and organization rather than structure. Or is that what you mean by structure? I think its structure is still in early stages of development.

One feature I used in FCP legacy, for example, that really needs to be there is to make custom layouts of the program that you can easily toggle between. Color correction - keyboard shortcut: scopes open, my viewer a certain size, the inspector open and on the visual tab, the browser and library windows closed, the audio meters closed, the effects browser open. Now I have to open and close all this stuff and resize it and its tedious.

[Craig Alan]"Isn't the first thing you do after production wraps or even before, is go through your clips (you meaning you and all the editors and assistants that work with you) and sort them out and label them in some form or other"

The show I work on records to AJA Ki-Pros and all the clips are meaningfully labeled as we shoot. AJA makes special control software that enables us to do that. While I realize that X has great tools for post logging, I don't really need them.

[Craig Alan]" You do not find it helpful, as one of a ton of features like this, that now you can tag clips in the finder and its imported as a keyword collection? "

A typical clip would come to me named C1514R_213, which tells me this clip is from the C camera (we use 5 cameras) season 15 episode 14 (we've been doing this a long time), the type of segment is a Recipe and its the 213th clip we've shot during production. The continuity department has sent me a notebook and using that clip number I know exactly what part of which recipe (most episodes have 2 recipes) it belongs to, what day it was shot on, what other shows were shot that day, and what the directors and producers comments were about that take. What exactly would I need keywords collections for?

[Craig Alan]"One feature I used in FCP legacy, for example, that really needs to be there is to make custom layouts of the program that you can easily toggle between. Color correction - keyboard shortcut: scopes open, my viewer a certain size, the inspector open and on the visual tab, the browser and library windows closed, the audio meters closed, the effects browser open. Now I have to open and close all this stuff and resize it and its tedious.To me that's kinda of a structural thing. Ergonomics."

That's not story structure, which is what the software that started this thread was concerned with. On the other hand I agree that custom screen layouts tied to shortcut keys are an excellent feature for an NLE to have.

[Herb Sevush]"That's not story structure, which is what the software that started this thread was concerned with"

"I don't get the need for editing software that specializes in structure."

Oh I thought you were referring to FCP X's whole emphasis on using metadata as a way to organize and build a story line. Not the original post which is a feature that has not been put into X.

Well it seems you could live without either.

But getting back to your example: shot C1514R_213 already comes embedded with metadata from the Ki Pro. Other important notes are passed in with a notebook. No advantage to have these in the NLE? Which take the director liked (favorite the clip and now you can sort the clips without turning to the notebook). Or even just typing in C1514R_213 in the search field rather than scrolling through 213 shots? Or let me just sort all the director's picks and then sort them by angle or subject?

Sounds like your show is a well oiled machine. But I think FCP X has done a good job or allowing you to collect and organize existing and new organizational metadata as needed.

Off Topic: I've been using a Ki Pro now for the last 5 years or so and its been a really useful device in production and post. The first time we shot all week using 3 Pana 170 P2 cams - 1 out the three cams we were using recorded in a frame rate and codec that FCP X could not read. I think it was set to 720 30P instead of 720 60P. In any case, I put the card back into the cam and recorded to the Ki Pro SDI out the cam. Worked perfectly though was no longer broken into clips. It also bypasses HDV compression giving new life to some of those cams. And a lot of the new Macs won't recognize Canon firewire cams. But these cams have a form of component out. Ki Pro again. Rock solid and great customer support. The audio is good on the Ki Pros too though I wish there was better monitoring.

[Craig Alan]"No advantage to have these in the NLE? Which take the director liked (favorite the clip and now you can sort the clips without turning to the notebook). Or even just typing in C1514R_213 in the search field rather than scrolling through 213 shots? Or let me just sort all the director's picks and then sort them by angle or subject? "

I do see the advantages of keywording and if Adobe would add it to Ppro I'd find ways to use it. but I'm not willing to trade customizable screen layouts, much less organizational track layouts to get it. It's all about priorities.

The only repetitive element I've ever had in the TV shows I've worked on has been the title sequence. And that is usually a self contained element. Recently we've made them so that some elements are swapped out that reflect the current show we are one...but that's easy enough without segmenting anything.

But aren't breaks at set amounts of time? Aren't credits given in a consistent style? Transitions/music/effects usually of a certain style in and out of breaks and at the end as well as the beginning of a show?

[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.

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.

... 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).

[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...

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).

The impression I'm getting is that the database type itself only tells part of the story, and the tools used to enter and manipulate data play a big role - that equal "features" might be implemented using different kinds of databases, appearing the same way to the user regardless of kind of database.

On the other hand, it seems the kind of database influences efficiencies and in certain cases makes things possible that are not possible with other kinds of databases. It's hard for me to conceive of an example of the latter (with regard to relational vs. navigational), but no doubt it informs much of development of new models ...

Just to be annoying, I worked for quite a while with Filemaker Pro - which was often described as a "semi-relational" database.

It was largely a flat file structure, but there was a facility to cross-link between what were essentially it's discrete spreadsheet data storage cels to form a uni-directional reporting relationship across the flat file structure.

Just pointing out that I'm not sure that the database nature has to be so binary - flat or relational.

Perhaps it would be better to discuss them in terms of the flexibility of the tools they give the user in order to empower them to do meaningful operations that enhance their access to and use of the data.

The "range-taggging" at the heart of X - giving the user the ability to range select across other selections and allow for the both the discrete and concatenated applied keywords to be accessed at will, is an expression perhaps.

Whether legacy was relational or not (and HOW relational) isn't so germane as the fact that the user wasn't given access to the same type of flexibility in it's implementation.

How I see it anyway..

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com - video editing curriculum complete with licensed practice content.

[Bill Davis]"It was largely a flat file structure, but there was a facility to cross-link between what were essentially it's discrete spreadsheet data storage cels to form a uni-directional reporting relationship across the flat file structure."

Those cross-links (keys) between flat tables are precisely what makes it relational.

[Bill Davis]"Just pointing out that I'm not sure that the database nature has to be so binary - flat or relational. "

It's not binary -- there are other database designs -- but if you have multiple tables in your database that are related to each other via unique keys, you have a relational database by definition.

[Bill Davis]"Perhaps it would be better to discuss them in terms of the flexibility of the tools they give the user in order to empower them to do meaningful operations that enhance their access to and use of the data."

Yes, this is a point I've been trying to make here for some time. While understanding the back-end helps us understand the tool, really the front-end matters more to the user than the back-end.

Really, I think the most important data structure to understand is the timeline. It's hierarchical parent/child design informs the entire relative-time magnetic model exposed to the user.

[Bill Davis]"Whether legacy was relational or not (and HOW relational) isn't so germane as the fact that the user wasn't given access to the same type of flexibility in it's implementation."

Maybe we have a jargon issue. What does "relational" mean to you? What functionality do you attribute to relational vs flat database design?

FCP X has a collection of features that expose data to the user in ways that no other NLE does. Taken together, these features are unique and powerful. It's just the attribution of these features to the design of the database and the implication that other NLEs are not databases that strikes me as odd.

If you promise to stop using the words "relational database" when describing the basis for a new feature in FCP X, I promise to stop pointing out that this design likely underpins basically every NLE ever made. :)

[Walter Soyka]"Maybe we have a jargon issue. What does "relational" mean to you? What functionality do you attribute to relational vs flat database design?
"

That was my intent in bringing up the idea of "semi-relational" in terms of Filemaker Pro.

Could you link some fields in some tables? Yes.

Could you link any field to any other field across tables? No.

So it was "somewhat relational" as with, perhaps, Legacy - compared to X.

If the other players are still itchy about "destructive" then just to end the madness, perhaps I'll consider in the future describing the FCP X the timeline is "ruggedized" compared to it's competition.

Just to avoid too destructive a debate going forward.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com - video editing curriculum complete with licensed practice content.

[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."

[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.

[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.
"

I disagree with this whole heartedly.

The nature of it's relationally is expressed in how the interface allows the USER to deploy range based key wording across overlapping and concatenated selections.

That's not any sort of mere "buzzword." It's the practical heart of what so many editors who understand X even at a very basic level admire about it.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com - video editing curriculum complete with licensed practice content.

Well there's an idea. Put audio tracks above the pic track. That seems like the natural order of things. many years ago I suggested to Fairlight that the tracks should be vertical like dubbing charts rather than horizontal like notation.

[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.
"

It could be a duplicate entry in the table and not necessarily relational.

New paragraph: the databaseyness (sic) of Roles seem to be worth contemplating here too.

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]"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. "

Thanks for taking the time.

I can't suppose prove anything about FCP7's engineering, but since you mentioned Premiere Pro CS6... open a .prproj file in a text editor. It's just an XMLish text file.

Search for "MasterClip". (Period placed literally, not grammatically.) Select the value of its ObjectUID and search on that. You'll find various other objects -- SubClips, ClipProjectItems -- that reference it via this value. You'll subsequently find VideoClipTrackItems that reference the SubClip records by their object reference numbers.

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]"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 don't think it's a safe assumption that the absence of a feature implies the inability of a data model to support its implementation.

[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.

[Richard Herd]"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."

I detailed the evidence supporting a relational arrangement in the file structure of a .prproj in a previous post. I have done a bit of work hacking .prproj files for an in-house media re-linking application and I am quite confident that this data is not duplicated in the project file structure as would be required for flat database storage.

For your proposition and my evidence to both be true, Premiere Pro would have to store data relationally in its project file, read it into memory, flatten the database, then de-duplicate/reorganize and store it relationally again upon save. I find that unlikely.

[Richard Herd]"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!"

Why do you feel Dynamic Link can't work with relationally-organized data?

DL mainly does three things: it is able to peer into a foreign project format to enable the user to select a dynamic link source, it is able to present an element from a foreign project to the local application as if it were project-native, and it is able to intermediate requests among applications for rendered frames from foreign elements.

Everything needed for Dynamic Link to work can be stored relationally in the local project's database, no super-structure required.

Well now we are in the weeds here. I don't post on the weekends, so if you don't look back that's quite all right, and so I won't spend too much time in the case this is dead discussion.

The evidence in the xml document may or may not be a relational database. Nothing in the document requires a relational DB. I detailed a scenario where it could be a single table.

My last project xml-ing between DBs was in 2008, so I am definitely rusty. At Caesar's Entertainment in Northern Nevada we exported slot data and jackpot wins while excluding customer data into a Scala script that integrated into a mograph celebration and audio celebration. We called it "popping the floor." It was many relational databases synced into one video presentation. I did not write the XML document. I created the mograph and audio and I wrote the Scala script (which is VBS).

XML is brilliant at dup and reorganize. That's what it does. Cherry pics data and reorganizes.

Dynamic Link is brilliant. I believe PP is the hub (according to stuff Kevin M has posted, mostly in passing, about using PP as a hub) because it is supposed to be the superstructure. The organizing application. And I've been using it like that since November 2013, and it's simply brilliant. For example, I cut the rough in PP and then line up any mograph elements in the timeline by stacking them. When I import PP project into AE, they are all aligned perfectly and I precomp etc. and then back in PP import that comp and replace. This line of reasoning makes it appear to me as a single table.