[David Grantham]

Mike, did CS4 run okay for you on Windows 7?

thx
David

[David Grantham]

This is a quiet forum. In case someone’s investigating this same thing, I’ll report that the display data can be removed from the HDMI signal in the camera’s settings. So (camera-generated) peaking can be displayed on the camera’s LCD only – handy if recording via HDMI.

I’m finding that peaking reacts wherever there’s a hard vertical edge, whether it’s in focus or not, so I’m not sure it’s so reliable.

[David Grantham]

(The atomos writes what it displays, so that’s not valid. I don’t think I’ll get one anyway – not until a similar unit will record 1080 @ 60p.)

However, I’d be interested in thoughts on the most cost-effective, small, light, and simple way to monitor and verify focus on this camera while providing one viewfinder devoid of peaking information at all times. I’m sure this will vary with personal preference.

thanks
David

[David Grantham]

Did you have any luck with this, Tyler? Can you tell me what settings resulted in you getting a file you could play on an android device?

I’m trying the same thing from CS4.

[David Grantham]

Did you have any luck with this, Tyler? Can you tell me what settings resulted in you getting a file you could play on an android device?

I’m trying the same thing from CS4.

[David Grantham]

On the side of PPro:

https://library.creativecow.net/kobler_helmut/FCP-vs-Premiere-Pro/1

I wonder if PPro is better on a Mac.

[David Grantham]

I appreciate your superior experience, Jon. I also place hope in 64 bit and the new OS which we’ve heard about over the last few years.

Were I to arrange (not simple) to test such a system for the several weeks it has taken these earlier versions to fail, to proceed there after this one doesn’t work is to place more faith in the brand after accepting consistent failure despite about ten years between 1.5 and CS4 on the PC. To proceed after successful testing would be to overlook the ongoing untestable risk of instability against updates to OS, drivers, and the app itself, which accepting an unresolvable current situation would give me no reason to trust.

I do appreciate your comment.

[David Grantham]

If I understand you, Mike, that extra step would help me place the clips into an off-line version according to my log notes, without having to manually set the Vegas-interpretted in-point. Considered that too, but subsequently subbed-in clips would have to match the offline ones exactly.

Of course substituted clips must have a) the same timecode/content relationship as the off-line edit. But any substituting clips not also matching b) the off-line clips’ in-points would require their Vegas-intepreted in-points to be manually set anyway – but not to their actual in-point, but to a number reflecting the difference between their in-point and that of the corresponding off-line clips. Yikes.

If Vegas is interpreting the off-line code correctly via manually-set clip in-point numbers, any subbing corresponding clips with varying in-points would require those in-points to be entered, but right off the timecode readout without the extra math.

Only a) (which is common to all video) is required with Premiere or any other program which uses the source time code reliably; this enables quite a bit of flexibility. Unfortunately the Premiere version I’ve bought – CS4 – is too unstable to produce on and Adobe tech can’t figure it out despite all the usual stripping down and updating etc. This was PPro’s last chance in my world, my last experience being the dreaded 1.5. So I’m looking for another alternative. Vegas might not be it but I’m giving the trial version a go.)

Rigidly disciplined timecode-matching hygiene between clip versions would obviate the need for Premiere’s flexibility, but flexibilty/forgiveability is a good thing.

[David Grantham]

Yes, these are off-line intermediates rendered by me to that codec, set up to begin with specific non-zero timecode numbers*, (which premiere reads and displays correctly without tweaks, but Vegas does not.)

(*To match the timecode on other clips which I will substitute for these clips on some versions of this vegas project.)

I found affirmation that the problem might never be sorted out by all the automated settings I found on many sites (all of which I tried to no avail.) It’s on a string somewhere – i think this forum – where it’s declared that for certain flavours of video Vegas just won’t interpret the timecode as beginning at anything but zero no matter what the source timecode says.

Manually entering the start point isn’t a horrible work-around this time – luckily I have very few clips. I imagine that manual setting might exist for just this eventuality.

But this could make a complex project involving off-lining – or setting up to substitute clips – very time-consuming and tricky with the wrong codec.

If this is the way it is, one is behooved to test any intended codec for proper interpretation before embarking on that sort of project in Vegas.

[David Grantham]

I’ve just gone through this source timecode issue in Vegas 9.

Cinepak Radius Codec AVI file starts @ 8:31:18.

Tried many recommended settings from many posts, but all marked and/or reported the timecode starting from 00:00:00:00

Only this worked: going into properties for the clip, unchecking “use timecode in file” and checking “Use custom setting” and manually setting the start point to the actual number.