3.0 progress

[esby]

3.0 Crew :
Me, alone (for now (I hope))


We have high hopes in human cloning, and will be able soon to chain produces Bidoche clones to work on the code ^^

Well more seriously, if you need any help and think it can be provided,
feel free to ask... :)

esby

[vispgraedde]

Thanks.
I just needed to know if any of the feature requests I think about maybe already was in the list.

One of those things was to make it easier to have a GUI frontend where you can see realtime results of filters that can be tweaked in realtime with GUI controls.
The GUI things I have seen so far for avisynth have simply been an editor that pulls up video when you save changes which is not what I need.

Another thing that I don't know if anyone is interested in at all (other than myself) is distributed processing and networked frameserving.
I only consider this as a nice feature to have, but it's not important. Maybe just keep in mind when working on 3.0, so that any future development on this path don't become too troublesome a task.

I'm thinking about other ideas as well, but let's leave it at this for now. I'd like to see what other people think about distributed processing and networked frameserving though.

[Kurosu]

More reports on the build process.

1) It seems the project includes folders Levels, Transform, Resize and Resize\Pattern. But no source files are actually present physically. The CVS is in a strange state, as one has to cvs checkout then cvs update before getting some of the src\ filters. Yet the above mentionned aren't present. Could you fix that, please?

2) CreateMessageClip isn't a member of StaticImage. But I guess you are working on that ;)

Apparently everything went fine once I changed $(VCINSTALDIR)stlport to $(VCINSTALDIR)include\stlport to fix my own error (don't laugh, it took me 20 minutes to figure out). As it hasn't yet reached the linking stage (I don't want to play around with the project file untill you fixed that), I can't comment on this.

TIA,
Kurosu

[Bidoche]

Features I forgot :

- provides 3 additional color spaces : YV24, a 444 YUV planar colorspace and RGB45 and YV45 which are 15 bits depth versions of RGB24 and YV24 (NB: even though RGB45 is 8 byte aligned, the extra is not alpha, just garbage)


Well more seriously, if you need any help and think it can be provided,
feel free to ask... Well, I could use some feedback about my core classes...

And I need default implementations for the (turn left and right, and flip horizontal) functors in src/core/bufferwindow.

[Bidoche]

@Kurosu

added and committed files into those folders


2) CreateMessageClip isn't a member of StaticImage. But I guess you are working on thatYes I am on that, I won't commit each time I change it.
I will once, when it works.


About empty folders, do you know how to remove them ?
I got some to get rid of, but WinCVS doesn't give me the option to remove them :/

[Mug Funky]

wow. 15 bit channels will be very cool indeed.

i'm pretty sure this has been discussed, but why 15 not 16? seems like an awkward number for a computer (i'm so used to seeing powers of 2).

obviously it wont affect dynamics much, considering the fun we all have with just 8 bits :)

[Bidoche]

@vispgraedde

[b]One of those things was to make it easier to have a GUI frontend where you can see realtime results of filters that can be tweaked in realtime with GUI controls.[b]That kind of things is quite complex as it needs to be done on a per filter basis...
Or at least some kind of introspection, which C++ does not provide.

Another complication is that some params change may modify the actually created clip implementation, so often you can't have params changing methods without an extra level of indirection... :/


Besides why is VirtualDubMod script editor + F5 not good enough ?

[vispgraedde]

Originally posted by Bidoche

Besides why is VirtualDubMod script editor + F5 not good enough ?

Editing script and press F5 simply takes too long for some stuff.
Like if you have a level filter, you don't want to sit and manually try values and press F5 until you find a good setting.
Realtime results from moving a slider would be much easier to work with.

And I don't see why a filter framework would have difficulties to export variables and their range and type to a GUI control. This is only to allow realtime preview and tweaking.

Anyway, I'm just saying what I'd wish to see in 3.0 to make it more useful for me. I use avisynth sparingly today because of the lack of the things I have mentioned, and thought I'd mention these things since it looks like 3.0 is still young enough that it wouldn't be too hard to at least implement provisions for these things.

[Bidoche]

I guess I could have a Clip method return an adapted editor, or throw...
But this can wait till the parser is done.

[Kurosu]

Originally posted by Bidoche
@Kurosu
added and committed files into those folders
Almost there. src\filters\resize\pattern\maker.h makes references to ..\subrange. which I can't find anywhere, even in the Attics of the CVS repository. It is necessary to compile the resize filter, so I can't go any further.

Yes I am on that, I won't commit each time I change it.
I will once, when it works.
No problem. What I meant is that I'll have to comment it to get it to compile.

About empty folders, do you know how to remove them ?
I got some to get rid of, but WinCVS doesn't give me the option to remove them :/ [/B]
I'm not quite familiar with CVS (it works for thousands of developpers but it sometimes is really a braindead system), but I see 2 options:
- I'm almost sure WinCVS has an option to prune empty folders; it might not work, or you may have errors. I've been told to always use cvs update -P to fix that.
- the only other solution is a direct delete in the cvs repository; you'd have to ask sourceforge to do that. I hope they will give you help on what you have to do on your end of CVS. What I know is that once it's done, you'll have to delete the whole parent folder so that the CVS entries get properly rewritten (as the empty folder may still have entries in your CVS sub-folder). Again use cvs update -P to be sure nothing gets wrong.

-P tells not to create empty folders when updating.

[Guest]

Here is the latest build from Bidoche, including the missing DLL:

http://neuron2.net/misc/avisynth1.zip

[Kurosu]

Originally posted by Kurosu
Almost there. src\filters\resize\pattern\maker.h makes references to ..\subrange. which I can't find anywhere, even in the Attics of the CVS repository. It is necessary to compile the resize filter, so I can't go any further.OK, this is now fixed.
The big stuff, now: try to use gcc to build that...

[Bidoche]

You could have removed the resize filter, he is not necessary to compile avs.
Nothing in the filters namespace is so far, since I haven't done the function table.


Edit: good luck with gcc.

[vion11]

Originally posted by Bidoche
- Maybe: exposes itself as COM interfaces and accept COM plugin.
I like this line...:)

Using CreateObject("") with AviSynth,
switching off autoload features (avsi),
using plugins per instance,
having all functions as a collection or dictionary,
asking functions about proper calls,
loading scripts with string or filename,
having events fired when script is ready to send frames,
and can ask for errors.....

Isn't it a must for seamless integration into GUIs?
(Sorry I'm not capable to write in C, but can
provide a reference design for testing COM-interface)

Upcoming GUIs driven with 5Ghz machines
will enable realtime result of filters,
ok - not with HDTV.

I have little progess with testing zip, msvcR71d.dll
is now missing, but don't want to have Bidoches complete
\system32 folder local.
Are these debug files really needed for testing?

Which ressources are needed to speedup building the parser?

[Bidoche]

Using CreateObject("") with AviSynth,
switching off autoload features (avsi),
using plugins per instance,
having all functions as a collection or dictionary,
asking functions about proper calls,
loading scripts with string or filename,
having events fired when script is ready to send frames,
and can ask for errors.....Well, apparently, you seem to know more about COM that I do.

Isn't it a must for seamless integration into GUIs?
(Sorry I'm not capable to write in C, but can
provide a reference design for testing COM-interface)If you could make COM interface proposal for what you would want to have available to a GUI, that would probably make the difference between a long lived maybe and a soon.


I have little progess with testing zip, msvcR71d.dll
is now missing, but don't want to have Bidoches complete
\system32 folder local.
Are these debug files really needed for testing?All those debug dlls are getting annoying :/, I will post a release build next time.

Which ressources are needed to speedup building the parser?Better spirit understanding, I would guess.
The thing is quite complex (and powerful).
Take a look at http://www.boost.org/libs/spirit/index.html to give yourself an idea

[vion11]

COM proposal is in work....

Find out this project matches best to AviSynth: http://www.devel.lyx.org/~leeming/yac/

It uses Spirit to parse input and constructs a virtual machine which outputs the results.

The used grammar lacks things like explicit last and pseudo oop style AviSynth provides.
Both should be adaptable from existing code/grammar.

Assuming there is no need to change current grammar, hmmm, what about macros?,
I detect from scratch 5 dividable subprojects with this workflow:
(read this '-' as this ' ')

script - grammar
---- | - | -----
---- parser ----
------ | -------
----- vm -------
------ | -------
-- execution ---

where 'script' is a growing collection of defined test scripts.
Every release should be capable to run these scripts to avoid
future version dependant issues. This a quite good technic from
extremeprogramming(.org)

'grammar' the language, defining statements, expressions and functions.
I would prefer an ascii file readed by parser at runtime and/or
compilable into code for releases.

Both test scripts and grammar can maintained without knowledge
of c++, which is a plus regarding the current team size :)

When scripts and grammar matches parser says parse = true.

If parser parser accepts at least one script and one grammar,
the next step is to build up the nodes representing filters,
readable by the vm. For error checking it is advantageous
to have an alternative human readable nodelist here (xml?)

The execution part bundles stuff like AviFile handler, COM,
providing frames, error messages, and so on, nothing new here.

All subprojects can be developed and checked independantly.
First things will be writing a grammar, a test suite of scripts,
and thinking about an text format for nodelists.

I know this is a very simple approach to what have to be done.
A lot of topics aren't mentioned and will give headache.
I only want to give ignition to start, AviSynth 3.0
should not die before birth.

[vion11]

Read some further information about spirit and
I'm prepared to write the grammar.

Anybody out there to put hands on the test suite?

[Bidoche]

COM proposal is in work....cool :)

Find out this project matches best to AviSynth: http://www.devel.lyx.org/~leeming/yac/

It uses Spirit to parse input and constructs a virtual machine which outputs the results.This is indeed really close to what we need with avisynth, I will look into it

The used grammar lacks things like explicit last and pseudo oop style AviSynth provides.
Both should be adaptable from existing code/grammar.
I don't think these will really be a problem.
An harder part would be to correctly handle avs function overload resolution, which is quite complex with its optional arguments.
But I think it can be done using spirit closures.

Assuming there is no need to change current grammar, hmmm, what about macros?You want macros in avs ?
Let's make it work without first, after we will see.

'grammar' the language, defining statements, expressions and functions.
I would prefer an ascii file readed by parser at runtime and/or
compilable into code for releases.You don't really expect the parser to be built at runtime from a def file... or do you ?
Even spirit dynamic parsers can't do that.
But a reference definition of the grammar, yes.

the next step is to build up the nodes representing filtersBad idea to directly make nodes for the filters.
It ties our hands if we want to change the parser later.
We do a Function class and a Function to Node adapter.

I only want to give ignition to start, AviSynth 3.0
should not die before birth.It won't :)

[vion11]

An harder part would be to correctly handle avs function overload resolution, which is quite complex with its optional arguments.Overloading yields to different parameter sets and prevents generic function description, which is essential for automatic script generation. I vote completely against overloading and vote for macros and wrapper functions instead.

You don't really expect the parser to be built at runtime from a def file... or do you ? I do or does the parser lacks a parser for EBNF notation?

Bad idea to directly make nodes for the filters.
It ties our hands if we want to change the parser later.
We do a Function class and a Function to Node adapter. Could you explain that, sounds good, want to understand, please.

And what are your next steps? :)

[Bidoche]

Overloading yields to different parameter sets and prevents generic function description, which is essential for automatic script generation. I don't see why it should be a problem, it's just two differents functions (even though generally related) who happen to have the same name.

I vote completely against overloading and vote for macros and wrapper functions instead. Well, then explain me how to retroactively remove overload support from avisynth ?
This has always been supported...

I do or does the parser lacks a parser for EBNF notation?The point is not whether or not I can parse EBNF notation but if I can build an avs parser from it, who will do the right thing !!!
It may be possible (very hard) to parse EBNF notation and make of parser who will recognize the given grammar... but just recognize the grammar, not produce a filter graph.

Besides, spirit syntax is really close to EBNF, so changes should not be that hard to forward into the code.
And I don't expect the need to changes the grammar very frequent, no ?

Could you explain that, sounds good, want to understand, please.There are dozens of filters in avs.
We do not want to make a node for each one, instead we make a FunctionNode who takes a Function as argument.
Where Function is the class who gets one made for each filter, with arguments description et al.

I already made this one (incomplete) with a Plugin class, see files in src/linker/

And what are your next steps?I have started working on the virtual machine implementation, taking inspiration from YAC.
But with some modifications...

[Kurosu]

@Bidoche

I've decided to make the first tests under MinGW. I've managed to make and install the various libs needed. stlport worries me though, as I had to use the unix install (make install wouldn't install), and copied as a complement all the needed libs/dlls/headers to accessible pathes.

I've thrown a makefile to build the project (rewritten from scratch, but following the MSVC project file) but ended up with those errors:


g++ -O -g -I/usr/local/include/boost-1_31 -D_STLP_DEBUG -I/usr/local/include/stlport -DAVISYNTH_EXPORTS \
-c -o src/text/antialiaser/bitrenderer.o src/text/antialiaser/bitrenderer.cpp
src/core/Exception.h:52: error: looser throw specifier for `virtual const char* avs::Exception::what() const'
/include/c++/3.3.3/exception:59: error: overriding `virtual const char* std::exception::what() const throw ()'
src/core/Exception.h:35: error: looser throw specifier for `virtual avs::Exception::~Exception()'
/include/c++/3.3.3/exception:56: error: overriding `virtual std::exception::~exception() throw ()'
src/core/Exception.h:35: error: looser throw specifier for `virtual avs::Exception::~Exception()'
/include/c++/3.3.3/exception:56: error: overriding `virtual std::exception::~exception() throw ()'
src/core/Exception.h:35: error: looser throw specifier for `virtual avs::Exception::~Exception()'
/include/c++/3.3.3/exception:56: error: overriding `virtual std::exception::~exception() throw ()'
src/core/Exception.h:52: error: looser throw specifier for `virtual const char* avs::Exception::what() const'
/include/c++/3.3.3/exception:59: error: overriding `virtual const char* std::exception::what() const throw ()'

I've edited pathes to have a better display

From that link (http://www.agapow.net/programming/looser_throw_specifier.html), I decided to add the missing "throw()" needed on each occasion. gcc then stopped complaining. Now I have this error:

g++ -O -g -I/usr/local/include/boost-1_31 -I/usr/local/include/stlport -D_STLP_DEBUG \
-DAVISYNTH_EXPORTS -c -o src/text/antialiaser.o src/text/antialiaser.cpp
In file included from src/core/ownedblock.h:28,
from src/core/bufferwindow.h:30,
from src/text/antialiaser.h:28,
from src/text/antialiaser.cpp:25:
src/core/block/base.h:52: error: declaration of `typedef struct
avs::block::Recycler avs::block::base<Deleter>::Recycler'
src/core/block/base.h:38: error: changes meaning of `Recycler' from `struct
avs::block::Recycler'
In file included from src/core/bufferwindow.h:30,
from src/text/antialiaser.h:28,
from src/text/antialiaser.cpp:25:
src/core/ownedblock.h: In member function `void avs::OwnedBlock::reset(int,
bool)':
src/core/ownedblock.h:71: error: syntax error before `;' token
make: *** [src/text/antialiaser.o] Error 1
It seems that for whatever reason, gcc simply discards an argument... I don't really understand this. Anyway, this makes me think that we should more and more:
1) split this topic. All my reports may belong to the programmation forum in a way, but there are many subjects treated there (porting, DCOM interface, ...)
2) setup a devel list. I don't think forums are well suited for this.


Not sure if it matters in the actual problem, but I'm very suspicious about the place where the error was raised. It seems gcc still uses its own implementation of the STL :/


Btw, some minor 'esthetical' remarks so far:
1) in the project file, bufferwindows.cpp/.h don't belong to Core, but to Core\BufferWindow
2) not so minor as it spams the stdout of the compiler: many of your headers and some source files where a comment (behind a '}' or a #endif) ends the file make gcc complain about a missing newline. Indeed.

Missing errors, output edited

I temporally fixed this by:
1) Changing object's name "Recycler" to "Recycle"
2) Casting GetEnvironment as (const avs::PEnvironment&)

[vion11]

two differents functions (even though generally related) who happen to have the same nameThis forces GUI developer to present the user two different
functions say Foo1 and Foo2, but the point is, this abstraction
cannot be made with code, pure hand written files are needed to
describe the functions for the generator.
Don't misunderstand me, I do not want to drop the power
of functions of Avisynth. But it is very hard and sometimes impossible
to find out which parameter is optional or not
when nobody knows want is ment: Foo1 or Foo2.
When there is a solution with overloaded functions - no problem.

And I don't expect the need to changes the grammar very frequent, no ?My intention is to split the process into different parts.
Describing and testing grammar is faster whithout compiling it.
I've just seen the developer of spirit have stopped their
dynamic library which was capable of reading grammar on the fly,
so this is not an option anymore with spirit.

We do not want to make a node for each one, instead we make a FunctionNode who takes a Function as argument. Will this enable the optimizing you'll plan
with recursive functions calls or am I totally wrong?

[Bidoche]

this abstraction cannot be made with code,
pure hand written files are needed to describe the functions for the generator.And why can't it be described by code !?
I see no opposition at having two of my Functions objects reporting the same name.

But it is very hard and sometimes impossible
to find out which parameter is optional or notThat info will be made available by the Function class

Will this enable the optimizing you'll plan
with recursive functions calls or am I totally wrong?No connection at all.
It's just that I already have to make a Function object per filter (for description to GUIs and parser), I don't want to make a Node type too.

The terminal recursivity optimisation avoids to setup a new context for each recursive call, thus avoiding stack overflow.

example: function f(int a, int b, int c)
{
//do something with a, b, c, eventually return
return f(a + 1, b - 1, c / 2);
}f ends with a single call to itself, it is terminal recursive.
Instead of setuping up a new context for this new call, we can reuse current one (which is now longer relevant at that point) by simply updating the values of a, b, c.
And restart execution at the //do something with a, b, c point...
That is what terminal recursivity optimisation do.

At this point I have absolutely no clue of if and how it can be done.

[vion11]

AssumeFPS(clip, float fps, bool "sync_audio")
AssumeFPS(clip, int numerator [, int denominator], bool "sync_audio")

As a programmer I understand the meaning of the two lines above.
A GUI is useful for non programmer. For using this function
I have to give user a max of 3 input fields. (clip parameter are filled other way)
User is lazy or experimental or both and GUI passes this line to avisynth:

BlankClip(100,320, 320, fps=20).AssumeFps(10.0,0)

later on GUI passes this line:

BlankClip(100,320, 320, fps=20).AssumeFps(10,0)

How can GUI explain the user difference between ten and ten?

[esby]

mmm I don't think your example is a good one.

here no matter the form used, the information & parameters are the same (in meaning, for the user).

So the GUI has only to care for one form, and maybe two representation, and allow transcoding between both if needed.

The GUI here don't have to explain the difference,
because it's a GUI, and since 10.0 can be translated into 10
without worry here.

And you are not forced to tell to the user that the parameter are identic.

Even if you suppose him dumb, you can adopt some trick like color coding the text field, to report if it is optionnal or not, and allow him to differenciate.

In your example:

AssumeFps(10.0,0)
<==>
framerate:10.0 , audio: NS.

and

AssumeFps(10,0)
<==>
framerate(calc.):10.00 numerator:10 denominator(optional/default):1 audio: NS.

supposing the color choice here represents:
-what can be changed normally by the user (eg blue)
-what can't be changed but is calculated from other settings (eg:red)
-and what is optional, meaning it will take this value if the user does not change it(eg: green)

Of course, since you are in a gui, you can introduce another level of indirection, and do what you want. Like adding comments that will not be interpreted by the avs interpreter, but might be used by other program reading the avi file in text mode... like nesting xml coding after comments #

It's a gui problem, not an avs one.

esby

PS: something disturb me more in your example:
if false is translated as 0 by the interpreter, that go against the logic,
it should be false / true or "false","true" if you are logic.
Or you won't be able to differenciate function(bool) from function(int).
and if you keep going in this way, of course how the interpreter
will make the difference between function(float) and function(int)
if you allow seamless casting before interpretation.
Meaning function(float) could be read as function(int(float))... or vice versa...

[Bidoche]

AssumeFPS(clip, float fps, bool "sync_audio")
AssumeFPS(clip, int numerator [, int denominator], bool "sync_audio")Here clip.AssumeFps(10, false) is a call ... to the 1st version, with imlicit int to float conversion.

In fact, it's not possible to have an ambiguous call with these two...


Edit: you are mixing two optional syntax, maybe you missed the fact that sync_audio is optional too there.
And that once you start skipping optional params, if you want to provide more, you must specify them by name.

[vion11]

Sorry, nobody has answered my question.
And there is a slight impression,
examples haven't been tried out.

There is no need to explain what syntax and optional parameters are.
We are all programmer, I'm sure.

But to stay constructive I'll provide an overview:

I want to build a version independant GUI. So I can tell users:
"Gui works with every version of AviSynthing starting with 3.0"
On the other hand AviSynth is work in progress, what is good.
So what can be done?

I see 3 solutions so far:

First: Hardcode it!
To code 200+ functions is a lot of work,
and on top every GUI version belongs only to one
version of AviSynth.
Not a prefered one....

Second: Drop ambigous!
Here all function headers are written in a text file
like the 2 lines of AssumeFps() above, dubious are dropped.
Parameter layout is determined on the fly while starting.
If header change or new function/filter arises only update
of text files is needed. And may maintained by users if capable.
That's current solution of AVEditor with Avisynth 2.5.

Third: Be dynamic!
Thats best! Bidoche has already worked in this direction with
Function Objects and proposing COM-Interfaces.
Nothing is hardcoded or saved in outdated files.
It is like talking...

GUI: Hello, User wants to have colorbars. What parameters
are needed?

AVS: Hi, first of all - colorbars exists as function.
There are two parameters, first is called width and second height.
Both are not optional, cannot be named, expect integer only, have
no defaults and good value are between zero and 12000 with including.

GUI: Thanks a lot!

Thats nice and exact communication.
Now same with AssumeFps()...

GUI: User wants to slow down movie. Does AssumeFps exists?

AVS: Yes exists.

GUI: OK - gimme parameter layout.

AVS: I have two representation of AssumeFps, which one do you want?

GUI: Hmm, don't know. Which is best?

AVS: It depends on what you want to do. Ask user please.

GUI: What should I ask?

AVS: Ask for NTSC or PAL.

GUI: User never heard about PAL or NTSC. But wants to make DVD.

AVS: Ok I see, I have no heuristic method for determing that.
I'll give you most flexible representation and we'll see.

GUI: Ok lets try.

AVS: four parameter, optional, default.........

GUI: thanks.

...

GUI: User seems to have problems, enters 29.97 in input box, Thats
not allowed. Gimme other representation, please.

AVS: Which one do you have?

GUI: Hmmm, don't know, is called AssumeFps.

AVS: I have two representation of AssumeFps, which one do you want?

...

Comunication stopped by user and has never been started again, programm was deleted.



What this dialog shows, there IS an ambiguous case when
you have to predict what representation is wanted.
It may be a solution when internal the representation are numbered or indexed
and we have AssumeFps(1,,,) and AssumeFps(2,,). But thats just the same
as having AssumeFps1(,,,) and AssumeFps2(,,).
Which are different functions with different names.

So how will Avisynth 3.0 support GUIs?

[Bidoche]

What this dialog shows, there IS an ambiguous case when
you have to predict what representation is wanted.
Why predict ?
You could take both and offer the choice, eventually using a contextual help message provided by the Function objects themselves...


or :

GUI: User seems to have problems, enters 29.97 in input box, Thats
not allowed. Gimme AssumeFPS(clip, float, ...

AVS: AssumeFPS(clip, float, ... resolved as AssumeFPS(clip, float, "sync_audio") and returned


or again :

GUI: User wants to slow down movie. Does AssumeFps exists?

AVS: I have two representation of AssumeFps, which one do you want?:

GUI: OK - gimme AssumeFPS#1

...

GUI: User seems to have problems, enters 29.97 in input box, Thats
not allowed. Gimme AssumeFPS#2

[esby]

What this dialog shows, there IS an ambiguous case when
you have to predict what representation is wanted.


I see no ambiguity...
you have to choose one, if the user wants the other one, you'll change it.
as long the parser is able to determinate that there is no ambiguity beginning with, you'll be able to have the gui react the same.

And to sum (from my point of view) what seems to be a problem for you, even if we have overloaded definitions of function, supposed the parameter, the function+(list of parameters) does constitute an unique identifier here supposing that the parser is able to clear all ambiguities first.

And if you are wondering 'how are we going to have this list of parameters', that could be the job of some functions, redefined in each plugin, more precisely something like that:
int GetNumberOfSyntax();
Syntax GetSyntax(int pos);

And you would have a structure parsing the list of loaded plugin,
handling the whole list of plugin, and able to export it to a gui application...
--Maybe as TextStream in the avi? (just a weird idea)--
[edit: definitely not, I forgot we are in a GUI, and that we need to create the avs script first :D ]

esby

[vion11]

@Bidoche

You're right. If there is a representation number along
to functions, there is no ambiguity. Important is both GUI and
AVS know about that.

To sum up:

When GUI starts up it asks AVS for all available functions
and their amount of representations. GUI presents different
representations as different filter/functions to the user.

When GUI asks AVS for parameter layout it has to tell
function name AND representation number.


And To complete it - a object hierarchie with properties:

Where '()' means there is more than one possible
and items are organized as list, collection, array, dictionary or
what ever and there is a 'core plugin' with all internal filter.
Also assuming all parameters can be named!
There is also ambiguoutiy with same function name from different
plugins, discussed here:
forum.doom9.org/showthread.php?s=&threadid=72235 (http://forum.doom9.org/showthread.php?s=&threadid=72235)


Plugins()
-PluginName
-PluginFileName
-Functions()
--FunctionName
--InputColorSpaces()
--OutputColorSpace
--AmountOfRepresentations
--Representations()
---IndexOf
---Parameters()
----ParameterName
----DataType
----DefaultValue
----IsOptional
----MinValue
----MaxValue
----ParamList()

When this hierarchie is concluded
I can go on with COM Interface-Proposal.

[Bidoche]

there is a 'core plugin' with all internal filter.Yes, that's effectively the case.
I wonder if I should make an user plugin for script defined functions too...

Also assuming all parameters can be named!Thought of that too, it's to be a requirement.

There is also ambiguoutiy with same function name from different
plugins, discussed here:
forum.doom9.org/showthread.php?s=&threadid=72235Some syntax will have to be set up for forcing plugin host function.
Even more necessary since I intend to allow function overrides...


About your hierarchy :

master class:
ScriptEnvironment (NB: that's not the same as in 2.X)

LoadPlugin
AddPlugin (passed from another ScriptEnvironment)
NB: does not allow two plugins with the same name

methods to list the plugins known

same thing for functions

look up function by name
either it returns a function pool like you seem to prefer,
or a function count and you have to use another method to get them...


Plugin :

Name, FileName, list functions...


Function :

Name, Host Plugin

Prototype (a string like: clip Trim(clip child, int begin, int end = 0)

About your parameters objects, I wonder if there are really necessary...
I am thinking about a method returning an XML description of the function instead.

[Guest]

Here's the latest build from Bidoche:

http://neuron2.net/misc/avisynth2.zip

[Bidoche]

Finally I found why extra dll msvc are required :

It's because since I link vs a dynamic boost.Thread I have to link vs a dll c runtime too :/

So we will have to drag them around until issues on boost.Thread are solved and it is available as a static lib again.


By the way, I have upped a new build (with all dlls required) to yahoogroups :

This one introduce variables support, with the 4 operations + - * / (and ( ) )
It outputs the state of the stack after code parsed is executed
(ie the values of variables in declaration order) as a message clip.

[Bidoche]

Got functions calls working (clip . function too)
That is to say that as far as there are functions to test with, it works :p

Will start making more functions.

[Bidoche]

Added variable scoping and an if statement using it.

I need some syntax to declare you DO want a new variable and not reuse the one from the outer scope.
I would like some suggestions.

I thought about this :clip = ....
clip2 = ...
if ( true )
{
clip = ... //reuse clip above
new clip2 = ... //not the same variable
}

[vion11]

What advantages are provided with an additional
scope inside IF statements?
Would assume vars are have same guilty
inside and outside of conditional branching.
Using '()' instead of '{}' will make it clearer.

[esby]

clip = ....
clip2 = ...
if ( true )
{
clip = ... //reuse clip above
new clip2 = ... //not the same variable
}


that sounds like a local variable overiding the 'more global' variable inside of an if statement.
so far... keywords 'local', 'override' 'local_override' ?
Althought I don't really the interrest of the procedure,
because we could just define a new variable name not used...
Is there another interrest I'm not seeing?

but Some questions...


clip = ...

if (true)
{
local clip2 = clip # (1)
local clip = clip # (2)
}
return clip2 #(1)
return clip #(2)


in (1), if I'm not wrong, this should not be allowed, since clip2 is only defined inside of the if.

in (2), could/would it be possible to initialize the local clip with the clip, content, and to have clip unchanged after the if, no matter what we did inside of it.

esby

PS: my preference would go for 'local' keyword, override & new having programming different usage in programming language... (override being used in oop & new suggesting pointer / memory allocation...)
The keyword 'var' could be used too... with the same problem as 'new' & 'override'...

[Bidoche]

What advantages are provided with an additional
scope inside IF statements?It avoids leaving useless variables on the stack, var created in the if context are cleaned when exiting.

Besides, if var were left on the stack, compiling would be simply impossible.if ( expression )
{
clip = ... //create a new var on the stack
}The 2 paths doesn't leave the stack in the same state, how can it continue after that. :'(


Using '()' instead of '{}' will make it clearer.Every language that I know about has chosen { } too.
And ( ) already have many uses, it would compexifiy parsing a lot.


that sounds like a local variable overiding the 'more global' variable inside of an if statement.
so far... keywords 'local', 'override' 'local_override' ?
Althought I don't really the interrest of the procedure,
because we could just define a new variable name not used...
Is there another interest I'm not seeing?Yes, we could do that, but keep creating new names is boresome and you could be trapped by a var defined in an Import...

The feature is here for completeness, I don't think it would be widely used.
But as long as you have scopes, I would expect to have local vars too.


in (1), if I'm not wrong, this should not be allowed, since clip2 is only defined inside of the if.Here parser complains that he doesn't know about clip2 (That is when error handling is implemented)

in (2), could/would it be possible to initialize the local clip with the clip, content, and to have clip unchanged after the if, no matter what we did inside of it.That's exactly how it happens

my preference would go for 'local' keyword, override & new having programming different usage in programming language... Was not too happy with new myself, for the same reason.
So 'local' it is :)

[vion11]

It avoids leaving useless variables on the stack, var created in the if context are cleaned when exiting. Vars are cleaned when leaving function scope or script. No problems with compilation.

Every language that I know about has chosen { } too.
And ( ) already have many uses, it would compexifiy parsing a lot.
LISP the "mother" of avisynth scripting language doesn't follow that rule.
'IF' is a function with two parameters: a condition and a expression list.
Why should second parameter have different type of parantheses?
Is it the parser or the user who has to deal with complexity of language?

What about:
c=foo()
if (c=true)(a="OK")
if (c=false)(a="Not OK")
print a

[Bidoche]

Vars are cleaned when leaving function scope or script. No problems with compilation.3.0 has stack based vars and not mapped through their names like 2.X.
So if you don't clean at scope exit, the exit state of the stack may be different according to the execution path it will take at runtime.

Which is totally fatal to the parser, it needs to know perfectly the stack's state to be able to able to map vars to their position in the stack.


LISP the "mother" of avisynth scripting language doesn't follow that rule.Really ? I didn't knew that...

'IF' is a function with two parameters: a condition and a expression list.
Why should second parameter have different type of parantheses?Because I don't remember promising to Lisp syntax.
I don't even know lisp syntax.

Is it the parser or the user who has to deal with complexity of language?It is the parser, but as the one writing the parser, I will choose to do as I please.

Besides, do you really think the basic user will be surpised about the { } ?
I think many would write it that way when learning avs has now if statement...

After that, maybe I could later support the ( ) syntax too.
But it can wait.


if (c=true)(a="OK")Affects true to c and "OK" to a.
And don't tell I can contextually deduce that c=true is a test, it's really really hard to do so.
And maybe you DO wanted to affect the value of the test to c...

[vion11]

c=foo()
if (c=true)(a="OK")
if (c=false)(a="Not OK")
print a Wouldn't execution fail at 'print a'?

Knowing of LISP is the reason why I "fall in love"
with avisynth. There is no difference between data and code.
You could write a LISP interpreter with a few lines in LISP.

I would say it is most simple and powerful language at all.
Meaning simplicity is power!

There is a strange trend to make languages more idiomatic.
Do you understand PERL? Perhaps it is a question of taste, but I want
to know if Avisynth 3 would execute my existing scripts.

If not - what advantages could I expect over 2.5 in terms of language
not video performance?

I predict you'll run into a inconsistency with this 'IF' scope
when implementing 'eval' or 'apply', but can't prove it from scratch.

Will Avisynth 3.0 support the lambda calculus with these functions?

It seems to me you are going the hard way. There is only a need
for a few functions and macro capability. The rest can be solved
with writing macros. Keeps consistency and doesn't inflate or overcomplex parser code.

This already happens in avisynth. As far as i know 'weave' envokes
other filter only. So it is kind of macro, easy isn't it?

Or more practical: Assuming 'LOOP' is on your list. What is easier to do?
- Writing it into the parser
- Using 'IF' and 'APPLY' and write a macro.

But it is your choice to split work at more shoulders.....

[Bidoche]

Wouldn't execution fail at 'print a'?Supposing your parenthesis are supported, yes.

There is a strange trend to make languages more idiomatic.
Do you understand PERL? Perhaps it is a question of taste, but I want
to know if Avisynth 3 would execute my existing scripts.I don't know PERL either :p
I expect there will be some inconsistencies with existing script, as it is more strongly typed than 2.X was.

That is to say that the following code will fail : val = true
val = 1But generally you don't go around changing the types of your variables, you just use a new one, so it should not break to much code.

I am more afraid of difficulties with Eval/Apply.
As you say, it will probably impossible to reproduce them exactly the same, but will need some change to reproduce the functionalities.

Will Avisynth 3.0 support the lambda calculus with these functions?I would not have expected hearing about that one here.

It seems to me you are going the hard way. There is only a need
for a few functions and macro capability. The rest can be solved
with writing macros..Maybe...

Keeps consistency and doesn't inflate or overcomplex parser codeThe parser is not that complex yet :p

This already happens in avisynth. As far as i know 'weave' envokes
other filter only. So it is kind of macro, easy isn't it?I am inclined to think that every function that could be made as an auto include script should be as such (unless performance issues).

That must be the case of Weave, but DuplicateFrame, DeleteFrame... too

Or more practical: Assuming 'LOOP' is on your list. What is easier to do?
- Writing it into the parser
- Using 'IF' and 'APPLY' and write a macro.clip function Loop(clip child, int n)
{
if ( n < 1 )
error( "n must be striclty positive" )
clip result = child
while ( n-- > 1 )
result += child
return result
}


NB: please submit (non trivial) current code so I can look if I can make it work

[vion11]

Wouldn't execution fail at 'print a'?Supposing your parenthesis are supported, yes. Yes, but what is wrong? Isn't it legal code?
That is to say that the following code will fail
val = true
val = 1 No problem as long as any datatype can be converted to any other datatype.
I would not have expected hearing about that one here. Feeling like Alice in wonderland ...? :)
The parser is not that complex yet When you start fearing complexity - when to many '()' arise? :p

Your loop function is not so bad, will it work like this:

function StackMore(clip c, int toStack)
(Do
Stack = StackVertical( Stack, c)
toStack = toStack - 1
Loop until tostack < 1
return Stack)

BTW: Does Stack have to be declared outside function to get returned
without parser error? Do you really miss the strange paranthesis?

New versions I usually test with good old TicTacToe.avs (http://www.avisynth.org/vion11/stuff/ttt.avs)
If 3.0 displays frames within one minute and
uses less then 200MB memory to play, chouette!

There is another one to post, I'll free it from sources soon.

[Bidoche]

Yes, but what is wrong? Isn't it legal code?Weren't you the one pointing out that there is no print ?

No problem as long as any datatype can be converted to any other datatype.Not all conversions are possible.
How do you convert int to clip ?

When you start fearing complexity - when to many '()' arise? It's not that I can't do it, I was just defending my { }...

function StackMore(clip c, int toStack)
(Do
Stack = StackVertical( Stack, c)
toStack = toStack - 1
Loop until tostack < 1
return Stack)You mean :clip function StackMore(clip child, int n)
{
stack = child
while ( --n > 1 )
stack = StackVertical(stack, child)
}A reverse syntax is possible too. (ie do while like you)
But your code sample use Stack before it is even defined, so can't work as is.

BTW: Does Stack have to be declared outside function to get returned without parser error?Of course not.

Do you really miss the strange paranthesis?you mean the { } ?
I do like them better than plain parenthesis, the code is easier to distinguish.

New versions I usually test with good old TicTacToe.avs
If 3.0 displays frames within one minute and
uses less then 200MB memory to play, chouette!You are the author of that thing ?

[vion11]

c=foo()
if (c=true)(a="OK")
if (c=false)(a="Not OK")
SubTitle anyclip, aNow it is right, but what is wrong?
Not all conversions are possible.
How do you convert int to clip ?Was meaning datatypes, which evaluate to themself, obviously.
But your code sample use Stack before it is even defined, so can't work as is. Oh - vars have to be declared, thats new and reason why code above will not run, right?
I do like them better than plain parenthesis, the code is easier to distinguish.It depends, when you come from c - may be, if you have experience
in basic or lisp you'll get typist's neuritis, and if you start
learning programming you'll search the right keys for hours.

In fact you'll prefer them as well if you write more complex scripts
and don't have to fiddle out whats good at the end of a large
expression ')))}))}' or '))})))}'
You are the author of that thing ?Remember this (http://forum.doom9.org/showthread.php?s=&threadid=59197&highlight=tictactoe) and you'll see I'm waiting for answers since months.:p

[Bidoche]

Now it is right, but what is wrong?It will expect parenthesis around the args of Subtitle.

Oh - vars have to be declared, thats new and reason why code above will not run, right?Nothing to do with that.
Your Stack var is circularly dependent upon itself.

It depends, when you come from c - may be, if you have experience
in basic or lisp you'll get typist's neuritis, and if you start
learning programming you'll search the right keys for hours.

In fact you'll prefer them as well if you write more complex scripts
and don't have to fiddle out whats good at the end of a large
expression ')))}))}' or '))})))}'I would never close so much context at once.
Spaces and NewLines are cheap ;p

Remember this and you'll see I'm waiting for answers since months.I remember about this post, but I forgot you were its author.

Anyway the script should work in 3.0 too (when features get implemented) with some modifications though :

I need Functions to declare their return type, eventually I may be able to deduce it from the code (and make declaration optional), but that won't be an immediate objective.
And there is the case of recursive calls. :/


As for performance issues, I think it should be faster than 2.X.
As using a stack avoids to copy the args into an AVSValue array when passing to function, and we are talking for this script of hundreds of calls.

And for memory, I doubt it can do worse.

[vion11]

It will expect parenthesis around the args of Subtitle.
You're right and I think you got the point though.
Nothing to do with that.
Your Stack var is circularly dependent upon itself. Got it too, and I like your while statement in the example. It is short and easy to read for humans.
I would never close so much context at once.
Spaces and NewLines are cheap ;pYes, but monitors are expensive so I use indention instead of newline to announce contexts.
Anyway the script should work in 3.0 too (when features get implemented) with some modifications though :

I need Functions to declare their return type, eventually I may be able to deduce it from the code (and make declaration optional), but that won't be an immediate objective.
Good news! No problem with return types for functions and
it would be a pleasure when the current ? : syntax is replaced with
'IF...' - with plain parantheses of course :)
And there is the case of recursive calls. :/ What should I think about this remark..?

[Bidoche]

And there is the case of recursive calls. :/What should I think about this remark..?The parser statically type analyse everything, so it can bind the proper calls while parsing.
If it defered this analysis at run time, it would fail to detect some illegal constructs (maybe affordable), but it would be damn slower. :/ (not funny at all)

In the case of your script, one would not want to do 500 times the very same overload resolution, including argument reordering and/or defaults generation....


To be able to do that, the parser need to know the return type of every function.

But if I try to deduce return type of a function from its code, and it's recursive.
The recursive call is necessarily before any return statement and at that point I won't know its type... :p

So recursive functions would need return type declaration.

[vion11]

So recursive functions would need return type declaration If that means a factor 10 speed improvement,
I can't await first version with functions enabled. :)

[Bidoche]

If that means a factor 10 speed improvement, I wouldn't arrogantly claim such an improvement (but in the other hand, it wouldn't surprise me either :p )



I got basic function support now (ie no default args, no recursivity yet)

I almost have added operator[] too (extract a substring on string, does Trim on clip)