Avisynth+

[pinterf]

Originally Posted by Stephen R. Savage

Wouldn't that conflict with a function named test_array? AVS does not prevent creating variables with the same name as functions.

Yes, there would be conflict.
Final solution should be something like that

black = [0,128,128]
test_array = [ ["ciao", black], ["hello",[1,1,2.718281]], ["null", []] ]
test_array = test_array + ["dummy"]
item = test_array[0]
item2 = test_array["hello"]
e = item2[2]

Provided the [ and ] symbols are not reserved.
Or { and }. Language experts will decide.

[Gavino]

Originally Posted by pinterf

Provided the [ and ] symbols are not reserved.
Or { and }. Language experts will decide.

[ and ] are currently used only for nestable block comments [* ... *].
Although technically possible, I recommend not using { and } as these are already well established as code block delimiters, whereas [] is familiar from other languages as indicating array indexing.

You could argue for using a different symbol, like { ... }, for array creation (as in C/C++ and Java), but I would prefer [] for both indexing and creation. There is no problem in distinguishing the two contexts in the parser even if the same symbol is used for both.

On a wider note...
You have so far shown examples of how the array features would be used in the script language.
From the plugin writer's point of view, I would also like to see a list of proposed API changes.
I imagine there will be changes to the public interface of AVSValue and possibly new ScriptEnvironment functions.

[pinterf]

Originally Posted by Gavino

On a wider note...
You have so far shown examples of how the array features would be used in the script language.
From the plugin writer's point of view, I would also like to see a list of proposed API changes.
I imagine there will be changes to the public interface of AVSValue and possibly new ScriptEnvironment functions.

I agree with [ and ].
I also wonder how can I do that with keeping backward compatibility. Anyway, I will return to the problem later, this will definitely need more time than that day I spent on it so far.

[Gavino]

Originally Posted by pinterf

I agree with [ and ].
I also wonder how can I do that with keeping backward compatibility.

Since [ and ] are currently illegal in scripts (except for [* and *]), what problem do you see with backward compatibility?

[pinterf]

Originally Posted by Gavino

Since [ and ] are currently illegal in scripts (except for [* and *]), what problem do you see with backward compatibility?

Sorry, I was thinking forward on AVSValue things and the possible interface additions.

[Gavino]

Originally Posted by pinterf

Sorry, I was thinking forward on AVSValue things and the possible interface additions.

Yes, that's certainly an area where careful thought will be required (although at the moment I can't see any specific problems).

[stranno]

I'm getting a "display error" with r2294 using ProRes 422LT source. Pre-2000 releases work fine. I have seen r2003+ releases support high bit depth colorspace so i'm not sure whats the problem.

Edit: I'm using FFMS2 2.23.

[pinterf]

Originally Posted by stranno

I'm getting a "display error" with r2294 using ProRes 422LT source. Pre-2000 releases work fine. I have seen r2003+ releases support high bit depth colorspace so i'm not sure whats the problem.

Edit: I'm using FFMS2 2.23.

Pre r2294 versions did not support 10,12 and 14 bit depths. Could you please try with the latest version?

[tuanden0]

I have a problem with Avisynth Plus r2294, can someone help me

I coppied the Avisynth.dll to System32 but i still error

[pinterf]

If you have installed 32 bit avisynth+ and have a 64 bit windows, the avisynth.dll must be placed to the SysWOW64 folder.
On 32 bit windows, system32 is O.K. for 32 bit avisynth.
But the installer should do this instead of you.
I suppose, there is another avisynth.dll somewhere, can it be set in avspmod?

[tuanden0]

Originally Posted by pinterf

If you have installed 32 bit avisynth+ and have a 64 bit windows, the avisynth.dll must be placed to the SysWOW64 folder.
On 32 bit windows, system32 is O.K. for 32 bit avisynth.
But the installer should do this instead of you.
I suppose, there is another avisynth.dll somewhere, can it be set in avspmod?

Yah, my fault, i forgot that

Thank you very much

[ajp_anton]

Originally Posted by pinterf

Yes, there would be conflict

But as mentioned, you can already create those conflicts with variable names. What makes array-name conflicts any different? Either you ignore the problem (allow conflicts), or you do something about it (throw error when conflicts happen, or require ()-brackets for functions), but you do the same thing with variable names and array names (aren't arrays also some kind of "variables"?).

Though I agree that []-brackets are better for arrays.

[Aktan]

I have an interesting problem. I have a Lagarith source AVI in RGB32 colorspace with the resolution of 350x240. If I open this AVI with AVS+, I get distorted video. From Info(), I noticed the video pitch is wrong. Then I realized 350 is not mod 4. Is this a known problem?

[Reel.Deel]

Originally Posted by Aktan

I have an interesting problem. I have a Lagarith source AVI in RGB32 colorspace with the resolution of 350x240. If I open this AVI with AVS+, I get distorted video. From Info(), I noticed the video pitch is wrong. Then I realized 350 is not mod 4. Is this a known problem?

What AVS+ version are you using?

[Aktan]

Originally Posted by Reel.Deel

What AVS+ version are you using?

r1576, x64

Edit: Well I guess it's an old version? lol.

[Reel.Deel]

Originally Posted by Aktan

r1576, x64

IIRC someone reported a similar problem way back. I believe it was fixed, try updating to the latest version. Report your findings .

Edit: maybe this? https://github.com/AviSynth/AviSynthPlus/issues/36

[Aktan]

Originally Posted by Reel.Deel

IIRC someone reported a similar problem way back. I believe it was fixed, try updating to the latest version. Report your findings .

Thanks, will do!

Edit: r2294 works fine =)

[Stephen R. Savage]

Originally Posted by ajp_anton

But as mentioned, you can already create those conflicts with variable names. What makes array-name conflicts any different? Either you ignore the problem (allow conflicts), or you do something about it (throw error when conflicts happen, or require ()-brackets for functions), but you do the same thing with variable names and array names (aren't arrays also some kind of "variables"?).

Though I agree that []-brackets are better for arrays.

There are no function pointers, so I believe AVS will use the presence of the parentheses token to identify a function name instead of a variable.

[Gavino]

Originally Posted by Stephen R. Savage

There are no function pointers, so I believe AVS will use the presence of the parentheses token to identify a function name instead of a variable.

It does indeed, but in principle it could be extended to try x(1) as an array indexing if it finds that there is no function named x - just as now, when it finds plain 'x' and there is no variable called x, it tries to treat it as a parameterless function call x().

However, I don't think that would be a good idea and the availability of [] makes it unnecessary.

[jpsdr]

A little question.
If i am with an YUVA 4:4:4 mode (for exemple), will IsYV24() still be true ?