AE SDK wrapper

[philrosenberg2013]

Hi

I've just been working on a project writing AE plugins - mostly fairly basic things like drawing and animating geometric shapes. This has been my first foray into After Effects plugins. However in doing so I must confess to finding the API painful and the documentation impenetrable. It has taken me the best part of a year working on-and-off on this project to feel comfortable writing basic plugins - and I never even got as far as smart plugins.

Anyway, along the way I've begun to write a series of C++ wrappers around the API to manage resources, things like an multi-d array class to correctly handle AE memory management, some transformation code using the after effect matrix structure and the beginnings of a World class for managing AE_Worlds and doing drawing etc. I was wondering if there was any demand for this kind of thing in the community and if it was worth me developing further? The kind of thing I'm imagining is a more object oriented and easier to use interface to the SDK, with better resource management - to save the memory leaks. I know the code I've written already has massively speeded up my plugin development and reduced bugs. Maybe it would be some help to others.

In the end though, I'm self employed so it boils down to would anyone be interested enough in a "nice" API interface to buy it and make it worth my time developing. I wondered if anyone here had any thoughts or even might be interested in a finshed product?

Phil

[shachar carmi]

well, here are my 2 cents about this issue.

any modernisation of the AE API would be a welcome change. i of course am

using my own libs made over time.

will there be a demand for a payed AE super lib? i'll try to break it down,

to the best of my knowledge.

from what i gathered from my years at the forum, there are 3 demographics

here.

i'd say the breakdown is like so (based on intuition, not research):

1. 30% are complete noobs, with very little or no programming experience,

usually AE artists with an idea they'd like to fiddle with.

noobs are less likely to buy a library, as they have little prospect of

what their product will become. it's more of an intellectual challenge for

them, and actually using a crude c code is easier for a noob than learning

c++ concepts. however, noobs can evolve into semi-pros.

common problems noobs hit:

a. adding new params (to be set at 3 different places).

b. allocation and deallocation of objects.

c. image processing, not via a suite.

d. a dire need for better sample projects.

2. 50% are semi pro programmers with AE experience, and a better grip of

what their idea entails, and what it's worth.

semi-pros may buy a library, if they had failed at solving a certain

problem by themselves and the price is right. i'd imagine most semi-pros

develop on their spare time and make a living elsewhere, so they'd rather

spend more time than spend money. (again, until they hit a wall or come to

a realization that it's better to buy a lib)

common problems semi-pros hit:

a. combination of AEGP style project operations in an EFFECT plug-in.

b. custom UIs.

c. an even bigger dire need for better sample projects than that of a noob.

3. 20% are professional programmers, with little or no AE experience,

executing a commissioned work by a 3rd party.

commissioned pros on the other hand, they have a budget and a schedule.

they're used to using off the self libraries and consider it a shortcut.

surprisingly enough, even seasoned pros run into walls with AE's API. so

they're rather a sure sell. (given they know of your library, and it offers

a solution to the problem they've hit)

common problems pros hit:

a. wasting time learning the API nuances and subtleties. (and there are

many)

b. realizing what the API limitations are.

c. overcoming API limitations. (doing stuff against AE's will)

all 3 demographics would LOVE to have more sample projects, and better

sample project.

my guess is, that if your library is of good enough quality, has

interesting enough sample projects, and will be brought to the attention of

the developer, you'll see some sells.

there's a world surge of AE development. for the last 2 years i saw the

demand increase x2 each year. i don't know when that surge will peak, but

it's there.

i also don't know how to estimate the market size. in this forum there are

about 20 active users, so i'm guessing there are a mere few hundreds AE SDK

developers out there at best. is the library development worth while?

depends entirely on your costs of development, and whether such tools

evolve from your actual project's work or are you developing the library as

a project on it's own merit.

these have been my 2 cents.

please take everything here as my personal opinion and not as a fact.

having said that, i hope it helped.

[philrosenberg2013]

Hi Shachar

Thanks for that. It's very useful to hear the input from someone who's on this forum regularly and has a better overview of things. It's also interesting to think which category I fall into. Probably between 2 and 3 - a semi pro programmer, but doing a comissioned work for someone else. I hit a lot of the problems you mentioned.

Like you said there are probably a few hundred SDK users, and a significant proportion of those who might be have considered buying in some code probably already have their own code base. Of course the fewer people were interested the more the cost would be - which would put even more people off. Sounds like for the effort I'd need to put in for development and maintenance to sell so few copies it wouldn't be worth it.

Cheers again

All the best

P

Phil

[shachar carmi]

my evil plan is unfolding as expected... good... good...

[fusepilot]

I definitely wouldn't plan making money off of it.

However, the best reason to release a framework is to increase it's stability and features. I plan to release my scripting framework for free once its a bit more presentable, mainly so that people can contribute and improve it. And that, in theory, should eventually help me out in return.

a. wasting time learning the API nuances and subtleties. (and there are

many)

This is the main thing I'm getting constantly caught on. I've never seen such a strange API before. It seems that at every turn theres a new quirk to figure out. And the documentation is terrible, too many lame jokes and not enough helpful content. I look forward to completely bypassing it all and just focusing on the application logic.

I would like to eventually adapt David Van Brink's framework ( or something like it ) for plugin dev. It looks like it very nicely abstracts the mess that I'm currently waddling through. But, I'm waiting until I do have more of a low level understanding of the API before I do bypass it.

[Christian Lett]

The sample projects have been quite useful during the development of my plugin, but they're very inconsistent between themselves and the documentation. Example: the doc says don't use PF_NEW_HANDLE, etc. any more because they're depreciated, use HandleSuite instead. But there are a couple of sample projects which still use the old macros. Also GLator has never worked, and it's not a secret that the plugin crashes AE when you apply it. You'd have thought that someone would have found the bug and updated the project.

To be honest the most useful documentation is in the headers themselves, but that's something I discovered by accident rather than by design.

My plugin is mostly C rather than C++, probably because I'm in-between group 1 and 2 (i.e. not a total noob but not that experienced either) and none of the sample projects promote using classes.

Christian

[françois leroy]

Hi!

About the GLator example, I think the problem comes from there:

S_GLator_EffectCommonData.mRenderBufferWidthSu is locked to 1024 in GLbase.h. If the output size is higher, then AE crashes. But if you set it with a value higher than ouput, it works. However, I don't know how to set it dynamically (see this thread: http://forums.adobe.com/message/5942618#5942618) If someone could solve it, I guess we could all go out and have a drink! (a lot of threads talk about it...)

I don't really know which group I'm in now, but I started from zero, and learnt from the samples. They're difficult to understand in the beginning. For example, a sample would get camera data, and do nothing with it... Or another includes matrix operations, but don't use it either... and then starts the research in the threads...

I think the most usefull for people starting would be clear examples of already existing plugins. Like the Geometry effect, to learn how to deal with transforms (and matrix), Stroke and Fill to deal with masks, Luma / Contrast to deal with color correction, and may be Twirl to deal with image Sample (like they did with Pixel Bender)... As I have no experience in programming, I can't say if solid examples or a frameWork would be best. Probably both!

Another solution would be to clone Shachar Carmi and download him with the SDK! 😉

I must say I couldn't understand half of what I read without his help.

Cheers,

François

[cassidycurtis]

Hey Francois,

I'm running into that same problem where GLator crashes when the buffer is bigger than 1024 pixels... looking closely at GL_base.h and GL_base.cpp, though, it looks like 1024 is just the *default* value for those arguments, which is only used if you omit the arguments when you call the function.

In other words, if you pass in two more arguments to AESDK_OpenGL_InitResources(), it should work for a buffer of any size.

I'm about to try that. I'll let you know if it solves the problem!

-Cassidy

[françois leroy]

Hi Cassidy,

you're right, passing the width and height argument works.

In fact, I made a few changes and the plugin works "fine", or almost. I'm trying to enable multisampling, too, this is big headaches...

As soon as I'm done, I'll make a new post to summarize everything. This sample as been torturing too many people for too many years 😉

Cheers,

François

[cassidycurtis]

Thanks Francois! Looking forward to your summary!

[wil_]

Hi philrosenberg2013,

I am also starting developing After Effects plug-ins, and I would also greatly appreciate a more "object-oriented" API wrapper

I find the code easier to read like that, and actually tried to rewrite some bits of the samples in that way to get a better idea of what's going on inside them.

So, I'll definitely be interested in your idea.

[shachar carmi]

françois, if you promise my mother grandchildren she will ship me in a box

for free. 😄

[Nik Ska]

Hi! I'm now actively looking for a C++ programmer for AE plugin project and your ideas seem nice.

Drop me a line at dokluch@gmail.com