site_archiver(a)lists.apple.com
Delivered-To: pro-apps-dev(a)lists.apple.com
Hmm, okay I guess it’s been 12 years since I looked at the FxPlug SDK! You’re
totally right. I was imagining using a filter FxPlug’s output as its own input,
which doesn’t make any kind of sense.
Carry on.
Dave
> On Oct 28, 2020, at 4:20 PM, Darrin Cardani <dcardani(a)apple.com> wrote:
>
> Good to see you around these parts, Dave!
>
> I’m not sure what you mean. Can you elaborate? The timing API returns info
> about the timing of objects in the project. The temporal image API of FxPlug
> 3 and earlier can get frames at previous times, but they’re input frames, not
> output frames. In FxPlug 4, you can schedule frames at other times to be
> inputs at the current time, but again, they’re input frames, not output
> frames. Am I misunderstanding what you’re suggesting?
>
> Darrin
>
>> On Oct 28, 2020, at 4:12 PM, Dave Howell <dave(a)avatron.com
>> <mailto:dave@avatron.com>> wrote:
>>
>> Could Bret just use the Timing API to make one frame depend on the contents
>> of a previous frame? Then when handed the previous frame, he could just
>> ignore it and render the current frame.
>>
>> Dave at Avatron
>>
>>
>>> On Oct 28, 2020, at 9:01 AM, Darrin Cardani via Pro-apps-dev
>>> <pro-apps-dev(a)lists.apple.com <mailto:pro-apps-dev@lists.apple.com>> wrote:
>>>
>>> I’m not sure how easy it is to ensure you get them in the proper order, but
>>> you can always use a lock of some sort. For example in your
>>> -renderDestination: method, you could lock an NSLock at the start. That
>>> will prevent 2 calls to the method on different threads from running at the
>>> same time. The issue is that the order may not be sequential. (It depends
>>> on a number of asynchronous things happening in the host app.) It might be
>>> possible to note the time of the last frame processed and if the current
>>> time is more than 1 frame later, hold off until a frame closer to the last
>>> rendered one gets rendered? It seems like you’d have issues if the user
>>> moves the playhead in that case, but that’s the only thing I can think off
>>> of the top of my head.
>>>
>>> Darrin
>>>
>>>> On Oct 28, 2020, at 8:57 AM, Bret Battey via Pro-apps-dev
>>>> <pro-apps-dev(a)lists.apple.com <mailto:pro-apps-dev@lists.apple.com>> wrote:
>>>>
>>>> Hi ProAppsDev,
>>>>
>>>> In doing my FxPlug 4.X conversions, I understand that now the plugin can
>>>> and will process multiple frames simultaneously if the GPUs are available
>>>> to do so, and that there is no longer a switch to control whether this
>>>> happens.
>>>>
>>>> I use FxPlugs for my own nefarious artistic purposes, so sometimes I break
>>>> rules, since it only needs to work for me. One of my FxPlugs relies on
>>>> frame-to-frame feedback (a rule-breaker for sure), which the new parallel
>>>> frame-processing paradigm in turn prevents. I’m just wondering if there
>>>> might be an underhanded trick available for me to get around this and
>>>> force sequential processing of the frames for an FxPlug. I might even
>>>> consider a soft-switch to disable my second GPU if I were truly desperate…
>>>>
>>>> Fully understandable if there is not a way.
>>>>
>>>> Thanks,
>>>> -=Bret
_______________________________________________
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:
https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.…
This email sent to site_archiver(a)lists.apple.com