New library with Avisynth script extensions

[gzarkadas]

Below are the links to a new extension library for Avisynth that I have developed in order to fulfill my needs as an Avisynth user for the various extras that I wanted to have in my scripts:

Download page: http://sourceforge.net/projects/avslib/
Online documentation: http://avslib.sourceforge.net/

The library currently offers the following main features:

A new container 'datatype' (the array) for all variable types (including clips' arrays and mixed types' arrays) and numerous functions, including operators, to handle arrays.

A large set of mathematic and statistical functions, that operate both on single variables and whole arrays.

A standard set of clip-editing functions which in addition they allow user-specified functions for arbitrary post-processing of result's parts, for example: implementation of transitions, filtering, insertion of cover-story (intro clips), etc.

A set of general purpose animation functions that animate position, size and opacity on succesive frame segments in one step, supporting all arguments of Overlay standard Avisynth function.

A set of functions to aid script debugging.

It is a stable, production version; see the example scripts at the documentation.

Any comments, suggestions or ideas for improvement are welcomed.

[Wilbert]

Great, that looks very impressive! I guess we've some reading and testing to do this week :)

[gzarkadas]

Thank you. I will be happy to answer any questions, should they arise during this process.

To help start with, there are ready test scripts along with their results both in the documentation and the distribution file to start with (the "Example scripts" section).

Also, before starting to code scripts it is essential that the "Limitations" page of the documentation is read, to avoid asking more than the library can deliver.

I would further recommend reading the "Backgrounders / Tutorials" articles, which provide an overview of the library internals.

[danpos]

Yep, it seems to provide more power to (already) powerfull AVISYNTH! :)

I will study it soon. ;)

THX for your time and efforts.

Cya!

[tsp]

It looks good but why didn't you implement it by creating a plugin (dll file)?

[stickboy]

Neat. I'll have to look at this in more depth later.

I skimmed through some of it, and a few parts look really familiar. Did you base (or copy) parts of it from some of my work? It's certainly okay if you did, since I released all of my scripts to the public domain. Still, if that indeed is the case, it seems like it'd be proper etiquette to give some form of attribution.

Also, it'd probably be good if you and I worked together to avoid name clashes. For example, my version of Undefined() is different from yours (but is equivalent to your Undef()). (Frankly I see no value in your Undefined(); !Defined() will do and has equal expressive power.)

[gzarkadas]

It looks good but why didn't you implement it by creating a plugin (dll file)?

For a long list of reasons, the most important of them presented at the end of this post as an appendix, to avoid cluttering those that may not be interested.

To give a one paragraph summary: Because it was challenging to do so and because I believe that Avisynth needs in the long-term native script language extension libraries; they add value because the power of scripting compared to a GUI implementation is that you can gradually build code to shorten repetitive tasks and rapidly implement new solutions to application-domain problems.

APPENDIX - (Partial) List of reasons

1. First of all it was a challenging mental exercise (especially the implementation of the array module); I like challenges :cool:, so I chose the hard way.

2. Second, because I assess that the script language has all the necessary constructs to create arbitrarily complex behavior, although of cource one will need more steps to achieve his/hers targets since he/she will have to start from the bare fundamentals.
However, if libraries exist, then development of new source code is faster (see the thread http://forum.doom9.org/showthread.php?t=96750; it took me just a part of one morning to implement the solution, because I already had the library to provide the hard parts of the implementation).
Therefore, I implemented it this way to provide a proof that building complex libraries with Avisynth script language is possible and in fact not inferior to the other alternative (see the next points, below).

3. For portability-related issues. Writing in an interpeted language is portable accross major version changes of the host application and across operating systems. Therefore, there is little chance that I will need to update even a single line of code when Avisynth 3 will come forward or whenever a port of Avisynth to Linux or Mac is done.

4. For maintenance-related issues. Packaging over 160 functions to a plugin is more difficult than placing them into source script files.
In addition, I have the intention to add in a later version a partial import scheme of the library for which having the ability to simply break code inside source script files and write a few headers is much more desired than distributing code across C++ projects and recompiling.

5. For speed-related issues. Interpreted code is always slower than compiled code but in our case the penalty is low because the interpreted code actually most of the time only administers calls to C++ functions (filters) and assignment of their results to variables. Most of the time spent to script execution is devoted to manipulation of large data streams by the (internal or plugin) C++ functions.
Thus, writing 'glue' code in avisynth script does not impose a serious performance penalty and in fact it repays more, because of rapid script development and the associated reduction of time spent by the script writer (IMHO computer's time is always a least expensive resource than human's time).

6. The filter SDK documentation in avisynth.org states that a plugin cannot return an array; thus impementing arrays with a plugin would be a complex task, because everything should be handled internally by the plugin since the actual array would never be possible to be returned and stored inside a script variable. Not to mention operations on arrays; I would end up writing a separate interpreter.

[gzarkadas]

Neat. I'll have to look at this in more depth later.

I skimmed through some of it, and a few parts look really familiar. Did you base (or copy) parts of it from some of my work? It's certainly okay if you did, since I released all of my scripts to the public domain. Still, if that indeed is the case, it seems like it'd be proper etiquette to give some form of attribution.

Also, it'd probably be good if you and I worked together to avoid name clashes. For example, my version of Undefined() is different from yours (but is equivalent to your Undef()). (Frankly I see no value in your Undefined(); !Defined() will do and has equal expressive power.)

I have used some of the names that you (and others also) have used, but since such basic functions or language primitives such as "min", "max", "throw", "insert", "delete", etc. have been around for many years in textbooks and example code all over the world, I cannot give attribution; I don't know to whom should I attribute. Not even most of the math or stat functions that I have included in the library (to use an obvious example) I consider them to originate from me; they are direct applications of math textbook formulas.

I have also used or built upon the implementation of a couple of your functions, notably Undef and IsCallable (I am using the library names), for which I will give attribution. As I will do to every other request that may arise; I have already prepared an attribution section in the library's documentation (at the 'Project Information' page, last section) which however I decided to leave empty in this very first release waiting first for Avisynth community's input regarding the library. It will be filled in the very next update.

Regarding the second part, I prefer 'Undef' because it is the same way names are #undefed in C/C++; 'Undefined' is better suited for a logical test function. I also consider it more consistent with the general style of the script language, which is basically C-style.

As a last comment, I also consider it good to work together, both with you and the other Avisynth community members, because one of the main reasons I have spent time to setup a project in SourceForge for this library, is to eventually work together on it with other developers.:)

[stickboy]

I have used some of the names that you (and others also) have used, but since such basic functions or language primitives such as "min", "max", "throw", "insert", "delete", etc. have been around for many years in textbooks and example code all over the world, I cannot give attributionOf course, and I certainly wouldn't expect anything for those.I have also used or built upon the implementation of a couple of your functions, notably Undef and IsCallable (I am using the library names), for which I will give attribution.Yeah, those two in particular are the ones that caught my eye. (Note that IsCallable is based on an idea from mf (http://forum.doom9.org/showthread.php?t=66627).)
Regarding the second part, I prefer 'Undef' because it is the same way names are #undefed in C/C++; 'Undefined' is better suited for a logical test function. I also consider it more consistent with the general style of the script language, which is basically C-style.Hm. That's an interesting point. So my motivation was that some other languages have a notion of an "undefined" type. For example, in JavaScript typeof(someUndefinedVariable) will yield the string "undefined". In this sense, then, you can treat "Undefined" as a constant (since AviSynth's parser, for better or worse, supports VB-like syntax for argument-less functions):
foo = undefinedAlso, #undef actively undefines a specified variable, but Undef() can't. #undef is an action, whereas Undef() simply yields a value.

And finally, my opinion is still that your definition of Undefined() offers nothing over !Defined() and therefore is a namespace collision for no compelling reason.