See subject. Or, alternatively, with colstodian's base, kolor. Whichever is the better suited abstraction.

Color management in Ae is still a mess. At least on the SDK side we can do better in Rust.

Dependabot can't resolve your Rust dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

    Updating crates.io index
error: no matching package named `aftereffects-sys` found
location searched: registry `https://github.com/rust-lang/crates.io-index`
required by package `aftereffects v0.1.0 (/home/dependabot/dependabot-updater/dependabot_tmp_dir

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

See the Rust API Guidelines on naming.

Just while going through #33, I saw a bunch of stuff that doesn't adhere to it.

For example, aeio::Handle is now aeio::AEIOHandle.

This is ugly for two reasons.

1. Rust naming guidelines say aeio::AEIOHandle should rather be named aeio::AeIoHandle.

2. However, consider std::io::Cursor. This is not named std::io::IoCursor.
   Or tokio::io::DumplexStream is not called tokio::io::IoDuplexStream.

   I.e. the module namespace is not repeated as a prefix on types in that module. This is not mentioned in the above document but kind of an unwritten rule, if you look at naming conventions used for structs in the std lib and common crates.

Dependabot couldn't fetch one or more of your project's path-based Rust dependencies. The affected dependencies were ../aftereffects-sys/Cargo.toml.

To use path-based dependencies with Dependabot the paths must be relative and resolve to a directory in this project's source code.

View the update logs.

TLDR;:

The handle lock and unlock calls no longer do anything in After Effects [since CS6/10 years] so you can leave those out.

See discussion on Adobe forums.

Dependabot couldn't fetch one or more of your project's path-based Rust dependencies. The affected dependencies were ../aftereffects-sys/Cargo.toml.

To use path-based dependencies with Dependabot the paths must be relative and resolve to a directory in this project's source code.

View the update logs.

I'm designing a high level plugin interface for the bindings, and my general idea is to have something like:

struct PortablePlugin { }
impl AdobePlugin for PortablePlugin {
    fn can_load(_host_name: &str, _host_version: &str) -> bool { true }
    fn new() -> Self { Self {} }

    fn handle_command(&mut self, cmd: Command) {
        match cmd {
            Command::About { mut out_data, .. } => {
                out_data.set_return_msg("Test plugin."));
            }
            Command::Render { in_data, mut params, output, .. } => {
                // ...
            }
            Command::GpuDeviceSetup { in_data, mut out_data, extra/*: GPUDeviceSetupExtra*/ } => { ... }
            // ...
        }
    }
}

register_plugin!(PortablePlugin);

basically the idea is to only expose relevant and valid data in each command, including all extras properly casted. I have that implemented so far, but I have a few concerns I wanted to discuss:

Struct instances

1. Should we create and maintain global instance for user? What I imagine is that PortablePlugin struct would be stored in global_data and would be a single object alive for the entire time the project is open (and any plugin instance is added to the layer)
2. Should we create and maintain sequence instance for user? That would be a separate struct, which is unique per every layer where the plugin is applied. This would be stored in sequence_data and I imagine I would require the user to make this struct serde::Serialize and serde::Deserialize and automatically handle flattening the data with bincode. Also that struct should be Send + Sync I believe, because AE can call the commands from any thread at any time? Is that correct?

I believe these two points are very useful for almost all plugins and at the same time quite time-consuming to implement properly by the user.
Pros:

• User can focus on just his actual plugin code without worrying about complicated details of Handles and flattening
• Much easier to get started with writing plugins

Cons:

• A bit of memory overhead, since the instances would be always created. But since we're talking about video processing plugins here, any overhead like that is nothing compared to actual pixels processing so it should be fine. We could maybe make this optional with a register_plugin macro parameter or something

Parameters

1. What do you think to create something like ParameterRegistry, which would be a manager for user params, with the enum-based getter/setter provided by user, and all parameters would be defined and retrieved using this enum. Something like:

enum MyParams {
    MixChannels
};
fn handle_command(&mut self, cmd: Command) {
    match cmd {
        Command::ParamsSetup { mut params } => {
            params.add_param(MyParams::MixChannels, 
                "Mix channels", 
                ae::FloatSliderDef::new()
                    .set_value(10.0)
                    .precision(1)
                    .display_flags(ae::ValueDisplayFlag::PERCENT)
            );
        }
        Command::Render { mut params, .. } => {
            let slider = params.get::<ae::Param::FloatSlider>(MyParams::MixChannels);
            // slider.value()
        }
    }
}
register_plugin!(PortablePlugin, MyParams);

That struct would maintain params array, indexes and counts (and would be stored in global instance data), so users won't have to worry about it.

I'll have more things to discuss once I get further, but let's start with these.

Let me know your thoughts, thanks!

CC @virtualritz @mobile-bungalow

Just recording an undocumented tidbit from the Ae SDK list here:

The Pipl file effect version has to match PF_VERSION returned value otherwise you are limited to Max 7 for MAJOR_VERSION

    out_data->my_version = PF_VERSION(    MAJOR_VERSION,
                                        MINOR_VERSION,
                                        BUG_VERSION,
                                        STAGE_VERSION,
                                        BUILD_VERSION);    

Good thing to know for new plugins... as it has a limited purpose , plugin who currently somehow use VERSION defines for other things, can work around this with extra defines (locking MAJOR to 7 and shifting MAJOR to MINOR)...