June 2008 - Pro-apps-dev - lists.apple.com

Draw a line with FXScript
by das_ich＠arcor.de 25 Jun '08

25 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.14 (Windows/20080421) ************ scriptid "Draw_Line" //DO NOT LOCALIZE filter "oneLine"; group "my Effects"; input p1, "1stPoint", Point, -0.25, -0.25 input p2, "2ndPoint", Point, -0.25, 0.25 code //dest = src1 line(p1, p2, dest, kWhite, 5) ************ All I get is a 5px white point at the Center of my canvas. What am I doing wrong? Regards, Georg Kiefer _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Hi, I'm new with FxScript and FxBuilder and I simply want to draw a line, but it doesn't work. Start and End should be defined by user's input. Here the code: This email sent to site_archiver(a)lists.apple.com

1 0

Re: Fxplugs not loading in FCP 5.1.4
by Darrin Cardani 24 Jun '08

24 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On Jun 24, 2008, at 4:41 PM, Jim Tierney wrote: G5, 10.4.11, FCP 5.1.4 Darrin -- Darrin Cardani dcardani(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… No FxPlugs are loading. Not ours or any other ones I have installed. Is there a preference somewhere to prevent FxPlugs from loading that could have gotten turned on? How does one completely uninstall FCP and related apps? Motion just crashes when I try and run it so I suspect there's something messed up with the system or installation. I've tried re-installing over it, but that didn't fix anything. I would prefer not to do a complete system re- install. :-) Any thoughts would be welcome... Is anything written to the console when the crash happens, or when FCP runs and doesn't find the filters? I don't know of any preference for FCP to turn off loading of FxPlugs. I thought there were uninstall instructions for the apps in the Apple Support web site, but don't know for sure off the top of my head. I'll see what I can find. This email sent to site_archiver(a)lists.apple.com

1 0

Fxplugs not loading in FCP 5.1.4
by Jim Tierney 24 Jun '08

24 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thread-index: AcjWLIxABolHAfVVRxOsWf9fg+BDPAACYAiQ G5, 10.4.11, FCP 5.1.4 No FxPlugs are loading. Not ours or any other ones I have installed. Is there a preference somewhere to prevent FxPlugs from loading that could have gotten turned on? How does one completely uninstall FCP and related apps? Motion just crashes when I try and run it so I suspect there's something messed up with the system or installation. I've tried re-installing over it, but that didn't fix anything. I would prefer not to do a complete system re-install. :-) Any thoughts would be welcome... Jim _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

SOLVED . Re: GetTexture and glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 )?
by David Patrick Farmer 24 Jun '08

24 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Framebuffer 0 is not the original target framebuffer in a plugin. On Jun 24, 2008, at 2:28 PM, David Patrick Farmer wrote: Howdy! www.davidpatrickfarmer.com/GetTexture.zip Thanks! David Farmer coreaudiovisual _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/catchall%40davidpatrick… _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… I am trying to use FBOs with GetTexture method and have found ugliness. It may very well be an incorrect use but I need to understand how to make it all work in FxPlug! Example Project Synopsis: Retrieve arbitrary frame from source layer. Render source layer to view, call glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 ) and clear view with arbitrary color. Why? Because the other noid has real FBOs. 9-) This was as clear cut as me thinks me could make the problem. If the bind framebuffer call is commented out, it all works. Why? Is it changing the context state somehow? Is it a masking issue of some sort? Update.: it does not need to use the GetTexture method to die. I came about this assumption through lack of thought. Still, why would binding the window frame buffer cause further render calls to be evaluated incorrectly or dismissed? This email sent to catchall(a)davidpatrickfarmer.com This email sent to site_archiver(a)lists.apple.com

1 0

Fwd: GetTexture and glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 )?
by David Patrick Farmer 24 Jun '08

24 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Howdy! www.davidpatrickfarmer.com/GetTexture.zip Thanks! David Farmer coreaudiovisual _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… I am trying to use FBOs with GetTexture method and have found ugliness. It may very well be an incorrect use but I need to understand how to make it all work in FxPlug! Example Project Synopsis: Retrieve arbitrary frame from source layer. Render source layer to view, call glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 ) and clear view with arbitrary color. Why? Because the other noid has real FBOs. 9-) This was as clear cut as me thinks me could make the problem. If the bind framebuffer call is commented out, it all works. Why? Is it changing the context state somehow? Is it a masking issue of some sort? Update.: it does not need to use the GetTexture method to die. I came about this assumption through lack of thought. Still, why would binding the window frame buffer cause further render calls to be evaluated incorrectly or dismissed? This email sent to site_archiver(a)lists.apple.com

1 0

GetTexture and glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 )?
by David Patrick Farmer 24 Jun '08

24 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com GetTexture.zip

1 0

Re: filter plugin getting unexpected frame numbers
by Steve Christensen 20 Jun '08

20 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Paul, steve On Jun 20, 2008, at 9:10 AM, Paul Schneider wrote: Hi Steve, - Paul On May 23, 2008, at 5:12 PM, Steve Christensen wrote: I also included a couple of test lines: testStart = [timingAPI startTimeForEffect:self]; testDuration = [timingAPI durationForEffect:self]; renderInfo.frame = 6 effectTime = 6 effectDuration = 300 testStart = 240 testDuration = 300 renderInfo.frame = 1806 effectTime = 1806 effectDuration = 3901 testStart = 0 testDuration = 3091 Any ideas if I'm doing something wrong, if it's a FC bug or what? _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… The first set of numbers (duration=300) comes from rendering to the canvas window. The second set (duration=3901) comes from rendering to the viewer window. From what I can tell, the in and out are set to a much smaller range centered within the 3901 frames, which I guess explains why the current frame number is so large. It sounds like the TimingAPI is giving you wrong values when your clip is loaded into the viewer? (The viewer is the per-item display window usually in the upper-middle of your monitor; the canvas is the sequence display usually in the upper-right of your monitor). If so, that sounds like a bug in Final Cut; I'll check it out. Kristian, is it possible that you're seeing the same thing, or is there more going on in your case? I'm seeing something weird in both FCP and FCE. I am working on a filter plugin that changes over time, so I'm getting the clip- relative frame number and the clip duration in order to calculate the fraction "done": timingAPI = [_apiManager apiForProtocol:@protocol(FxTimingAPI)]; effectTime = [timingAPI inputTimeForFilter:self fromTimelineTime:renderInfo.frame]; effectDuration = [timingAPI durationOfInputToFilter:self]; Everything behaves correctly in most cases, but I've run into one case where I get very unexpected numbers. Here's what I'm doing: 1. Launch FCE/FCP with a new project. 2. Drag a clip onto the timeline so it starts at about the 01:00:00;08 second mark. 3. Move the playhead so it's a few frames into the clip. 4. Click once on the clip so it's selected. 5. Locate my plugin in the list and drag it onto the clip. I have a breakpoint set in -renderOutput:withInput:withInfo: which gets hit at this time. I see: This is what I expect. I continue execution then switch back to FC. If I double-click on the clip, my plugin breakpoint gets hit once again, this time with the following values: steve This email sent to site_archiver(a)lists.apple.com

1 0

Re: filter plugin getting unexpected frame numbers
by Paul Schneider 20 Jun '08

20 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Steve, - Paul On May 23, 2008, at 5:12 PM, Steve Christensen wrote: I also included a couple of test lines: testStart = [timingAPI startTimeForEffect:self]; testDuration = [timingAPI durationForEffect:self]; renderInfo.frame = 6 effectTime = 6 effectDuration = 300 testStart = 240 testDuration = 300 renderInfo.frame = 1806 effectTime = 1806 effectDuration = 3901 testStart = 0 testDuration = 3091 Any ideas if I'm doing something wrong, if it's a FC bug or what? steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… It sounds like the TimingAPI is giving you wrong values when your clip is loaded into the viewer? (The viewer is the per-item display window usually in the upper-middle of your monitor; the canvas is the sequence display usually in the upper-right of your monitor). If so, that sounds like a bug in Final Cut; I'll check it out. Kristian, is it possible that you're seeing the same thing, or is there more going on in your case? I'm seeing something weird in both FCP and FCE. I am working on a filter plugin that changes over time, so I'm getting the clip- relative frame number and the clip duration in order to calculate the fraction "done": timingAPI = [_apiManager apiForProtocol:@protocol(FxTimingAPI)]; effectTime = [timingAPI inputTimeForFilter:self fromTimelineTime:renderInfo.frame]; effectDuration = [timingAPI durationOfInputToFilter:self]; Everything behaves correctly in most cases, but I've run into one case where I get very unexpected numbers. Here's what I'm doing: 1. Launch FCE/FCP with a new project. 2. Drag a clip onto the timeline so it starts at about the 01:00:00;08 second mark. 3. Move the playhead so it's a few frames into the clip. 4. Click once on the clip so it's selected. 5. Locate my plugin in the list and drag it onto the clip. I have a breakpoint set in -renderOutput:withInput:withInfo: which gets hit at this time. I see: This is what I expect. I continue execution then switch back to FC. If I double-click on the clip, my plugin breakpoint gets hit once again, this time with the following values: This email sent to pschneider(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: filter plugin getting unexpected frame numbers
by Paul Schneider 20 Jun '08

20 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Kristian, - Paul On Jun 19, 2008, at 7:49 AM, Kristian Harms wrote: Hi List, Steve, others, Best regards, Kristian Harms, software developer, Vizrt Norway I'm seeing something weird in both FCP and FCE. I am working on a filter plugin that changes over time, so I'm getting the clip- relative frame number and the clip duration in order to calculate the fraction "done": timingAPI = [_apiManager apiForProtocol:@protocol(FxTimingAPI)]; effectTime = [timingAPI inputTimeForFilter:self fromTimelineTime:renderInfo.frame]; effectDuration = [timingAPI durationOfInputToFilter:self]; I also included a couple of test lines: testStart = [timingAPI startTimeForEffect:self]; testDuration = [timingAPI durationForEffect:self]; Everything behaves correctly in most cases, but I've run into one case where I get very unexpected numbers. Here's what I'm doing: 1. Launch FCE/FCP with a new project. 2. Drag a clip onto the timeline so it starts at about the 01:00:00;08 second mark. 3. Move the playhead so it's a few frames into the clip. 4. Click once on the clip so it's selected. 5. Locate my plugin in the list and drag it onto the clip. I have a breakpoint set in -renderOutput:withInput:withInfo: which gets hit at this time. I see: renderInfo.frame = 6 effectTime = 6 effectDuration = 300 testStart = 240 testDuration = 300 This is what I expect. I continue execution then switch back to FC. If I double-click on the clip, my plugin breakpoint gets hit once again, this time with the following values: renderInfo.frame = 1806 effectTime = 1806 effectDuration = 3901 testStart = 0 testDuration = 3091 Any ideas if I'm doing something wrong, if it's a FC bug or what? steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/kha%40vizrt.com This email sent to kha(a)vizrt.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… I'm unaware of any circumstances under which the TimingAPI is unreliable. Your best bet would be to file a detailed bug at bugreport.apple.com, so that I can see exactly what you're seeing. Could you also include your project settings? Under normal circumstances, we should be asking you to render at sequence size, not at whatever size the canvas window happens to be... I'm seeing something similar to what Steve is reporting, in the FxPlug generator that I'm working on. It also changes over time, based on the length of the effect, which therefore is of fairly high importance. In my -renderOutput:withInfo: method, I find that I cannot fully rely on the duration obtained from the timingAPI's - durationForEffect: method. In many cases it does give the correct result, e.g. 250 frames, but very often it also reports the duration as being exactly 3000 frames. This seems to happen in most cases when FCP is getting a frame for the Canvas preview area, i.e. for scrubbing, where the parameters for the rendering is often different from that of the actual rendering. We could try hacking around this based on the reduced dimensions of the requested image (but that's not very good, since some users will have the Canvas window large, yielding requests for full-size images when scrubbing) or based on the field order of the requested image being progressive (again not very good, as projects that actually -are- progressive would yield false positives). I've also tried using the -inPointOfTimelineForEffect: and - outPointOfTimelineForEffect: methods fot the timingAPI. The difference between these two doesn't seem to be fully reliable either, but in my testing today this number seems to be correct exactly in the cases where -durationForEffect: is not, and vice versa. Therefore this seems to be my best bet at the moment, although testing in Motion remains to be done. The reason I'm so troubled by inaccurate effect lengths even when scrubbing is that we store the effect length in an internal datastructure the first time we see it after it seems to have changed, and use this stored number to determine how a custom parameter is presented to the user. Perhaps it has been thought that incorrect effect lengths are innocuous in the scrubbing case, but clearly for us it's not. Taken together with Steve's observations from a few weeks ago, it does seem that the timingAPI is somewhat unreliable. Would anyone care to comment on my proposed workarounds or recommend another course of action? Steve Christensen skrev: This email sent to pschneider(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: filter plugin getting unexpected frame numbers
by Kristian Harms 19 Jun '08

19 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Thunderbird 1.5.0.14pre (X11/20071023) Hi List, Steve, others, Best regards, Kristian Harms, software developer, Vizrt Norway I'm seeing something weird in both FCP and FCE. I am working on a filter plugin that changes over time, so I'm getting the clip- relative frame number and the clip duration in order to calculate the fraction "done": timingAPI = [_apiManager apiForProtocol:@protocol(FxTimingAPI)]; effectTime = [timingAPI inputTimeForFilter:self fromTimelineTime:renderInfo.frame]; effectDuration = [timingAPI durationOfInputToFilter:self]; I also included a couple of test lines: testStart = [timingAPI startTimeForEffect:self]; testDuration = [timingAPI durationForEffect:self]; Everything behaves correctly in most cases, but I've run into one case where I get very unexpected numbers. Here's what I'm doing: 1. Launch FCE/FCP with a new project. 2. Drag a clip onto the timeline so it starts at about the 01:00:00;08 second mark. 3. Move the playhead so it's a few frames into the clip. 4. Click once on the clip so it's selected. 5. Locate my plugin in the list and drag it onto the clip. I have a breakpoint set in -renderOutput:withInput:withInfo: which gets hit at this time. I see: renderInfo.frame = 6 effectTime = 6 effectDuration = 300 testStart = 240 testDuration = 300 This is what I expect. I continue execution then switch back to FC. If I double-click on the clip, my plugin breakpoint gets hit once again, this time with the following values: renderInfo.frame = 1806 effectTime = 1806 effectDuration = 3901 testStart = 0 testDuration = 3091 Any ideas if I'm doing something wrong, if it's a FC bug or what? steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/kha%40vizrt.com This email sent to kha(a)vizrt.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… I'm seeing something similar to what Steve is reporting, in the FxPlug generator that I'm working on. It also changes over time, based on the length of the effect, which therefore is of fairly high importance. In my -renderOutput:withInfo: method, I find that I cannot fully rely on the duration obtained from the timingAPI's -durationForEffect: method. In many cases it does give the correct result, e.g. 250 frames, but very often it also reports the duration as being exactly 3000 frames. This seems to happen in most cases when FCP is getting a frame for the Canvas preview area, i.e. for scrubbing, where the parameters for the rendering is often different from that of the actual rendering. We could try hacking around this based on the reduced dimensions of the requested image (but that's not very good, since some users will have the Canvas window large, yielding requests for full-size images when scrubbing) or based on the field order of the requested image being progressive (again not very good, as projects that actually -are- progressive would yield false positives). I've also tried using the -inPointOfTimelineForEffect: and -outPointOfTimelineForEffect: methods fot the timingAPI. The difference between these two doesn't seem to be fully reliable either, but in my testing today this number seems to be correct exactly in the cases where -durationForEffect: is not, and vice versa. Therefore this seems to be my best bet at the moment, although testing in Motion remains to be done. The reason I'm so troubled by inaccurate effect lengths even when scrubbing is that we store the effect length in an internal datastructure the first time we see it after it seems to have changed, and use this stored number to determine how a custom parameter is presented to the user. Perhaps it has been thought that incorrect effect lengths are innocuous in the scrubbing case, but clearly for us it's not. Taken together with Steve's observations from a few weeks ago, it does seem that the timingAPI is somewhat unreliable. Would anyone care to comment on my proposed workarounds or recommend another course of action? Steve Christensen skrev: This email sent to site_archiver(a)lists.apple.com

1 0