Red-rob Rothkopf
Forum Replies Created
-
Oddly, although it’s still not proper, it displays differently in the BCC UI Window than it does when previewing/rendering in Vegas (14).
Note when it initially is spinning on, that the full middle-lower half of “Mirror Mirror” is displaying and only the top gets clipped.
-
HEY.. that’s awesome!
Although I’d think this *should* be simpler with digital processing (e.g. why can’t the NLE just detect all differences between source matte and other video channels laid on top of it??) — that tutorial is a *GREAT* place to start playing until something simpler comes along.
Thanks for the heads-up! (and how’d you find that?)
☺ Rob
-
I haven’t worked with “CloneFX plug-ins”. Do they rely on chromakeying, and then essentially duplicate whatever’s remaining with various transforms applied?
-
It sounds like you’re on the right path… but like you said, converting it to a B&W mask would potentially cause shadow problems.
Could you detail out a bit more what your plan looks like (layer-order, compositing modes) to make your idea work?
Are there 3rd party tools that could help accomplish this?
-
-
Rippling will be a good start to creating the effect.
Since we want each of these 4 diamond shapes to be suspended by a string, they’ll spin a bit.. and sway along the Z and X (rotating the Z and X).. and if they bump into each other, should react appropriately.
I haven’t played around at all with object interaction in Boris.. does it have that kind of thing? Are there any instructionals out there?
-
[Matthew Barbato] “It seemed to work until I reassembled my kit (attached beachtek to camera to handle grip to tripod) then the problem came back. Eventually I came to the conclusion that the tiny post on the tripod plate that holds alignment was touching something inside the Beachtek and causing a grounding problem. When I removed the post, the problem disappeared.”
Fast forward to 2017 — this is STILL a problem. I’m having it with my Canon G30 and G40, and as you discovered, it only happens if the audio interface (Beachtek in your case) or recorder (Tascam DR-701D in my case) is threaded all the way into the bottom of the camera. As soon as I unthread it a hair, the beep/chirp (which is tied to the tally lamp) goes away. Unfortunately, I don’t see a “ground” setting I can change on the Tascam. This seems like a prolific problem across the Canon line of cameras which needs to be corrected by:
1. Isolating the tripod/mount thread on the bottom of the camera from the rest of the camera’s electronics (so there is no ground issue)
2. Making sure all their cameras allow the operator to DISABLE the Tally Lamp! Most cameras have a system option for TALLY LAMP On/Off.
I’m shocked #2 doesn’t exist, and am really upset that #1 still is going on still after all these years.
I’m talking with Canon support and hope they will listen.
-
Your signature-line says you’re using an NVIDIA card.
Other people have posted also, that the Starbust and Defocus effects crash when using AMD cards like the RX470, which has been recommended by many others as an excellent-performing card with Vegas (and I agree with the performance assessment). This is not a new problem, only a problem that appears (by searching threads) to have been around for a while, which now affects me adversely the same way it has been affecting some others.
FWIW — I understand the difference between a version # and build # — it’s just a semantic detail of the version-numbering scheme, and when I wrote “my Vegas 14 build” I probably meant “my Vegas 14 configuration”.
-
FWIW, in my Vegas 14 build, Starburst crashes the app — Core i7, 4.2Ghz 32 GB RAM, AMD RX470.
- Setting RAM preview to 3,000 or 0 made no difference.
- Disabling GPU acceleration avoids the crash and it works properly.
This has little to do with how fast the system can keep up — there’s something in the Starburst code which doesn’t play properly with GPU implementation.
-
Hey Karl!
Firstly, I must say — NICE WORK! I worked in the technology field for 16 years coding in a variety of languages, sometimes digging into HEX to find bytes of data and massage data, code, whatever.
I’ve struggled on more than one occasion with lost interleaved data on Zoom R16. I use Windows and never thought of creating a disk image to start (I’m not sure how I’d even do this on Windows.. haven’t looked into it). When I analyzed chunks of files I had recovered and merged I never figured out the chunk size.. and without published specs on the actual file format eventually gave up. ☹
Just this past Friday I had someone unplug my R16 again.. and although I had fresh batteries (backup, yay!), by the time I noticed it was unplugged they too had died. And then it happened again Sat. with my Tascam DR-701d. ARGHHHH.
Thought #1: You suggested last year that automation was not likely possible due to not knowing the start of file… but I’m not so convinced. If a human can figure out the start of file, then we can build tools to help find that start of file, or actually find it. I know the Zoom R16 keeps “file directory” information somewhere, with the list of projects… maybe that also contains file-starts?
Although it’s been a bit of time, I’d be happy to attempt to build a recovery tool to automate things if an algorithm can be devised. This is a LONG OVERDUE tool, for both ZOOM, Tascam and other recorders.
Thought #2: Have you considered selling your recovery skills as a service? At least on THIS thread, you seem to be the de-facto expert. ☺
Whatcha think?
☺ Rob
