Franz Bieberkopf
Forum Replies Created
-
[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.
-
[Walter Soyka] “Once I perform an overwrite, that data cannot be brought back without stepping the entire state back via undo.”
[Walter Soyka] “Here, I am showing an editorial operation that irreversibly alters its source (the timeline, not the media files), cannot be reversed and becomes baked into the file: the project file that is, not the media files. David Lawrence has very reasonably declared the project file as the true digital master; I think that along these lines, the use of the word destructive to apply to media changes only is overly narrow, is inconsistent with its use in other media applications, and undervalues the data in the project file.”
Walter,
I follow your reasoning here, but for reasons well explained by Herb I think the word “destructive” is misleading. I’d suggest something more like “committed” vs. “uncommitted” decisions which suggest more of a sense of whether it can be reverted or changed later (ie. whether some initial state is preserved and can be returned to).
[Walter Soyka] “By your definition [David], there is literally no operation in Photoshop, other than save, that is destructive, because anything else has immediate undo. That makes the word destructive practically meaningless in many of these contexts, because a history stack is now so common.”
I don’t see the problem here. Photoshop makes “uncommitted” changes until you save and lose the ability to undo them. Why can we not call this non-destructive?
Franz.
-
[Richard Herd] “7 seems flat.”
Richard,
From where I am standing, the horizon is relational.
Franz.
-
[Jeremy Garchow] “Wouldn’t that disprove that Apple is walking back the design of FCPX, but rather, had this plan all along?”
Jeremy,
I am continually amused that you assume development at Apple is at root rational and linear.
Franz.
-
[Walter Soyka] “… the way that FCP X rolls a DAM into an NLE is new …”
Walter,
How so?
Franz.
-
[Walter Soyka] “That’s organized relationally, … It’s much harder in a flat database.”
Walter,
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 …
Franz.
-
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] ” 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 anotherBy 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 interoperabilityFranz.
-
… 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.
-
[Marcus Moore] “Thanks for the recap, Franz.”
Marcus,
It’s all Oliver and Michael – I’m sure there’s more from David Lawrence somewhere with the right search … I suppose the thanks goes to Tim as well for keeping the resources alive.
Franz.