i don't see where james and i disagree on the checkin index. we both wrote it's the same index as used in the checkout. anyways, check the status of err and err2 in pre-render. it's possible that a checkout fails and sets the err state to non 0. once set, the ERR and ERR2 macros skip the code inside them, so the pre-render checkouts might not be happening past the first error. same goes for the render function. keep track of which checkouts succeeded, so you don't check in buffers that were never checked out. ... View more

i tihnk i see where you got things mixed up. when using extraP->cb->checkout_layer, you specify the layer param index for the checkout, and you also pass some unique identifier. the misconception is that this identifier has to do with the layer param index. it does not. on the sample projects the param index is used because it is unique in itself, but it's ablsoutely not required to be so. if you're doing 100 checkouts, you need 100 unique identifiers. you need to use the same identifiers when eventually checking out the pixels and when cheking them back in again.   say your param index is 6. the unique identifier can indeed be 6 as well. it can also be 234967592. the input layer is also checked out with param index 0, so except for 0 you can use any number.   if you have 2 layer params you'd like to check out with at 100 different times, you need to make sure the unique identifiers don't collide. for exmaple, if the param index for one is 6 and the other is 7, you can't do checkouts with 6+i and 7+i, as the nubers would overlap. instead, make a checkout counter, checkout the first param with indetifiers in the range of 1 -100 and the scond one with the range of 101-200. as long as in the redner function you know what identifier was associated with what sample so you could get what you expect, all is good. ... View more

there's no direct way without resorting to c++. however, here's a nice javascript workaround poasted way back when in this forum: https://community.adobe.com/t5/after-effects-discussions/calling-the-after-effects-color-picker-through-script/td-p/11954317 ... View more

ok... now that starts to remind me of an issue i've encountered way back when. i was using transform_world to rasterize many instances of a small texture along a path to create a brush storke. it ran fine on a macbook with windows installed, but on the same machine running osx it would get super sluggish. turns out on mac there was (and maybe still is) an overhead for calling transform_world. the function itself was working just as fast regardless of the transformed buffer size, but the acuumulation of the 100 overhead call lags was the performance killer... i ended up writing my own implementation of 2d transform which solved the problem. ... View more

if i'm not mistaking, AE's own "Transform" effect (effects->distort->transform) also interanlly uses transform_world. is it also sluggish on your new machine compared to the old one?   i once ran into the strangest bug that manifested as a memory leak. after a couple of tedious days of hunting it down i started commenting out parts of my plugin until finally the problem was found and it was... surprising. turns out having PF_OutFlag_KEEP_RESOURCE_OPEN while having an arb param causes a leak outside the plugin, somewhere in the bowels of AE.   what i'm saying here is that the problem may be deus ex... so if ae's "Transform" effect performs well, maybe try using transform_world in some sample project and see if the result is the same. ... View more

i honestly don't know why that would happen. in your shoes, i would have put some profiling code in my plug-in that would write data into a file, benchmark on the machines where it runs fast, and then see wherre the slowdown occurs on the problem occurs on the new machine. with a few iterations of this process you could pinpoint the problem area. ... View more

i never tried setting a track matte programtically, so i don't know if you're doing it wrong or if that function is broken. i can say, however, that some c api functions are indeed broken and the workaround is to use AEGP_ExecuteScript for that operation. once you're past the "but this is not elegant!" mental barrier, it just works. i used it to set keyframe interpolation info that was broken on the c side back when and perhaps still is broken... ... View more

i'm marking your answer as correct because it contains only true statements. ... View more

indeed. a bit of a hassle, but if you're going commercial then this cost is negligible.  ... View more

oh gawd no! construct one matrix and do the transormation only once. both for performance sake and for not re-sampling the image 3 times which will blur your image in a nasty way.   you're putting the correct stuff in the correct places in the matrix, but these operations need to be multiplied as whole matrices for each of the transformation operations, and not multiplying the separate components in the matrix. lookup matrix multiplication. you'll find a function in no time.   but here's some shortcuts before going on this adventure: the default matirx which does nothing is rederred to as "identity mtrix". it's filled as follows: 1, 0, 0, 0, 1, 0, 0, 0, 1, use that as the base for each of your separate transform, scale and rotate matrices, and then multiply them.   2. matrix operations happen relative to the top left corner of the image. if you want it relative to the center you need to first create an transpose matrix for half the width and height. so what you'd actually want to do to construct a proper transformation matrix is: 1. create a transpose matrix for negative the anchor point value. that moves the image's pivot point to the matrix's 0,0 coordinate. 2. multiply that matrix by the scale matrix, which will now happen around the anchor point. 3. multiply the previous result by the rotation marix (again, will happen aroung the expected point) 4. multiply the previous result by another transform matrix with the x/y position values. that's it. your matrix is ready to use. when going more advanced, you'll want to factor in pixel aspext ration as well. it would just mean doing a scaling matrix on x and the begining and end steps. ... View more

i see. let's tell a few things apart: 1. the means of determining what the transformation should be like at a given time. 2. putting all the transformation info into a matrix. 3. transforming the input image with said matrix.   so: 1. that's pretty much a translation of your expression to c++, ending up with x/y position, rotation and x/y scaling values for a given time. i trust you don't have an issue there.   2. why do you need a matrix? because rendering a transformation is no trivial manner which requires a TON different algorithms for sampling the image when upsclaed and downscaled, and a TON of optimizations to run it fast. luckily, the AE api offers you transform_world which accepts a matrix and does the rest. that's why you need a matrix. you need to read up on transformation matrices and how to construct them. but for testing sake, here's how to fill the PF_FloatMatrix to downscale the image by half: 0.5, 0, 0, 0, 0.5, 0, 0, 0, 1 matrices are kind of magical. you can concatenate multiple transformations into one matrix, and when multiplying an input point's x/y coordinates (a vector) by the matrix, you magically get the x/y coordinates of where it should appear on the output buffer.   3. now that you have a matrix contaning all of your transformation decisions put together, you can call transform_world with an input buffer to take pixels from, output buffer to put pixels to, and the matirx with all your transformation. transform_world does not talk to any other functions. all it does is move the pixels from the input to the output according to the matrix. ... View more

ooohhh... that's a bit of a mess. first off, the docs are wrong about putting in_data on the first arg. the best way to figure out how to use a callback (if you don't find it in the SDK sample projects) is to go to the function definition in the code. here's what it looks like there:   PF_Err (*transform_world)( PF_ProgPtr effect_ref, PF_Quality quality, PF_ModeFlags m_flags, PF_Field field, const PF_EffectWorld *src_world, const PF_CompositeMode *comp_mode, const PF_MaskWorld *mask_world0, const PF_FloatMatrix *matrices, A_long num_matrices, PF_Boolean src2dst_matrix, const PF_Rect *dest_rect, PF_EffectWorld *dst_world);     so now we can see the first arg is actually the effect_ref (in_data->effect_ref) that should go there, but i put a NULL instead. (otherwise it checks for interrupts)   in the last arg, you need to put a PF_EffectWorld, not a function. the output buffer would do. transform_world does the calculations of what pixel goes where according to the passed matrix.   for a matrix you need to fill a PF_FloatMatrix. read up on transformation matrices. just note that AE's matrices are column based instead of row based as is usually demostrated, so you might need to change the pocation of the elements from x,y to y,x. (it's called transposing a matrix)   about PF_Field_FRAME. frames in videos might be interlaced (where even rows come from one moment in time and odd rows from another). in the in_data, ae tells you is the input is interlaced or not, and you should act accordingly throught your process. if all you do is change pixel colors, then it doesn't matter. if you're doing scaling it matter a lot, because pixels originating from odd lines must end up on odd lines or they will appear on screen at the wrong time. read up on interlacing.   src2dst_matrix tells AE that the passed matrix transfroms points from source coordinates to destination coordinates. if set to false, the transformation will be reversed.    PF_CompositeMode tells AE how to treat the incoming pixels in regards to pixels already inside the dst buffer. so it doesn't only transform but only composites the transformed image on top of the existing buffer. hence, the opacity and transfer mode options. ... View more

yes, the process you described is correct. take a peek at the sample projects in the SDK, they all (the effects at least) show a similar concept for handling the render.   now i'll go a bit deeper. the only thing that really matters in regards to rendering, is that the ouptut buffer is returned filled within the scope of the render call. that is, you can't tell AE "i'll return now, bu t pass the result later". once your plug-in returns from a render call, AE will use the ouput buffer for downstream processes.   the rendering code itself doesn't have to reside entirely in the render function. you can write classes to handle that, you can send the innputs to a remote server for processing (don't do that. i'm just being rehtorical), AE doesn't know or care as long as the output buffer is filled by the time your plug-in returns from the render call.   some stuff to consider: to use AE's suites, you would (probably) want to use the suite handler (otherwise it's a hassle to aquire and release the suites). to use that handler you need to pass it the basic_picaP pointer from in the in_data structure. now we're getting to the point. that in_data structure is only valid within the scope of a single AE call to the plugin. if you try to store the in_data and use it after the call in which that data was sent has returned, that data is now garbage and using it will cause your plug-in to crash. that being said, the basic_picaP pointer itself is consistent throughout the AE session, and is safe to store. ... View more

generally speaking, a plug-in receives an input buffer with pixels to mnipulate, and an output buffer to put the results into. *how* the output buffer is filled is entirely up to you. AE doesn't care. so to scale your image you could use your won algorithm to shuffle pixels around, use 3rd party libraries, OR use some of the tools supplied by AE's API. for example, you could use transform_world() from PF_WorldTransformSuite1 to transpose, scale to rotate an image. here's a thread talking aobut it: https://community.adobe.com/t5/after-effects-discussions/help-with-transform-world/m-p/1840909 search the forum for more info, this function has been talked about here on numerous occasions. ... View more

i agree with Mylenium. you could add data to AE's pref files, but it offers absolutely no advantage to you or the user over just writing it where ever you prefer. ... View more

put some break points in the debugger. does it get a hit in the entry point function? ... View more

there's a new python api for AE, courtesy of @Trenton5EC4 ! it can shorten your development process for intergating your tech. https://community.adobe.com/t5/after-effects-discussions/after-effects-python-api/td-p/14386368 ... View more

indeed. same goes for any allocation. you can override the "new" operator for that purpose. i opted for a class with overridden "new" and "delete" operators which i use as a base class for all others. ... View more

well, collections are used to transfer selection sets to and from AE.  (as in, which layers are selected in the timline, and which keyframes are currently highlighted) you COULD use collections as a replacement for a vector, but it's intended to pass item selection sets back and forth with AE.   as for using an std vector, there's a general problem with that, because then you're drawing ram directly fromt he system and not from AE. it's not forbidden, but if you do so, then you don't let AE prioritize it's ram handling. with a ram preview rendering, ram is higly likely to run out so asking AE for ram allows AE to choose whther to free up some cached images to give your plug-in what it needs, while drawing directly from the system won't. i personally use a custom allocator for the std vector so it would draw memory from AE, and then i use it freely. ... View more

well, you can use AEGP_RenderAndCheckoutFrame and AEGP_GetReceiptWorld to get any project item in any color depth regardless of the project settings. the downside is that AE can't know in advance that your plugin will need that item, so it doesn't cache the results. that means the input aquisition is much slower than if you used the input AE passses to your plugin. ... View more

comp item id doesn't change thoughout the session. it can change between sessions, and if a project is imported into another then a new comp item id is assigned to the ones in the imported project.   layer id doesn't change in reordering. it can change, however, if the layer is copied to another comp, or cut/pasted back into the same comp. same goes for duplicating. i think a layer id might be re-used if a layer is deleted and a new one is created. in any case, layer ids are unly unique within one comp. the same id might be used for layers in different comps.   as for effect index, well... it changes when the effect is moved in the effect stack, but not when the layer is moved. you might have more than one instance of your effect on a layer.   in regards to writing data to an arb param, you can only do that from the ui thread. the render threads can not change the project at all, and that includes changing param values. ... View more

Awsome, man! my deepest appreciation for both execution and open source approach! ... View more

Thanks Bruce! at last, a straight answer. ... View more

hmmm... renaming readlly shouldn't trigger a re-render. what happens if you use AEGP_SetStreamName during UPDATE_PARAMS_UI? perhaps the name is linked to some param value via expression? is the name factored into GuidMixInPtr() dure pre-render? ... View more

ah! now that you've mentioned multiple CEP being open at the same time, i see what you mean by concurrency. in that regard, i do know a bit about what's going on there behind the scence. the calls from the CEP panel to AE's extendscript API are actually async. the result of the call comes around at a later time, and not synchronously with the call. the layer between the CEP and AE's extendscript is called "vulcan", and it's responsible for handling these async requests, queueing them, talking to AE at the appropriate time, and returning the results.   part of the premise of and motivation behind UPX, is ridding of the vulcan layer and making the communication with AE synchronous. ... View more

well... i don't know how these components work together, but i have a few thoughts in regards to all you've written here.   since in AE there are separate threads for rendering, and one thread for ui, each of these separate threads is independent of the others. render threads are, of course, forbidden from changing the project, and are only good for rendering puposes (or sending analytics over to the ui thread). the only thread allowed to change the project is the UI thead. having said that, what are the concurrent scripts you're running? if they're render scripts, then there shouldn't be a problem operating in parallel. if they're "project manipulation" scripts, why are they concurrent? having asked that, i'll continue assuming you have your good reasons.   as for having multiple python instances per process. if i understand you correctly, you mean by "process" you mean "ae program instance"? meaning, you're talking about 1 ae process talking to multiple python processes, right? and not, say, multiple instances of ae are open with the same project and you wish to use data from one as valid on the other... i'll assume you're not INSANE and go with the former assumption... so, i see no problem transfering ae stuff like an AEGP_ItemH between python processes, as all of these objects are references to some opaque data struct ae owns, so the reference remains valid and there no memory owned by one process travelling to the other. the thing to consider, though, is the lifespan of each of these items. officially, you shouldn't trust these objects beyond the scope of a single AE call. (i.e, from the beginnig of an idle_hook or render call, until  that call returns to ae) some of these items invalide immediatly, some seem to stick around. i've used an AEGP_ItemH over the span of a whole AE session, and it remained valid. AEGP_LayerH seems persistant over the session as well. AEGP_EffectRefH on the other hand, explodes as soon as the call is done... i'm not saying some items are guaranteed to stay valid throughout a session, as the docs don't mention it, but that's my experience with them.   so how does that concerns your development? i don't know the life span of your scripts. which means: 1. if a script is born and dies within the same AE call, all items aquired by it are valid thoughout it's lifespan. if it sticks around across AE calls, some item types may invalide in between. 2. if one script passes an item to another, and the other script lives beyond the scope of the first script's launching AE call, some of the passed items will have invalidated between AE calls. 3. items need to be disposed of. meaning, if a script passede an item onto another, then the first script exits and disposes of the checkout items it had, the passed ones will become invalid. again, these items are references to some internal AE data. it's not a copy of the data itself. 4. scripts may do contradictory things, so one script may try to act on an item already invalidated by another. for example, one script may try to access some layer it has a handle to, after a concurrent script had deleted it.   so i didn't answer your original question, but i hope my thoughts here can help. and oh, BTW, are you familiar with ExtendScript external objects? take a peek at "C:\Program Files (x86)\Adobe\Adobe Utilities - CS6\ExtendScript Toolkit CS6\SDK\Samples\cpp". you can create a c++ plug-in that adds capabilities to AE's javascript. when your functions are called, it invokes the c++ plugin along with the call data, the plugin does on the c++ side whatever it wants, and returns the result back to javascript. i don't know how that plays into your work scheme, but maybe it will spark your imagination... say, run python code from within a regualr AE script 🙂 ... View more