AviSynth+ thread Vol.2

[almosely]

Hideho,

I just stumbled upon a new AVS+ release (my installed version is 3.4.0) while cleaning up my ff-bookmarks and found some confusing things. The following files are downloadable here:

1. AviSynthPlus-3.5.1_20200402.exe
2. AviSynthPlus-3.5.1_20200402_vcredist.exe
3. AviSynthPlus-3.5.1_20200402_vcredist_xp.exe
4. AviSynthPlus-3.5.1_20200402_xp.exe
5. AviSynthPlus_3.5.1_20200402_filesonly.7z

I guess #1 is the regular installer. The place to go if nothing is installed? Is it possible, to use this file to update the current avs-version without loosing any custum made configs too?

Do I need the file #2 (vcredist) when I choose to use file #5 (filesonly) or are there no differences between avs+ 3.4.0 and avs+ 3.5.1 regarding that?

What is "_xp" for (files #3 and #4) ? Windows XP?

So, and finally file #5 (filesonly). Within that .7z-archive are several folders:

- x64
- x64-xp
- x86
- x86-xp

I guess, the "-xp" is regarding Windows XP?

Then, within the "x64"-Folder there are some more folders:

- c_api
- plugins

What do I do with the "c_api"-folder? There are two files within:

- AviSynth.exp
- AviSynth.lib

Are they only needed in an SDK-environment and totally not needed for the running version (= just users)?

Then the "plugins"-folder; I guess the content of that folder has to be copied into the "plugins64+"-folder of my installed avs+ version?

And there are two files, outside the two folders:

- AviSynth.dll
- DevIL.dll

So, I guess, both are to be copied to "Windows\System32"?

... and regarding the "x86"-content ... The files within "plugins" has to be copied to "plugins+" and "AviSynth.dll" and "DevIL.dll" are to be copied to "Windows\SysWOW64"?

There's no documentation regarding that at all, sadly.

[gispos]

almosely your assumptions are all correct.
Copy the avisynth.dll and DevIL.dll into the correct system directory and the update is finished.
If you feel like it, you can also copy the plugins into the plugin directories.
I never do that, I just move the avisynth.dll. into the system directory.

[qyot27]

Yes, it can be installed over the previous install. Stuff suffixed with -xp are still WinXP compatible (but are not exclusively for XP). Installers suffixed with vcredist include the Visual C++ 2015-2019 Redistributable installer and runs it during the install process.

If you don't know which one to use, use #2.

[almosely]

Oh, thank you both! :-)

Therefore I manually switched the corresponding files (avisynth.dlls, devil.dlls and the plugins-folders), disposed the c_api- and xp-folders and downloaded up-to-date-versions of the already installed VC++ redists 15-19.

[pinterf]

Originally Posted by Groucho2004

So, these are the headers we should be using from now on?

Yes, but it IScriptEnvironment will still extend a bit.
My intention that these future extensions do not affect already defined elements.

[Groucho2004]

Originally Posted by pinterf

My intention that these future extensions do not affect already defined elements.

That's good to know.

[gispos]

Originally Posted by pinterf

My intention that these future extensions do not affect already defined elements.

also CUDA doesn't that
Do you also have CUDA in your sights? You're welcome.

[tormento]

Originally Posted by gispos

also CUDA doesn't that
Do you also have CUDA in your sights? You're welcome.

OpenCL is a much better future aware way to go.

It's not platform dependent and have lot of manifacturers supporting it.

Nonetheless CUDA has direct C++ and Fortran compiler support from at least Intel.

[tormento]

To whom redact AviSynth+ Wiki: what about starting to divide plugins into AVS supported interface versions?

It could be easier for programmers to start a revision of the missing plugins.

[StainlessS]

Post #5103 in original Avisynth+ thread updated[AvsVersion.avsi]:- https://forum.doom9.org/showthread.p...80#post1897680

[MeteorRain]

tormento: Agree.

Or having a table for each plugin indicating the support of HBD and x64, better if also indicating GPU version and Internal MT version.

Also would like to know if there's anything missing from famous scripts such as MCTD or QTGMC etc. (Especially HBD and x64.)

[pinterf]

Originally Posted by MeteorRain

I believe you have to specify "type[]" as type in VS. So it's 1D array of specific type. -- hopefully my memory serves right.

The main problem is "a" type will cause the filter to not run on non-array avs -- even same avs version that compiles without array support.

That's why I proposed a compatible way of annotating array. Again it's a premature idea, I haven't checked Invoke() and I'm not sure if it would work.

The most compatible way is to specify "." instead of "a" and you check the arrayness and throw a possible error in filter creation.

Anyway I'm now on eliminating the "a" and if possible I'm using ".*" or ".+" instead of that.

But I won't discriminate and will recognize arrays as named parameters using the "*" and "+" array-modifiers. I can use this internally. Such as new BlankClip has a parameter with signature "[colors]a"; direct color values can be specified. Now it became "[colors]f+" so it has to be an array of one or more floats.

This way I could even specify that the function requires float numbers in the array (which are converted to integer inside for integer color spaces) while the old version with "[colors]a" needed more checking (no zero size, no strings inside, etc.) in the filter creation.

So work in progress.

As I said using "." instead of array is working right now, compatible with anything.

Internally [paramname]f+ style is working as well but your external plugin will fail to load into older AviSynth versions if this parameter-list syntax is used.

If this concept works, I can try the proposed "()" modifier in the name of the parameter, which is expected to get your plugin loaded into any Avisynth version but still you can use the named parameter array concept if parameter is given when used in future Avisynth+. Thus a filter definition syntax [colors]f+ would become into [colors()]f or similar, but it's not too nice.

The incompatibility lies in (among other things) that named parameters should be followed by exactly one 'type' character

[MeteorRain]

In the example of c[sstring]s[ssx]s[sstring()]f[ssx()]f

The good thing is -- in old version it interprets it as
sstring: string
ssx: string
sstring(): float -- which can only be read by _args[3]
ssx(): float -- which can only be read by _args[4]

Because the plugin should not read anything beyond 2, all it could read are 1 clip and 2 strings.

In new version it interprets it as
sstring: string or float[]
ssx: string or float[]

so user can pass either string or array, and the plugin should detect if _args[1] and [2] is a string or an array. If it reads a string, it parses string to array. If it reads an array, it loops through it to get values.

Any non-identifier non [] characters can be used to indicate arrays. So for example, [colors()], [color*], [(colors)], [{colors}] should all work.

[MeteorRain]

And it's also possible to completely use a new syntax for argument list. Plugins can send the new version of argument type list instead of using the old one, if it's called by a new version of AVS. I'm never a fan of old syntax, so I think after more than 15 years, it's OK to remove some technical debt and move on. (And backward compatibility is also maintained.)

A very quick way is to use the same / similar format from VapourSynth.

c[sstring]s[ssx]s[sstring()]f[ssx()]f
becomes
clip:clip;sstring:float[]:opt;ssx:float[]:opt

Of course when called from old AVS, a plugin still returns old argument string. New AVS should also be able to parse the old syntax.

Just my $0.02.

[pinterf]

In what aspect is VS syntax more elegant aside from using [] for arrays?

[videoh]

Anyway, "elegant" is very subjective.

[wonkey_monkey]

Personally I can never remember whether the type comes first or the name comes first. VS syntax seems slightly more explicit in that regard.

[pinterf]

Originally Posted by wonkey_monkey

Personally I can never remember whether the type comes first or the name comes first. VS syntax seems slightly more explicit in that regard.

In case you'd forget just remember to clip:clip

[Reel.Deel]

Originally Posted by tormento

To whom redact AviSynth+ Wiki: what about starting to divide plugins into AVS supported interface versions?

It could be easier for programmers to start a revision of the missing plugins.

Feel free to get the ball rolling. A spreadsheet would be a good start

[qyot27]

Having a spot in the table for which OSes the plugins support would also be beneficial, as more of them begin to get ported to at least Linux, if not the other two.