|
|||||||||
|
Thread Tools | Search this Thread |
June 13th, 2004, 08:48 PM | #16 |
Major Player
Join Date: Jan 2004
Location: Katoomba NSW Australia
Posts: 635
|
Correct me if I'm wrong, but don't plug-ins make use of an applications' native features/architecture to achieve their functionality? If so, the 'parent' program is capable of achieving what the plug-in can...... the only difference being the long and involved task of discovering how!!
The desire by the majority of computer users to avoid 'blowing time' on tracing such long and torturous paths to a single result; that may or may not be of benefit, is what the plug-in developers have expoited. From my viewpoint it's a mighty fine thing that plug-in developers have developed their software to make my creative life a little easier, but it's a relief when you get an app that does everything you want of it without having to hunt down plug-ins/codecs etc. just to get a bit more than basic functionality!!!! For this reason alone, (and especially as a HD10 user!!!) Vegas is a standout app..... |
June 21st, 2004, 05:01 AM | #17 |
Inner Circle
Join Date: Apr 2003
Location: Aus
Posts: 3,884
|
hmm..
moving back to the focus of teh thread.. heheheh one thing i have noticed is that footage shot in 50i, which is then slowed (i got it down to 15%) then rendered to Progressive 25p is much smoother and alot more fluid and jerk free than it is when rendering back to 50i |
June 25th, 2004, 01:52 AM | #18 |
New Boot
Join Date: Apr 2004
Location: Melbourne, Australia
Posts: 7
|
Interlace broken
Speaking of that footage, it looks like much of the difference in image quality is due to the fact that the Vegas footage is still interlaced and the FCP footage has been deinterlaced, giving it a 'smoother' look...
Is this just a question of the settings that are being used for the final render? |
June 25th, 2004, 04:49 AM | #19 |
RED Problem Solver
Join Date: Sep 2003
Location: Ottawa, Canada
Posts: 1,365
|
From a programmers' and plug-in writers' point of view:
"We all stand on the shoulders of giants." If I write a plugin, as I do regularly for FCP, I use it's fxscript API, and that can be as simple as putting together a programmed version of a simple layering or bluring recipe, or it can be as complex as programming a new effect from scratch with only the most basic tools at my disposal. Now what those basic tools are, is down to the programmers at FCP, but if I invent something totally unique using them, like my chroma reconstruction filter, then that's serious programming and mental effort on my part. If I write a plugin for, say, After Effects, and I have to code every bit of image manipulation from scratch in C, I'm still using the C language and all it's constructs and underlying operating system code that makes my plugin work. I still wrote or invented my algorithm, but I've had to do more work. However, either way, we're all building on the work of others. So when something like Shake or AE gives you a plugin architecture that allows you write your own low level code in C, it can open doors to much more complex effects, however, exactly the same could theoretically be done in FCP with it's higher level API, albeit too slow to be usable. Shake (which I'm just learning, so don't take my word as the total truth) has 3 levels of "plugin" type customisation: macros, which turns a node structure you've set up into a single node, a sort of recipe if you like, scripting, which uses the macro type structure, but you can go in and add expressions and even some C code to make things even funkier SDK, which supposodly lets you at everything including writing your own stuff from scratch with C. This will be great for very complex, innovotive stuff. Also, the "difficulty" level scales, so even non-techy users can do some programming, and real geeks can get right into it. Graeme
__________________
www.nattress.com - filters for FCP |
| ||||||
|
|