[Herb Sevush]

[Charlie Austin] “Nope. Because it doesn’t go out of sync unless you move it out of sync. If need to be reassured it will never go out of sync don’t disconnect it, or comp it to the pix.”

So your argument is that if you want to do an audio only overwrite, just disconnect the audio. But if your worried about the audio ever going out of sync, don’t disconnect the audio. So what if you want to do audio only overwrites (something every editor does routinely) and you worry about audio inadvertently going out of sync (something every sane editor does.)? Use another NLE, I guess.

For someone like myself who always edits using disconnected media, advising someone to work in a timeline without sync indicators is like advising someone with a sore throat to gargle with nitro glycerin. Unless you’ve got something better to offer, then Aindreas’s comments on this issue are still valid.

Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf

[Herb Sevush]

[Charlie Austin] “Except that you can do an audio only overwrite, just like any other NLE. Ya know, with detached audio. “

Just a question by a non-user who always works with detached audio: when you work with detached audio does FCPX provide sync indicators so you can easily maintain sync, just like any other NLE?

Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf

[Herb Sevush]

[Steve Connor] “That’s how I’ve made my audio editing in FCP X much easier, I’ve stopped using music and EFX”

ahh, so that’s your secret. brilliant! and the way you make video editing easier is by not using any video. awesome! now i’m finally “getting” fcpx. I’m sure Bill will be very proud.

Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf

[Herb Sevush]

[Atilio Menéndez] “Of course the whole elegance breaks down as soon as you add some music and sounds and the audio clips end up getting thrown randomly all over the place in a sea of green, but, well, that’s another story.”

No, that is the story, unless you don’t use music or sound EFX.

Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf

[Herb Sevush]

[Bill Davis] “The code base, top to bottom, is newer.”

I’m not sure what this means. The overall design paradigm is unique for sure, but I doubt that it’s code is newer than let’s say Lightworks for OSX, which is just getting written this year.

It also begs the question – is newer code base a criterion for better? Does this mean if some new company, like Resolve, comes out with a fully operational NLE next year it will automatically be better than the then comparatively arthritic 4 year old code of X? Or better still, using this criterion the X of 3 years ago should be better than today’s version because 3 years ago the code was definitely “newer” in all ways.

Beware the curse of chasing after the new, because everything once new now grows old. (for all you Paul Simon fans.)

[Bill Davis] “The software takes advantage of the latest Apple hardware and OS improvements, brilliantly.”

As compared to Avid, Adobe and Lightworks that work on both OSX and Windows and can take advantage of a much larger set of hardware and software options.

[Bill Davis] “and it’s simply more fun to use than other NLE programs. (Source: people I meet who have switched!)”

Ah yes, the fun criteria. Well there it is, that clinches it. Well done.

Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf

[Herb Sevush]

[Walter Soyka] “but is this really harder than actually designing and implementing the feature? Why can’t this work be done in parallel if necessary?”

$$$ – you don’t sell subscriptions based on your documentation. Why do they outsource their help desk to India? Why spend to create your own manuals when many people are happy to watch zero cost self-made youtube tutorials. Garry Huff said he never looks at manuals — I’m guessing he’s in a large majority.

But the thing about good technical writing is that the tech writers add another layer of critical eyes before a product is released – I don’t know of any tech writer who would have let the software designers call a multicam feature “edit cameras” – in a normal documentation workflow the tech writers serve as a crucial, and often annoying, feedback loop for the developers.

The theme of my original post is that there is a cost for everything, and I believe the true underlying cost for quicker release cycles will be disorganization. It doesn’t have to be true, but it will cost more money to fight the additional chaos these quicker cycles bring and I don’t see enough of a constituency for the dollars to be spent.

Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf

[Herb Sevush]

[Walter Soyka] “Whether you are releasing 12 features once a year, or 3 features four times a year, you’re developing, testing, and documenting the same number of features. This should be manageable.”

The difficulty comes in integrating the new information into the old. it is not hard to document a new feature, Adobe does this now with their release notes. What’s hard is integrating, let’s say, a new timeline feature into the already existing chapter you have on timeline layouts. figuring out how to relate the new to the old and present it in a seamless way. Doing that once a year is hard enough, doing that 4 times a year is asking a lot. Again, it’s not about documenting the feature in isolation, it’s about figuring out how and where to integrate the new information into the existing structure, which is why creating a video about the new feature is so much easier than actually revising all your existing documentation to absorb it in a logical way for the user to find and understand.

Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf

[Herb Sevush]

[Paul Neumann] “To see the cameras/angles in the preview/multicam window the clip needs to be in track 1. If the clip is in any other track you can still toggle through the cameras/angles using your number keys.”

Thank you for that, and yet another bit of info NOT in the PDF.

Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf

[Herb Sevush]

[Walter Soyka] “obviously they still have a development process in place. There is no reason that documentation couldn’t happen along with development.”

I know there is a development process, what I was talking about was the value of an established, reliable development cycle, that allows for the comprehensive scheduling that good print documentation requires. Once you throw printed documentation out the window, then the cycle can be sped up, but if your on-line PDF starts out with 45 pages of release notes, then I suggest that someone is not minding the store. Short irregular release schedules can lead to disorganization — the lure of “hey lets get this new feature out quick” has it’s downsides.

PPro case in point — in one of the later releases PPro introduced a very good feature that allows the editor to rearrange the layout of sources in the multicam window, i.e., switching camera 1 from upper right to lower left in a 4 screen window. Excellent feature, well implemented. However the feature is located only in the preview window menu and is called “edit cameras.” No indication whatsoever that this is a “multicam” feature. I knew this feature existed, but I didn’t know the name of it so I spent way too long trying to find it. This is the kind of chaos you get when software designers add new features without review.

Can a company keep order while speeding up release cycles? Possibly, but I think it’s much harder.

[Walter Soyka] “Preserving some legacy organization is a good thing because it means that current users will already understand how to find the features (making them highly discoverable), but it becomes a bad thing when the original organization no longer makes sense. A certain degree of complexity is necessary for controlling a large amount of functionality, but this shouldn’t be the same as outright disorganization.”

Yes, this is an issue for all organized data, whether composed of computer code or national tax codes. This is the OSX vs Windows paradigm. The longer the legacy, the greater the complexity of structure. Blowing things up and starting over allows the FCPX PDF to come in complete at under 500 pages. However I believe a middle road is achievable, but not without effort (=dollars.)

Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf

[Herb Sevush]

[Dennis Radeke] “At almost 600 pages, I hope it is enough for most people. ;-)”

It well might be enough for most people but that doesn’t make it enough. There are any number of menu choices that come up that are not explained or even mentioned in the PDF, which itself is confusing because of the 45 pages of “release notes” which serve as a pre-amble.

For instance, it appears that multicam source sequences have to be on track 1 of the target timeline or they won’t function. I haven’t found this important bit of info mentioned in the PDF, and I have looked.

PPro has become a very deep and complex program and while documentation is expensive and print is old fashioned there needs to be some organized way to find out the properties of a given function that does not require a user to wade threw a host of youtube videos that may or may not give the information you are looking for.

Knowing that the PDF covers 90% of the features doesn’t help you when you are drowning for lack of knowledge about the other 10%.

Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf