AviSynth+ thread Vol.2

[manolito]

Well, I do not pretend to understand all this AVS runtime stuff, but I do make tests and I can interprete the results.

And my test results do make a lot of sense to me. If you have "M = EMskip.GScriptClip" then you assign a mask (EMskip is not a valid video clip, it is just a mask). And whatever you do with this mask with all the GScriptClip calls, the end result will still be a mask instead of a video clip.

Using "M = M.GScriptClip" instead will apply the GScript calls to the real masked video clip M instead to just a mask. And "M" is returned as the result of MX_FPS (unless you specify otherwise).

Whatever, I tested it using a short 1 minute clip using all the different methods which came up so far, and the resulting clips were all bit identical. Speed was also the same. Of course I know that a 1 minute clip does not mean much, it could be that the thresholds for SkipOver and BlendOver were not reached, but basically it seems that all the different methods are valid.

[Gavino]

EMskip is not a valid video clip, it is just a mask
Ah, does it have different properties (dimensions or colorspace) from M and the other clips?

I was assuming all the clips were similar in these respects (and StainlessS's test assumed that too). Since the clip properties of the result of ScriptClip are taken from its input, that could be the difference.

[StainlessS]

Was tryin' to find "ConvertFpsLimit" dependency, and found that I did compile of non SSE2 ie C + MMX/iSSE for Mani, dont recall doing that at all :( [memories, like the corners of my mind ...]
C + MMX/iSSE version here:- https://forum.doom9.org/showthread.php?p=1876121#post1876121

OK, I've got full script working now.

Mani's/MysteryX original Scriptclip version but removed string() stuff using args, and also removed Scriptclip internal M (using Last instead)
NOTE, this is still the version that is logically different to the commented out conditionalfilter stuff.

## Apply BlendOver and SkipOver
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("Skip = EMskip.AverageLuma()
(SkipOver>0 && Skip>=SkipOver) ? BHard : (BlendOver>0 && Skip>=BlendOver) ? B : Last",
\ args = "EMskip,Blendover,SkipOver,B,BHard", Local=true)


Same but with same logic as conditionalfilter stuff

## Apply BlendOver and SkipOver
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("
Skip=EmSkip.AverageLuma
(Blendover<=0 || Blendover>Skip)? Last : (SkipOver<=0 || SkipOver>Skip) ? B : BHard",
\ args="EMskip,Blendover,SkipOver,B,BHard",Local=true)

Both work but dont know which is best (presume the conditionalFilter logic one)
Previoulsy 'M' now Last marked in blue.

EDIT:
@ Gavino,
EmSkip is (for JohnMeyer Parade clip) 32x24 pixels, so is a lot smaller than others.

Is derived from Mvtools SAD and Occlusion Masks and

# Create skip mask
EMskip = EM.BicubicResize(Round(C.Width/BlkSize/4.0)*4, Round(C.Height/BlkSizeV/4.0)*4)
\ .mt_expand(mode= mt_circle(zero=true, radius=1))
\ .mt_binarize(SkipTrh)

[manolito]

Both work but dont know which is best (presume the conditionalFilter logic one)


MysteryX abandoned the GScriptClip stuff in favor of the ConditionalFilter logic some time ago, so you are probably right to assume that the ConditionalFilter logic works better.

But MysteryX used his own ConditionalFilterMT function because he determined that the internal ConditionalFilter function was not compatible with multithreading. And unfortunately this ConditionalFilterMT function does not work on my old PC because it requires SSE2.

So here my question again: (to pinterf)
Is it still true for current versions of AVS+ that ConditionalFilter is not compatible with multithreading?
Because if this is no longer true then I can easily ditch all this GScriptClip stuff and use ConditionalFilter instead. Would make my life much easier...

[StainlessS]

Mani, Point out for Pinterf, where it was that MX said that [might be some clues as to reason].

[manolito]

I think I posted it before, but cannot find it right now...

https://github.com/mysteryx93/FrameRateConverter

ConditionalFilterMT

Avisynth+ MT provides great capabilities to process videos. However, conditional functions are not compatible with MT (multi-threading) due to design limitations. To work around this problem, this class provides a subset of conditional features that will work with MT mode.

[pinterf]

But MysteryX used his own ConditionalFilterMT function because he determined that the internal ConditionalFilter function was not compatible with multithreading. And unfortunately this ConditionalFilterMT function does not work on my old PC because it requires SSE2.

So here my question again: (to pinterf)
Is it still true for current versions of AVS+ that ConditionalFilter is not compatible with multithreading?

The multithreading issues with runtime filter family (ConditionalFilter and ScriptClip) have been fixed.

[Gavino]

@ Gavino,
EmSkip is (for JohnMeyer Parade clip) 32x24 pixels, so is a lot smaller than others.
Thanks.
That explains why using EmSkip.GscriptClip() didn't work, as the result will also be 32x24.

[vcmohan]

both, fftw3.dll were used to be old one that come with FFT3DFilter, the default name for new one one is libfftw3f-3.dll

Today I checked my source code and found that I have been checking first libfft3f-3.dll and then others. So that does not require change.

[pinterf]

(MP pipeline and other things are being solved)

[pinterf]

Dear all, download
Avisynth+ v3.6.1 test build 5 (20200603) (https://drive.google.com/file/d/1BDHHCj_HD4fogQ4zKm5C6eQPzrm2zNJj/view?usp=sharing)
Addressing mp_pipeline and further CPP 2.5 compatibility fixes (GRunT CPP 2.5 runtime filters, AverageLuma, etc.)
New: Histogram("Levels"): add greyscale support

[Groucho2004]

Dear all, download
Avisynth+ v3.6.1 test build 5 (20200603) (https://drive.google.com/file/d/1BDHHCj_HD4fogQ4zKm5C6eQPzrm2zNJj/view?usp=sharing)
Addressing mp_pipeline and further CPP 2.5 compatibility fixes (GRunT CPP 2.5 runtime filters, AverageLuma, etc.)
New: Histogram("Levels"): add greyscale supportThank you Ferenc. Weren't you supposed to take a break for a couple of weeks?

[pinterf]

No, I can't sleep well if I know that there are unfinished stuff. And I want to close this giant modification wave as soon as possible.

[Groucho2004]

No, I can't sleep well if I know that there are unfinished stuff.I know the feeling. It can be unhealthy though.

[FranceBB]

Dear all, download
Avisynth+ v3.6.1 test build 5 (20200603) (https://drive.google.com/file/d/1BDHHCj_HD4fogQ4zKm5C6eQPzrm2zNJj/view?usp=sharing)
Addressing mp_pipeline and further CPP 2.5 compatibility fixes (GRunT CPP 2.5 runtime filters, AverageLuma, etc.)
New: Histogram("Levels"): add greyscale support

Well I'm really sorry to say this 'cause you need some rest, but... it doesn't work. It starts allocating RAM and it creates the processes, however instead of showing the result, it outputs this error:


MP_Pipeline("""
ColorBars(848, 480, pixel_type="YV24")

### ###

""")


https://i.imgur.com/P6ud7HD.png


MP_Pipeline("""
ColorBars(848, 480, pixel_type="YV12")

### platform: win32
### ###

""")


Same error.



MP_Pipeline("""
DirectShowSource("I:\Production\431.avi")

### platform: win32
### ###

""")


Same error.
(DSS 'cause I'm too lazy to wait ffms2 to index a test file).

I also tried it with a real script and it didn't work.

As to the Histogram() thing, well done updating it. I wonder if Histogram("color2") will get high bit depth in the future since it's currently limited to 8bit only. :)
No pressure at all, anyway. Take your time and have proper rest, you deserve it. :)

[pinterf]

And with a return last?
edit: before the last """ line

[manolito]

Results for 3.6.1 test 5: (only testing the x86 version)

HDRAGC still crashing with an access violation. This is under Win7-64 as well as under WinXP. Test version 2 has no problems with HDRAGC.

[FranceBB]

And with a return last?
edit: before the last """ line

Return last did solve the problem.
I even tried it with a real-world script and it worked just fine allocating its 4.3 GB of RAM and delivering the correct output:


MP_Pipeline("""
video1=DGDecode_MPEG2Source("\\VBOXSVR\Share_Windows_Linux\Production\RAW\424-430\opening_ending_textless.d2v")
audio1=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\424-430\opening_ending_textless T80 2_0ch 224Kbps DELAY 0ms.ac3")
AudioDub(video1, audio1)

opening=trim(0, 2715).ConvertFPS(23.976)

ending=trim(5436, 8175).ConvertFPS(23.976)

### export clip: opening, ending
### platform: win32

video2=DGDecode_MPEG2Source("\\VBOXSVR\Share_Windows_Linux\Production\RAW\417-423\421.d2v")
audio2=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\417-423\421 T81 2_0ch 224Kbps DELAY -115ms.ac3")
AudioDub(video2, audio2)

### export clip: opening, ending
### platform: win32

tfm(mode=1,pp=5,slow=2,micmatching=2,clip2=tdeint(mode=2,type=3))
tdecimate()
ConvertFPS(23.976)

### export clip: opening, ending
### platform: win32

opening++trim(2279, 6400)++trim(8799, 32938)++ending

### ###

Dither_convert_8_to_16()

### ###

nnedi3_resize16(target_width=1920, target_height=1080, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4,
threads=0, tv_range=true, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=true)

### ###

dfttest(sigma=64, tbsize=1, lsb_in=true, lsb=true, Y=true, U=true, V=true, opt=0, dither=0)

### ###

ConvertFromStacked()

### ###

aWarpSharp2(thresh=180, blur=3, type=0, depth=35, depthC=10, chroma=4)

### ###

ConvertBits(bits=8, dither=1)

### ###

FastLineDarkenmod(strength=128)

### ###

f3kdb(range=15, Y=45, Cb=30, Cr=30, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false,
opt=3, mt=true, keep_tv_range=true, input_depth=8, output_mode=1, output_depth=16)

### ###

nnedi3_resize16(target_width=3840, target_height=2160, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0,
pscrn=4, threads=0, tv_range=true, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=true)

### ###

ConvertFromStacked()

### ###

Tweak(sat=1.51, dither=true)

### ###

ConvertToStacked()

### ###

s16 = last
DitherPost (mode=-1)

TextSub("\\VBOXSVR\Share_Windows_Linux\Production\Subs\Ep 421.ass")

Dither_convert_8_to_16 ()
s16.Dither_limit_dif16 (last, thr=1.0, elast=2.0)

### ###

ConvertFromStacked()

ConvertYUVtoXYZ()

ConvertXYZtoYUV(Color=1, pColor=2)

return last

""")


https://i.imgur.com/a3aqI7Y.png

(you can't see some of the processes in the screenshot, though, but it works).


Results for 3.6.1 test 5: (only testing the x86 version)

HDRAGC still crashing with an access violation. This is under Win7-64 as well as under WinXP.

I can reproduce that.

DirectShowSource("I:\Production\431.avi")

HDRAGC()

https://i.imgur.com/s0jSljF.png

[pinterf]

Thanks, (and I found a buffer overflow for YUVA transfer in MP_Pipeline, but since this format is not much used yet, the priority for the fixed release is low).

[pinterf]

Daily test build 3.6.1-test6 (https://drive.google.com/file/d/1maXp53tQ2Vc-b91QyL8UpEYQd0a-OLY2/view?usp=sharing)
Further v2.5 things (HDRAGC issue)
"return last" is not needed when script ends with a function definition

[gispos]

Daily test build 3.6.1-test6 (https://drive.google.com/file/d/1maXp53tQ2Vc-b91QyL8UpEYQd0a-OLY2/view?usp=sharing)
Further v2.5 things (HDRAGC issue)
"return last" is not needed when script ends with a function definition
Yes, MP_Pipeline is running, but

dear pinterf, is that all because of the arrays?

I can only imagine a few things I could do with arrays (I'm just an average user).

But I don't want to exchange the loss of some plugins for it. I think I'm not the only one with this thought.
Did you really take the right path? In any case you have my sympathy.

[Gavino]

"return last" is not needed when script ends with a function definition
This has always been so, at least in 'classic' Avisynth.
(or is this a bug-fix for something that crept in recently?)

Simple test:
Version()
function f() { return 0 }

[StainlessS]

(or is this a bug-fix for something that crept in recently?)

Return Last requirement in mt_pipeline arose quite recently:- https://forum.doom9.org/showthread.php?p=1906156#post1906156

EDIT: Hmm, you cant quote from a previously Closed thread [eg old Avs+ thread]

By GisPos
MPP requires a 'return last' in the last section for NEO builds.
I take it MPP means mt_Pipeline. [EDIT: I mean MP_Pipeline]

[gispos]

Yes that related to MP_Pipeline.
I don't need a return last for this test version.
I didn't think that was bad either, you just had to know.

[FranceBB]

Daily test build 3.6.1-test6 (https://drive.google.com/file/d/1maXp53tQ2Vc-b91QyL8UpEYQd0a-OLY2/view?usp=sharing)
Further v2.5 things (HDRAGC issue)
"return last" is not needed when script ends with a function definition

HDRAGC() now works fine:

#crappy simple test


video1=DGDecode_MPEG2Source("\\VBOXSVR\Share_Windows_Linux\Kyou kara Ore wa!! EP02 1080i.d2v")
audio1=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Kyou kara Ore wa!! EP02 T80 2_0ch 224Kbps DELAY 0ms.ac3")
Spline64Resize(704, 396)
sdr=last
hdr=HDRAGC()

StackVertical(sdr, hdr)

#for those script nazi (does such a word exist? like grammar nazi but for Avisynth scripts?)
# that lurked at the name of first file I found and indexed to make this simple stupid test
#and really wanna know why it's saying 1080i but I resized it without deinterlacing,
#the reason is that it's just 29.970 progressive flagged as interlaced


https://i.imgur.com/JjiCrp0.png

And I tried MPPipeline with the very same script I tried before but without the return last and it works without it now! :D
Very well done, Ferenc, just in time for the weekend.
You really deserve to rest now. :)

[manolito]

This latest 3.6.1-test 6 version looks like a winner to me... :D

HDRAGC now works under Win7-64 as well as under WinXP. Under XP I also tested it using all my old (and very very old) CPP 2.5 plugins, and all of them did not cause any problems.

MT stability is also very good. Right now I am running an encode on the WinXP machine (which has a single core CPU) with Prefetch(2), and it is slightly faster than without MT, and it is also stable. Kudos to pinterf...

[FranceBB]

Actually I gotta say that I found yet another thing... (sorry).
MPPipeline works, but if you go to XYZ and then come back to YUV it doesn't work...


MP_Pipeline("""
ColorBars(848, 480, pixel_type="YV12")

ConvertBits(16)

### ###

ConvertYUVtoXYZ()

### ###

ConvertXYZtoYUV(Color=1, pColor=2)

""")


https://i.imgur.com/R9ZHWRX.png

It's supposed to be showing color bars in BT2020 SDR YUV but it clearly isn't...
Of course if I make the conversion inside the very same block it works, but since you were asking about MPPipeline issues... well... this is one.
Of course, XYZ isn't officially supported by Avisynth as color space, so I don't know what Jean Philippe made inside his plugin to display it in Avisynth and work inside such a wide colorspace...
Anyway, this is one of the reasons why on the 25 of June 2018 I said that it would be nice in the future to have XYZ support inside Avisynth and perhaps one day it will happen... :')

[StainlessS]

This has always been so, at least in 'classic' Avisynth.
(or is this a bug-fix for something that crept in recently?)

Simple test:
Version()
function f() { return 0 }

No prob in v3.6.1 test6

EDIT:
You mean 3.6.1 test6, right?
Fixed

[manolito]

No prob in v2.6.1 test6

You mean 3.6.1 test6, right?

[manolito]

MPPipeline works, but if you go to XYZ and then come back to YUV it doesn't work...


Does this work under AVS+ 3.5.1?

Because if it does then pinterf has some more work to do, but if it doesn't then I think a more radical approach would be needed.

[ravewulf]

PremiereAVSPlugin v1.95 (https://sourceforge.net/projects/videoeditorskit/files/PremiereAVSPlugin/1.95/) causes Premiere CS3 to crash with both 3.6.0 and 3.6.1 test6 while it was working with previous versions of AviSynth+. I'm not too skilled in C/C++ (web development is more my forte) but was able to compile a debug version of PremiereAVSPlugin to find where the crash was within the plugin. Note that compiling requires premiere_pro_cs3_r1_sdk_win.exe or similar and the project on SourceForge needed to be modified to include some existing header/cpp files that weren't loaded by default.

GetInfo.cpp Line 299

res = fi->scriptEnvironment->Invoke("Import", AVSValue(&arg, 1));

Exception thrown at 0x26E1938C (AviSynth.dll) in Adobe Premiere Pro.exe: 0xC0000005: Access violation reading location 0xC7FBC448

I'm guessing it could use updating to new interfaces but the project seems to be abandoned given it was last updated in 2009 and I'm not sure how to fix it myself. Probably a low priority issue as I can work around it by skipping the Premiere plugin and either using MakeAVIS to create a "fake" avi for Premiere to load or else rendering out an actual avi file. More of a "nice to have" if it can be fixed

[pinterf]

[[/code]
I'm guessing it could use updating to new interfaces but the project seems to be abandoned given it was last updated in 2009 and I'm not sure how to fix it myself. Probably a low priority issue as I can work around it by skipping the Premiere plugin and either using MakeAVIS to create a "fake" avi for Premiere to load or else rendering out an actual avi file. More of a "nice to have" if it can be fixed
I have placed you two links at the first post (https://forum.doom9.org/showthread.php?t=181351) in this thread.
I'm curious so
- first: please try your _existing_ plugin with the test7 avisynth.dll (only 32 bit version provided)
- second: try the _updated_ plugin (Avisynth version can remain)
Let me know your results after both cases.

[pinterf]

This has always been so, at least in 'classic' Avisynth.
(or is this a bug-fix for something that crept in recently?)

Simple test:
Version()
function f() { return 0 }
That was a recent one.
It was a regression (appearing in 3.6) after incorporating Neo-fork updates.

[pinterf]

Actually I gotta say that I found yet another thing... (sorry).
MPPipeline works, but if you go to XYZ and then come back to YUV it doesn't work...


MP_Pipeline("""
ColorBars(848, 480, pixel_type="YV12")

ConvertBits(16)

### ###

ConvertYUVtoXYZ()

### ###

ConvertXYZtoYUV(Color=1, pColor=2)

""")



Well, the output of ConvertYUVtoXYZ() is using RGB64 and not planar RGB, probably we could eliminate the use of 'packed' formats and prefer planar RGB instead.

And why you saw such blackness: because I prepared MP_Pipeline high bit depth for planar colorspaces only and forgot about RGB48 and RGB64. Until then use a ConvertToPlanarRGB(A) after the YUV-XYZ conversion.
edit: Check MP_Pipeline 0.21 (https://github.com/pinterf/MP_Pipeline/releases/tag/0.21)

[Reel.Deel]

PremiereAVSPlugin v1.95 (https://sourceforge.net/projects/videoeditorskit/files/PremiereAVSPlugin/1.95/) causes Premiere CS3 to crash with both 3.6.0 and 3.6.1 test6 while it was working with previous versions of AviSynth+.

This wont fix your problem but there is another variant of this plugin that supported CS3 and CS4, also released in 2009. I wonder if they have the same problem. I don't have any Adobe products so I can't test it myself.

csavs: Premiere CS AVS Importer for CS3 and CS4

https://web.archive.org/web/20180320124503/http://valion.net/csavs/


Later on there was an update to that plugin to support CS5 and 64-bit.

csavs64: Premiere CS AVS Importer x64 1.1 (pre CS5 plugins will not work)

setup: https://web.archive.org/web/20150324225527/http://pwolfamv.com/programs/csavs64/
source: http://pwolfamv.com/programs/csavs64/

[kedautinh12]

Pinterf was released PremiereAvsPlugin 1.96 for Avisynth+ and Avisynth 2.6 interface.
https://github.com/pinterf/PremiereAVSPlugin/releases

[kedautinh12]

Also updated MP_Pipeline
https://github.com/pinterf/MP_Pipeline

[ravewulf]

I have placed you two links at the first post (https://forum.doom9.org/showthread.php?t=181351) in this thread.
I'm curious so
- first: please try your _existing_ plugin with the test7 avisynth.dll (only 32 bit version provided)
- second: try the _updated_ plugin (Avisynth version can remain)
Let me know your results after both cases.

Not sure if this is expected but AvsPmod Version 2.6.2.5 gives an ignorable error with test7
Exception WindowsError: 'exception: access violation reading 0x9DE18AFD' in <bound method AVS_ScriptEnvironment.__del__ of <avisynth.AVS_ScriptEnvironment object at 0x03857690>> ignored


The results of the first test were a bit surprising. Using the test7 build with the existing Premiere plugin works if the script is video-only. But if the script has video and audio (or audio alone) it causes Premiere to crash. Tested with both external audio files and the built-in ColorBars function.

The new updated Premiere plugin works perfectly with video and audio for both 3.6.0 and 3.6.1 test7.

Let me know if you want me to test the old Premiere plugin with future test updates to see if the audio issue can be fixed as a test case for similar plugins. Otherwise, I'll just use the new version of the plugin you built. Thank you! :thanks:


This wont fix your problem but there is another variant of this plugin that supported CS3 and CS4, also released in 2009. I wonder if they have the same problem. I don't have any Adobe products so I can't test it myself.

csavs: Premiere CS AVS Importer for CS3 and CS4

https://web.archive.org/web/20180320124503/http://valion.net/csavs/


Later on there was an update to that plugin to support CS5 and 64-bit.

csavs64: Premiere CS AVS Importer x64 1.1 (pre CS5 plugins will not work)

setup: https://web.archive.org/web/20150324225527/http://pwolfamv.com/programs/csavs64/
source: http://pwolfamv.com/programs/csavs64/


Looks like the 32-bit version of this plugin has similar results to the first test where it crashes with 3.6.0, crashes with video+audio in 3.6.1 test7, and works for video-only clips in 3.6.1 test7.

I don't have the newer 64-bit versions of Premiere to test the 64-bit plugin though. I use CS3 to have audio playback and a zoom-able timeline while I work on cuts/timing issues then go back to 64-bit AviSynth/AvsPmod for everything else after exporting an EDL file. No need to sink a ton of money in subscription fees to Adobe for new features/encoding support I don't use ;)

[MeteorRain]

https://github.com/HomeOfAviSynthPlusEvolution/neo_f3kdb/issues/4

Seems like 3.6 added some enums from VapourSynth and thus directly conflicts with VapourSynth headers. Any good ways we can get around with it and include both headers in one file?

[feisty2]

https://github.com/HomeOfAviSynthPlusEvolution/neo_f3kdb/issues/4

Seems like 3.6 added some enums from VapourSynth and thus directly conflicts with VapourSynth headers. Any good ways we can get around with it and include both headers in one file?

you need "enum class"
https://godbolt.org/z/dKLqkB

[Selur]

I can confirm that HDRAGC works fine with Avisynth_3.6.1_20200604_test6. :)
And SmoothCurve also works now.
Thanks! Now I can switch to 3.6.x :)

[pinterf]

:stupid:you need "enum class"
https://godbolt.org/z/dKLqkB
Yes, I was planning that. But I'll guard it with ifdefs. You know it requires C++11.

[StainlessS]

You know it requires C++11.
Feisty, cares not a jot for compatibility.

[feisty2]

:stupid:
Yes, I was planning that. But I'll guard it with ifdefs. You know it requires C++11.

ancient compilers that do not even support c++11 up until this day should just die.

[feisty2]

besides there're many workarounds other than enums
you may use a namespace

namespace PropTypes {
constexpr auto ptUnset = 'u';
constexpr auto ptNode = 'n';
...
}

auto x = PropTypes::ptNode;


you may also place these constants in a struct as static variables

struct PropTypes final {
static constexpr auto ptUnset = 'u';
static constexpr auto ptNode = 'n';
...
};

auto x = PropTypes::ptNode;

[gispos]

Not sure if this is expected but AvsPmod Version 2.6.2.5 gives an ignorable error with test7
Exception WindowsError: 'exception: access violation reading 0x9DE18AFD' in <bound method AVS_ScriptEnvironment.__del__ of <avisynth.AVS_ScriptEnvironment object at 0x03857690>> ignored

Who wants to play with the avisynth test 7 version and AvsPmod.
This eliminates the window error message on startup.

Exchange the included library.zip with the one in the lib folder. 32bit only.

Removed. The problem is deeper

Edit: test7 seems to have a problem releasing the IScriptEnvironment

[stax76]

Seems like 3.6 added some enums from VapourSynth and thus directly conflicts with VapourSynth headers. Any good ways we can get around with it and include both headers in one file?

I just disabled these new definitions using comments, it's easy and for now works for me, I hope it doesn't become an issue in the future.

[MeteorRain]

The issue with the conflicts, for now, is that filters will include headers from system directories (/usr/include or whatever), so I can't touch that for now, unless I choose to ignore that and always use an old version of headers that I carry.

I think maybe I should just wait until the issue is resolved.

[tormento]

Out of curiosity: why do you keep devil.dll in a "system" directory, separate from avisynth.dll? They will go in the same windows directory, at the end.

[stax76]

Out of curiosity: why do you keep devil.dll in a "system" directory, separate from avisynth.dll? They will go in the same windows directory, at the end.

I wondered about that too.