The plug-in currently resets all of the inputs to defaults when you even update even a single character of the shader. So it'd be useful to find a pair of parameters whose names and types are equivalent, between old and new ISFs, and carry over the values.

Not sure if this is planned or not, but would be really nice to see this get Windows support! Looking at the source with my limited knowledge of cpp, I think the file open/save dialogs and such are the only parts that require macOS, but maybe there's more to it I'm not aware of.

can't build it in my environment.
AE CC 2018
High Sierra 10.13.4

Hey, sorry im newb but i get this error when installing:

error: git diff header lacks filename information when removing 1 leading pathname component (line 98)

any hints on how to fix this?

It could be helpful if the effect had a sort of “export“ button in ECP and could compile the currently loaded ISF into a binary.
There are several merits for realizing the feature:

• Much easier to distribute effects for teams, as users don't need to load the specific ISF manually after applying the ISF4AE effect.
• No need to worry about some references via expressions being broken since the parameter lists are declared statically.

Suggested by @mizt

I installed the plugin downloaded from the release section.
When I add the plugin to a solid layer I get this error:

Here are my specs:

By using PF_Arbitrary_PRINT_FUNC and SCAN_FUNC, it might be possible to allow a user to copy and paste the ISF code via clipboard.

First, let me thank You for creating and sharing GLSLCanvas!

I've tried it with two versions of After Effects.
AE CC 2017.2 (14.2.1.34) - loads and renders some of shaders from Book of Shaders that I've tried. So far no crashes, performance is ok (just a little choppiness while adjusting parameters in plug-in UI).

AE CC 2018 (15.0.0, build 180) - after attempting to load shader via "Load Shader.." AE crashes, same if I just add GLSLCanvas to empty solid and move playhead. Few times it even froze my whole system (not a kernel panic, just complete freeze and lots of artefacts). I also tried to change AE renderer from Metal to Software Only, same thing.
Crash report:
AE_2018_GLSLCanvas_CRASH.txt

I've compiled Your plugin on MacOS 10.12.6 & XCode 9.2 (9C40b) and used latest AE SDK.

At the moment, the 'Reset' label right to the name of effects refreshes not only inputs but also the imported shader itself. So it would be nice to add a 'Reset to Default' button under ISF options so that users can only reset the value of ISF inputs.

This issue occurs in at least the 2023 version of macOS. This may be related to multi-thread locking logics such as [globalData->lock lock].

Does anyone who's used to thread-safe programming have any clue how to resolve it?

I installed the plugin downloaded from the release section.
When I add the plugin to a solid layer I get this error:

Here are my specs:

As discarding the 'Use Layer Time' checkbox,
it'd be useful if the remaining 'Time' slider automatically refers the layer time that the effect is applied.

Since PF_AD_PARAM only supports non-expression values as a default,
I tried to use AEGP suites to modify a parameter like the below code at the timing PF_Cmd_SEQUENCE_SETUP has called:

// Set the default expression to parameters
AEGP_EffectRefH effectH = NULL;
AEGP_StreamRefH streamH = NULL;

ERR(suites.PFInterfaceSuite1()->AEGP_GetNewEffectForEffect(G_my_plugin_id, in_data->effect_ref, &effectH));
ERR(suites.StreamSuite5()->AEGP_GetNewEffectStreamByIndex(G_my_plugin_id, effectH, FILTER_TIME_ID, &streamH));
ERR(suites.StreamSuite2()->AEGP_SetExpressionState(G_my_plugin_id, streamH, true));
ERR(suites.StreamSuite2()->AEGP_SetExpression(G_my_plugin_id, streamH, "thisLayer.time"));
    
if (effectH) ERR(suites.EffectSuite3()->AEGP_DisposeEffect(effectH));
if (streamH) ERR(suites.StreamSuite2()->AEGP_DisposeStream(streamH));    

But it raises an error, which says ”internal verification failure, sorry! {child not found in parent} (20::0)”.
Does any guru know how to handle this?

Since the plug-in dynamically changes the names of parameters to match with ISF inputs, it raises an error when you try to retrieve the value by expression.

An expression like this:

const d = thisLayer.effect("Polar Displacement")("Distance");

triggers an error with the message: ”Error: property or method named 'Distance' in Class 'Group' is missing or does not exist.”.

Hello everyone! I decided to create a separate Issue, which was previously mentioned in the Enhancement regarding Windows in this issue. Now there is a Windows version, but it seems to work with certain limitations, apparently related to issues with multithreading in OpenGL, as mentioned here.

When we simply move the sliders or the playhead in the composition, everything is fine. Also, if we turn off the MFR mode in the settings, the plugin's output renders perfectly.

However, with MFR mode enabled, a crash occurs because the cpuBackingPtr is found to be Null. I've reflected this more explicitly in this assert inside SmartRender at this line:

if (!outputImageCPU->cpuBackingPtr) {
      err = PF_Err_OUT_OF_MEMORY;
      // A more explicit assert that appears with the new versions 
      // of the Nvidia Studio driver described in this post:
      // [link](https://github.com/baku89/ISF4AE/issues/19#issuecomment-1724631129)
      assert("FATAL! CPU backing pointer is NULL! Cannot copy CPU buffer to EffectWorld!" && false);
    }

But there are some peculiarities, many of which I mentioned in the comments to that issue. Although I've now found that the driver version doesn't actually affect the issue. During rendering or background frame calculation, cpuBackingPtr will always be NULL.

Also, the scene behaves very strangely if, for some reason, you don't do this line before compiling it:

// Without this USELESS variable I'm getting a glitch, where the scene
// doesn't work without any errors
// FIXME: Dig into it to figure it out the reason
ISF4AESceneRef useless = VVISF::CreateISF4AESceneRefUsing(globalData->context->newContextSharingMe());

In doing so, you actually need to assign this variable; otherwise, it won't fix the problem. I made these useless variables in a separate commit.

Without it, the screen will sometimes be black, and the gl2aeScene won't work either. There's still more to figure out with this issue, and it may not be as critical if it isn't related to the main problem causing the crash.

Possible Cause

Firstly, for what it's worth, the context on Windows is initialized slightly differently, and I did this based on intuition and from examples; perhaps I did something wrong in GlobalSetup:

#ifdef _WIN32
  GLContext::bootstrapGLEnvironmentIfNecessary();
  // VVGL on Windows Doesn't have pixel format functions
  globalData->context = VVGL::CreateNewGLContextRef(nullptr, nullptr);
#else
  globalData->context = VVGL::CreateNewGLContextRef(NULL, CreateCompatibilityGLPixelFormat());
#endif
  VVGL::CreateGlobalBufferPool(globalData->context->newContextSharingMe());

globalData->downloader = VVGL::CreateGLTexToCPUCopierRefUsing(globalData->context->newContextSharingMe());
globalData->uploader = VVGL::CreateGLCPUToTexCopierRefUsing(globalData->context->newContextSharingMe());

Here the global pool is initialized, which is subsequently used in the downloader and uploader, and I think the problem lies therein. Because later on, when we copy data from CPU to GPU through the uploader in the SmartRender function, here:

ERR(uploadCPUBufferInSmartRender(globalData, in_data->effect_ref, extra, checkoutIndex, layerSize, image));

Further in this function here:

auto imageAE = globalData->uploader->uploadCPUToTex(imageAECPU);

And then further down the calls, we come to this function: GLCPUToTexCopier::_beginProcessing inside of which we fail to bind the buffer:

glBindBuffer(inPBOBuffer->desc.target, inPBOBuffer->name);
if (glGetError() != 0) {
  assert("Cannot Bind to Buffer" && false);
}

All I found about this is a similar issue. But I'm not particularly knowledgeable about working with glew, and maybe @baku89 has an idea why, for instance, our buffer gets cleared through VVGL::GetGlobalBufferPool()->housekeeping(); in the renderISFToCPUBuffer function and not, say, through purge()? Or why does the cleanup happen here and not at the end of SmartRender()?
Spoiler: I tried changing and moving them, it doesn't make any difference.

The ISF spec says long "has" the extra LABELS and VALUES fields, but does not explicitly state whether they are required or optional.

ISF4AE in both renderISFToCPUBuffer and UpdateParamsUI assume that LABELS and VALUES exist for every long, and AE will crash if those fields are not defined for a long.

ISF Editor has logic to use values as labels if there is no LABELS field (or LABELS size mismatches), and values between MIN and MAX if there is no VALUES field defined. See ISFEditor/ISFEditor_app/misc_ui/ISFUIItem.cpp

The ISF Editor behaviour allows long to be used a generic integer input. At least, ISF4AE should fail to load rather than crash.