Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
19th June 2007, 16:42 | #1 | Link |
Registered User
Join Date: Aug 2004
Location: Denmark
Posts: 807
|
extending IScriptEnvironment->AddFunction function in avisynth 2.6
I think it might be a good idea to extend the parameter string in env->AddFunction to include a valid range for each type to support program like AvsP. Adding a optional valid range inside curly brackets like this
env->AddFunction( "Blur", "cf[]{[-1.0 - 1.5849625]}f[mmx]b", Create_Blur,0); to indicate the valid range for the float is from -1.0 to 1.5849625 ranges could be specified by using [] as a closed interval and ][ as an open interval. More than one range could be joined by using +. Any thought about this? Of course some range are defined from the input clip like crop depends on the size of the input clip. It would be more difficult to include this( maybe using something like args[0].width ?)
__________________
Get my avisynth filters @ http://www.avisynth.org/tsp/ |
19th June 2007, 17:59 | #2 | Link |
Registered User
Join Date: Sep 2005
Location: 100011110010001000001 10000011111111000001
Posts: 221
|
It would be better if any range information is positioned at the end of the parameter string, say following a "!" character. This would allow to store it in a separate LocalFunction field and make no changes to the TypeMatch code (which is called on each function name lookup).
Thus, we get added functionality for only those that need it without impact on lookup execution speed. We only pay a small one -time fee during function registration.
__________________
AVSLib, a free extension library for Avisynth. Current version: 1.1.0 (beta), 14/05/2007. [ Home page | Download page ] |
19th June 2007, 19:20 | #3 | Link |
Registered User
Join Date: Aug 2004
Location: Denmark
Posts: 807
|
you could extract the range information before storing the param in FunctionTable.AddFunction. Anyway the lockup only occur during filter graph construction(unless conditional functions are used).
I think it is easier to manage when the range comes with the param type at least for the functions with lots of parameters (like fft3dfilter).
__________________
Get my avisynth filters @ http://www.avisynth.org/tsp/ |
19th June 2007, 21:42 | #4 | Link |
AviSynth plugger
Join Date: Nov 2003
Location: Russia
Posts: 2,183
|
IMO the range is not important.
for example for ftt3dfilter we probably may use sigma=1000 or more. How useful is it? And good filter usually can say about parameters out of range. But default values are important instead IMO. It is useful to know them to adjust.
__________________
My Avisynth plugins are now at http://avisynth.org.ru and mirror at http://avisynth.nl/users/fizick I usually do not provide a technical support in private messages. |
19th June 2007, 23:16 | #5 | Link | |
Registered User
Join Date: Sep 2005
Location: 100011110010001000001 10000011111111000001
Posts: 221
|
Quote:
The virtue of my proposal is that you don't need to make the standard executing code more complex (apart from scanning for the ! at AddFunction, assigning the location to a pointer and executing an additional strdup). The rest of the complexity can be placed in a separate routine that will be used only by the software that needs this information; users that do not use such software will not need to pay for that. The management is also easy, using string concatenation; cf. the following two examples, where I propose a format for the string inside [], which can handle nicely multiple ranges (parentheses denote optional components): (name|)default value|range_low,range_high(|range_low,range_high(|range_low,range_high(...)) first example for short param_types: Code:
env->AddFunction( "Blur", "cf[]f[mmx]b" "!" "cf[1.0|-1.0,1.5849625]f[mmx]b", Create_Blur,0); Code:
env->AddFunction( "Blur", "cf[]f[mmx]b" "!" "cf[1.0|-1.0,1.5849625]f[mmx]b", Create_Blur,0);
__________________
AVSLib, a free extension library for Avisynth. Current version: 1.1.0 (beta), 14/05/2007. [ Home page | Download page ] |
|
20th June 2007, 02:13 | #6 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
"cf{-1.0..1.5849625}[]f{-1.0..1.5849625}[mmx]b" might be a more managable syntax, i.e add the {...} after an "f" or an "i", no extra []'s to confuse the poor parser authors.
Example:- "ci{0,1,2,4,8,16}[plugh]f{-20.5..-10.5,10.5..20.5}" mandatory 1st arg, a clip. mandatory 2nd arg, an int with 6 legal values. optional 3rd arg, name "plugh", a float with 2 ranges. Also how would you handle ".", "+" and "*"? Remember the internal functions are not AddFunction'd the compiler builds builtin_functions[] directly, so this will need to parse at script load time. I don't think range validating arguments is going to break the CPU, lots of other things are already many times slower than this. |
20th June 2007, 08:41 | #7 | Link | |
ffdshow/AviSynth wrangler
Join Date: Feb 2003
Location: Austria
Posts: 2,441
|
Quote:
Of course, all of the above will only work for plugins in DLL form; something similar would also be needed for AVSI script functions like LimitedSharpen et al as far as GUIs are concerned...
__________________
now playing: [artist] - [track] ([album]) |
|
20th June 2007, 09:40 | #8 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Default values handling would be a bit further out of left field.
Default value processing is currently done in the filter creator from ...AsFloat(default); like statements. Moving default value processing up into the parser would be a significant cultural change, but could have benefits. Supporting these concept for .AVSI function declarations would need a change to the function syntax. Perhaps the 3.0 people have some thoughts, especially as they are working up a completely new syntax. |
20th June 2007, 12:14 | #9 | Link |
Avisynth 3.0 Developer
Join Date: Jan 2002
Location: France
Posts: 639
|
That's how it works in 3.0.
The parser resolves the defaults himself and always calls functions with all the args. I think it's cleaner that way, defaults really belong to Filters (Script functions) and not to Filters (Clip subclasses). |
21st June 2007, 09:14 | #11 | Link |
Avisynth 3.0 Developer
Join Date: Jan 2002
Location: France
Posts: 639
|
Pretty much the same than the old one, but adding the return type of the function.
Code:
function clip Foo(Clip c, int i = 0) Code:
function clip Bar(clip c, int i, int j = i + 1) |
23rd June 2007, 07:34 | #12 | Link |
Stray Developer
Join Date: Mar 2003
Location: Italy
Posts: 82
|
What about passing a pointer to a parameter validation function?
For example, to allow more complex rules like (assume param0 is a clip, and the others are floats) Code:
switch (param0.colorSpace) { case CS_YUY2: if (width % 4) throw avisynthValidationError("with YUY2, width should be mod 4"); break; case CS_YV12: if (width % 8) throw avisynthValidationError("with YV12, width should be mod 8"); break; default: throw avisynthValidationError("input colorspace should be YUV"); } if (param1 > 0) { if (param2 > param1) { throw avisynthValidationError("param2 should not be greater than param1"); } } else { if (param2 < 0 || param2 > 1) { throw avisynthValidationError("param2 should be between 0 and 1"); } } Eventually, avisynthValidationError could be used to carry some kind of machine/GUI-readable information... C++ (via boost, maybe?) should allow something like Code:
throw avisynthValidationError< paramBetween<0, 1, "param2"> >("param2 should be between 0 and 1"); Last edited by CAFxX; 23rd June 2007 at 07:42. |
23rd June 2007, 22:00 | #13 | Link |
Registered User
Join Date: Aug 2004
Location: Denmark
Posts: 807
|
CAFxX: that doesn't solve the problem of providing the range of the parameters to a GUI. Also it should support gui's written in other languages than c++ as it does now by saving the filter parameter string in an script environment variable.
__________________
Get my avisynth filters @ http://www.avisynth.org/tsp/ |
24th June 2007, 08:52 | #14 | Link |
Stray Developer
Join Date: Mar 2003
Location: Italy
Posts: 82
|
The first issue can be overcome somehow, but I have to admit that the second is rather difficult. My fault: everything I coded for avisynth in the past has always been written in C++.
Nevertheless, the actual proposed solution can't handle complex validation rules (although it's way easier to implement). Maybe someone else will be able to come up with something better... |
24th June 2007, 22:23 | #15 | Link |
AviSynth Enthusiast
Join Date: Jul 2002
Location: California, U.S.
Posts: 1,267
|
What's the real need for this? Why complicate the code and that part of the grammar for little gain?
I think functions should just assert that their inputs are in range themselves. Then their validation rules can be however complex they need them to be, and the functions can provide more specific error messages. |
24th June 2007, 22:45 | #16 | Link | |
Stray Developer
Join Date: Mar 2003
Location: Italy
Posts: 82
|
Quote:
Mind: I'm not saying that my proposal is the way to go, but simply that it may be a good idea to carefully think about it in the planning stage (to avoid whining GUI authors afterwards). Last edited by CAFxX; 24th June 2007 at 22:47. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|