Thanks. Will look at it soon.
EDIT: This YUY2 bug probably exists since forever (quicky tested with r2266), occurs when width is less than 8.
EDIT2: Crash happens when RGB32 has width<4, and RGB64 width<2

I've been using AviSynth 32bit, now upgraded to AviSynth+ with that "use my old plugins" option.

Now my problem is, any time an error occurs, it seems I only get "Avisynth open failure: System exception - Access Violation". (Opening with VirtualDub or VirtualDub FilterMod)

64 Bit seems to output proper messages, for example when using with ffmpeg, but I am dependent on many 32 bit plugins from the old AviSynth.

Somewhere I read that the older release r1858-pfmod might work. I tried it (by replacing the dlls) and indeed now I got reasonable error messages like "function does not exist". I was even able to use loadPlugin to load ffms2 and load a clip with FFmpegsource2. The sad thing is, that version does not yet support deep color apparently, as it says it can't find the function ConvertBits.

Deep color is important to me and is the main reason I upgraded.

I am not sure what I'm doing wrong. I also tried running VirtualDub Filtermod as an administrator, no difference.

Interestingly, the error message does show the correct line in the script. When I move the loadPlugin for ffms2.dll down 2 lines, the error is shown as line 3 instead of 1.

But no matter what error it is, it's always just that System Exception. I can write "blahblurp" in there and still get a System Exception. This is not very helpful for debugging or finding errors.

I have a Windows 7 Ultimate 64 bit pc with an i7-3930k, 32GB RAM and a GTX 1070 on a Sabertooth X79, if it's any use.

Hope this can be resolved, as I have already tested the deep color functionality with the internal AVISource and it was pretty good! I hope to now be able to also use all my old plugins and get proper error messages.

Edit: I was able to avoid the error message altogether by calling ClearAutoloadDirs() in the beginning. Probably because I was using LoadPlugin anyway? Still, would be nice to resolve it.

EDIT: 64 bit provides error messages because it is not having a 32 bit plugin autoload problem.
Might also want to put ffms2 dll in autoload plugins directory, just to view the AvsMeter results relating to it. (can later remove)

EDIT: Some avs v2.6 plugins compiled with old avisynth header (prior to avisynth 2.6 Alpha 4) will crash if used on Avisynth v2.6 Alpha 4
and later, guessin that this may be the problem (because the older avs+ works ok, probably from pre alpha 4 era).

I tried what you said and entered that commandline, but all I get is a "Query Avisynth info..." stuck for minutes with CPU at 17% or so (probably one core).

Edit: Interesting point. So your theory is basically that there are incompatible plugins in my folder and they trigger the error, even if the one I'm actually requesting is not responsible for the error? (since I was able to load it with loadPlugin after disabling autoload)

EDIT: AvsMeter will probably not be able to tell you anything about bad plugin that is not compiled with later avisynth header,
Avsmeter might well crash for same reason as avisynth with old plugin in plugins directory. [EDIT: dont know if it checks AVS_linkage for NULL]
You may have to manually pinpoint bad plugins by trial and error (clear plugins, then add in batches of maybe 10 and test, then remove and try next batch, until problem batch located, then narrow down to bad plug [there may be more than 1 bad plug])

EDIT:

Quote:

Edit: Interesting point. So your theory is basically that there are incompatible plugins in my folder and they trigger the error, even if the one I'm actually requesting is not responsible for the error? (since I was able to load it with loadPlugin after disabling autoload)

Yes.

EDIT: Not sure, perhaps AVS_linkage=NULL, only produces a problem on last autoloaded bad plugin,
EDIT: Maybe not, I guess that AVS_linkage is private copy for each individual plugin.

@Jenyok,
Are you using an old version of Avisynth v2.6, If so, you need to update as ClipClop uses new AvisynthPluginInit3() only available in Alpha 4+ ?
(Or alternatively use the v2.58 dll).

There will (I think) be a reciprocal problem if plugin compiled with pre-Alpha 4 header, and not using AvisynthPluginInit3().
[So as previously posted in this thread, I was on the 'right track', but a bit back-to-front ]

@raffriff42: Big thanks for the documentation update, I was just about to do that for recent r2636 changes and saw that you have already done that.
I have added one or two things (e.g. ColorYUV supports float, levels "TV", gamma handling, Histogram "bits") and clarified AddAlphaPlane that it can use a single Y clip or a number as the source for Alpha plane.
I hope I kept the standard formatting.

Found an old comment
// sse2/mmx versions are not identical to C. Sharpen(1.0, 1.0) has ugly artifacts
I removed the sse/mmx code to run it in plain C and it became O.K. Now let's find the bug in the SIMD code.
EDIT: YUY2 sharpen overflow fixed on Github

Systems with a locale using a decimal dot need a decimal dot. If there are locale-independent functions to process numbers, they should default to this syntax.
Systems with a locale using a decimal comma need a decimal comma if numbers are processed depending on the locale.

It would be pretty strange if there were no more locale-independent number functions available under Windows 10, that would interrupt international data exchange in text form.

Implementing a locale-aware conversion in the script would be quite annoying, but possibly not impossible?! But finding a locale-independent implementation that works in Windows 10 as well should be preferable.

Implementing a locale-aware conversion in the script would be quite annoying, but possibly not impossible?! But finding a locale-independent implementation that works in Windows 10 as well should be preferable.

It should be AVS+ to work accordingly to windows local settings, not the script itself.

And an international portability of scripts can only work when the syntax (here: of numbers) is locale-independent.

Locale-dependent handling of numbers is fine in user interfaces, where an immediate relation between the widget a user fills with a value and the layout of the keyboard the user utilizes can be assumed.