• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Problems with plugins .bundle from Premiere Pro SDK for macOS

New Here ,
Aug 23, 2017 Aug 23, 2017

Copy link to clipboard

Copied

Hi all,

I am using:

SDK - Premiere Pro CC 2017.1

Program - Adobe Premiere Pro CC 2017.1

OS - macOS Sierra

After compile Vignette plugin from Premiere Pro SDK, it is not load to Premiere. But Premiere founded this plugin.

In log file: "No loaders recognized this plugin, so the plugin is set to ignore."

Pasted File at August 17, 2017 5-40 PM.png

Does anyone have a solution to this problem? Please, help me.

TOPICS
SDK

Views

2.4K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Sep 07, 2017 Sep 07, 2017

Copy link to clipboard

Copied

Hi Sergei,

Have you installed the latest CUDA Toolkit from nVidia?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Nov 03, 2017 Nov 03, 2017

Copy link to clipboard

Copied

I can't even get the example to compile...

getting following error in Xcode 9 with latest cuda toolkit.

nvcc fatal   : The version ('90000') of the host compiler ('Apple clang') is not supported

In general this sdk seems to be a bit 'clunky' at least for someone who is used to programming on a Mac!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Nov 08, 2017 Nov 08, 2017

Copy link to clipboard

Copied

Internally, we're using Xcode 8.3.


Not sure what you find clunky...?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Nov 08, 2017 Nov 08, 2017

Copy link to clipboard

Copied

The SDK.

If you're used to programming in Cocoa, you'll know what I mean 😉

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Nov 08, 2017 Nov 08, 2017

Copy link to clipboard

Copied

Cocoa = adorable.

Yes, cross-platform C++ code will likely never be as well-marketed, or tightly constrained, as Apple's single platform walled garden approach.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Nov 08, 2017 Nov 08, 2017

Copy link to clipboard

Copied

Hehe.. Yes, cocoa is adorable until it is NOT. The NOT kicks in when programmer wants to do something that Apple did not intend for.

But thats where Obj-C Runtime kicks in. And YES -> that starts to get clunky there too..

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Nov 08, 2017 Nov 08, 2017

Copy link to clipboard

Copied

Indeed!

I took an MFC class in the mid-'90s (hey, I was young). The teacher started with:

"Using MFC classes and library code will save you loads of time; that's good news, because  you're going to need that time, and more, to work AROUND those same classes and library code."

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Nov 08, 2017 Nov 08, 2017

Copy link to clipboard

Copied

LOL - That is very true.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Nov 08, 2017 Nov 08, 2017

Copy link to clipboard

Copied

If there are specific things we could do to make the PPro C++ SDK more user-friendly*, let us know.

* Other than by re-writing everything for Cocoa.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Nov 08, 2017 Nov 08, 2017

Copy link to clipboard

Copied

Event Handling

1. The way things are now it is impossible to implement a great Custom UI. We can't tell PPRO to render when we want PPRO to render unless we positioning the mouse where the SDK wants us to. So unless the user physically left-licks on his mouse, there is no way to modify the params. Scroll Wheels has been around for quite a while is the most intuitive way of adjusting colors.

2. We've used the DrawBot Suite to Draw our CustomUI within the ECW - but the SDK does not throw a 'Mouse Left View' event so if the user clicks and drags on a control and moves mouse outside of Effects Control View, lets go of the mouse and comes back to Effects View, the parameter will still think it should be performing alteration !

There are a lot of thing you could do to improve the experience for your users when it comes to custom UIs. Providing all events known to i.e NSView, NSControl, NSResponder would be a BIG no Gargantuan step forwards 😉

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Nov 08, 2017 Nov 08, 2017

Copy link to clipboard

Copied

LATEST

In Addition to Above Post..

We have written numerous of drawing classes for our other plug-ins in i.e. FCPx and Standalone.

Those use NSControls to draw. Which is a lot easier than using the DrawBots.

So - when an effect is being instantiate we grab the CocoaPlatformView_for_UI_PlatformSubView and add an NSView to that.

This works quite ok for but there is a huge problem.

Your CocoaPlatformView_for_UI_PlatformSubView which overlays the CustomUI and provides the NSTrackingArea is ​not ​being clipped to the Effects Control View's DVAMacContainerView but to the DVAMacRootView. This of course causes havoc on our drawing and which is not being clipped to the scrolling Effects Control View and will thus draw over which ever view lying beneath in the coordinate system. If only CocoaPlatformView_for_UI_PlatformSubView would be clipped to the Effect Controls View we could be drawing and handling events with Cocoa. This approach would be mean MUCH less work for you as SDK Writers. It could probably be done on Windows as well....

PS - Given the fact the numerous of your 3rd pty developers are extending Apple classes with their own methods you could potentially run in to serious bugs.

Just try setting CocoaPlatformView_for_UI_PlatformSubView' layer's backGroundcolor to blue. And you will see that your own NSVIew 9CocoaPlatformView_for_UI_PlatformSubView) IS not being clipped to effect control window -  like its supposed to. It actually extends beyond its intended view space and is just waiting to cause a bug 😉

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines