Avisynth+

[wOxxOm]

Originally Posted by ultim

What kind of for-construct would you like to see?

The simpler the better. I like Gavino's with even less 'noise': for var = init, limit, step { .... } #step could be negative.

Originally Posted by mirkosp

It's not like they are needed, since they can already be done through recursion

Recursion is not human readable. Making dlls isn't worth the effort in simple cases. Using vapoursynth isn't always an option. And there's nothing wrong to have a small set of simple human readable block statements in avisynth-plus. Also, this topic was discussed like a thousand times.

[Sapo84]

Originally Posted by mirkosp

It's not like they are needed, since they can already be done through recursion if one needs to.

Which is harder to write, read and probably less efficient (not that it matters).

Anyway, I'd go with the C style for (and no while, for already covers it).
I find the readability of Gavino's one a bit of a problem (if you don't use named parameters), and while his solution is a lot more in line with Avisynth synthax I still prefer having full statements.

[jmartinr]

+1 for C-style

[Gavino]

Originally Posted by ultim

I can see upsides and downsides too to Gavino's version. It might be easier to grasp for non-programmers, and also it gives Avisynth some possibilities to recognize infinite-loops, and helps prevent the user from shooting himself in the foot. C-style for-loops could then be emulated using manually written while-loops. On the other hand, it is less generic, non-standard, and despite all the simplifications and built-in automatic, it still cannot prevent all user errors, like when the loop variable is modified inside the body. Programmers could also argue that it is counter-intuitive, because 'limit' and 'step' are only evaluated once even if their value is dynamic.

My goal with for was to provide a simple looping construct without the need to use recursion, making life easier for script writers, especially for non-programmers. The syntax is simple so that errors can be quickly recognised and reported clearly.

I made limit and step fixed as I felt they are the parameters that define the loop.
Anything more complex can be programmed as a while loop.

[TurboPascal7]

I'm not sure for loop is required either, maybe because I haven't seen a single useful example of it used in gscript, that couldn't be rewritten with recursion with maybe a bit more effort. If anyone could provide such an example (preferably used in a real working commonly-used script), I would be grateful.

That said, if you feel like adding features to the language just to simplify a little more than zero scripts - sure, go ahead. It's not like it will make the language worse. I don't have any particular opinion on which version is better, they are both fine.

Originally Posted by Sapo84

and probably less efficient (not that it matters).

Efficiency should be pretty much identical because after building the filter graph it's all the same.

[Gavino]

Originally Posted by TurboPascal7

I'm not sure for loop is required either, maybe because I haven't seen a single useful example of it used in gscript, that couldn't be rewritten with recursion with maybe a bit more effort.

Clearly it's not required, as any for loop can be rewritten using recursion.
Its purpose is to avoid that 'bit more effort' for the majority of script writers.

[TurboPascal7]

Gavino, I understand and I would fully agree with you in an ideal situation. I just think it would be better to check if the actual demand is high enough (with examples) rather than simply adding features that "would be cool to have". It's never late to add the feature but it will be really hard to remove it. Just look at C++ right now.

[ultim]

I myself find the new block-if the most useful, but the looping constructs are useful too. Please don't turn this discussion into whether to have looping constructs at all or not. The fact that previously loops have been emulated using recursion proves that loops are needed and sought after in Avisynth. Especially in a language that is designed to be simple to write and simple to interpret by humans, "for" or "while" can mean a lot, because they are way easier to program and read than even the simplest form of recursion.

So there will be ifs, fors and whiles (and admittedly I'll also see if I can hack a "break" statement into the language). If you are more comfortable with recursion, you can still keep using it. Now please, let's get back to the question at hand and let's vote which "for" variant you'd prefer.

Edit: I understand that none of these new constructs are technically needed, as the same effect can be achieved using other methods. However, those methods make scripts harder to write and to read. These new constructs are improvements, and improving the existing functionality of Avisynth is the goal of Avisynth+ after all.

[qyot27]

Originally Posted by TurboPascal7

But this requires filters/plugins to have this unoptimized plain C version, which might not always be the case (take a look a sangnom2 for example, which doesn't have a plain C version. Original sangnom didn't either). I dunno about you, but I don't really see any point in adding that only to support some 15-years old CPUs (readability problem aside). This is probably not the problem for internal filters though, since most (all?) of them do have the C path.

I don't see how it requires plugins to have it. It just means the user is SOL if a plugin doesn't have a fallback, same as they are now if they try to run a plugin with incompatible SIMD on their machine. But I don't see how the core running unoptimized has an effect on what the plugins support.

I'm looking at it more from the perspective of growth toward other machine architectures - having an unoptimized version maximizes portability. Sure, there could be wholesale additions for NEON or AltiVec or SHmedia or whatever else, but that'd still have to be a case-by-case basis.

[kypec]

ultim, you should probably create separate thread with poll about "preferred loop constructs" then as to move it outside this topic. BTW, I'd prefer C-style syntax myself...

[ARDA]

Originally Posted by ultim

What kind of for-construct would you like to see?
Gavino's "for" looks like

Originally Posted by ultim

So there will be ifs, fors and whiles (and admittedly I'll also see if I can hack a "break" statement into
the language). If you are more comfortable with recursion, you can still keep using it.

Related with Gavino-style for-loops or C-style for-loops I have no preferences, but obviously the
easier for script writers the better, to make more human readable avisynth language is something to add
to a TODO list, avisynth is far to be intuitive or friendly for normal user. Gavino's work is in that
direction, nor more nor less.(My opinion, never interchanged views with him)
I see you have already decided to conform everybody including both and something else, luckly you
have the energy and skills for everything. Thanks again.

Originally Posted by ultim

Porting to x64 could even be made step-by-step. Most ASM resides in builtin filters, so as long as the core
without filters can be compiled in x64, we can be adding more and more builtin filters back to an already
working x64 version as the porting continues.

Originally Posted by ultim

Separating *all* the filters out of core is not my plan either, actually.
but I too don't think that the core sould be totally bare and empty of filters.

Originally Posted by ARDA

I always dreamt with a core very light, the lightest possible, and different
projects of filters grouped by their functions.......

I do not see the word empty or *all*, maybe is my poor english, but I remarked the lightest possible,
that I don't define with precision, so I left opened to a research, study or discussion.

Originally Posted by ARDA

To compile assembly code with an external assembler is not so hard, at least according to my experience
Nasm/Yasm syntax is very near inline asm, except some pointers syntax, not too much.
They are also portable between enviroments and platforms if I am not wrong. Well, I work almost always
with Microsoft Visual Studio C++ 2008 and Yasm or Nasm.

Originally Posted by ultim

True, intrinsics do not always generate optimal code, but it will be close, and it will still be much better than
traditional C code. And let's be honest, hand-written ASM is not guaranteed to be optimal either. Not to mention,
code generation from intrinsics improves with better compilers.

I do not say asm is better than intrinsics, just remark it is not so hard to move inline asm to Nasm/Yasm.
And is also portable, probably to more platforms.
Obviously you have to work under and enviroment that can use Nasm.
Asm code can be non optimal of course. I was thinking about the task of moving out inline code you already have
in built in filters nowadays, optimal or not, while preserving many mmx and Isse code.
There are some Isse codes that are well optimized in avisynth and it is very difficult to get a SSE2 or higer version
to work better, mainly when you have to work with misaligned ptrs.

Originally Posted by ARDA

I also think there is a lot work previous port to x64, and I agree is not for near future.
And in that future probably mmx or Isse will not be needed anymore, while 32 bits it doesn't hurt
to mantain mmx and mainly Isse cause the profit of non temporal store instructions.

@ultim
All these are just some quick ideas, I see you are working hard with other issues, more immediate needs
and improvements so we can leave all this discussion for future.


Thanks for all the work you are doing, and keep on.

[ultim]

Hu, I can rename the thread Btw, Wilbert, I never thanked you for moving us out of the Avisynth a4 thread. So sorry for the trouble and thank you.

[TheFluff]

Originally Posted by ultim

Separating *all* the filters out of core is not my plan either, actually. I already made external plugins out of many functions that IMHO do not belong into the core, like DirectShowSource, audio timestrething, support for vdub filters etc, and maybe I'll do the same with a few more, but I think too that the core library should be usable on its own too.

There are a bunch of "core" filters that should be removed and some that should be restructured, because the current selection is a horrible mess of old cruft and arbitrary ad-hoc "design". I'll quote myself:

Originally Posted by TheFluff

SelectEven/SelectOdd are special cases of SelectEvery and are not going to be implemented (you can of course "implement" them trivially in Python if you want). Similarly, ApplyRange is a special case of Trim (plus splicing) and can be trivially implemented in Python as well. Vapoursynth will not have an 1:1 copy of all Avisynth functions, especially not since the scripting language is now a real programming language so implementing interesting script functions is mostly trivial.

Avisynth has a ton of old crufty functions that are in the "core" for very unclear reasons, anyway. Why are there five different level manipulation functions (coloryuv, levels, limiter, rgbadjust, tweak) with a ton of overlapping functionality? Why are things like PeculiarBlend, FixBrokenChromaUpsampling and FixLuminance core functions? Why does CropBottom exist? Why does the basic "fade" function (equivalent to dissolve+blankclip) need nine different function names and prototypes? God (or maybe BenRG) alone knows.

I mean, check the documentation for FixLuminance. Why the hell has this been in the core for over a decade?

Other redundant functions that should be removed:
ShowFiveVersions - exactly equivalent to StackHorizontal with five arguments. Why?
MonoToStereo - has been explicitly deprecated since 2.5 and replaced by MergeChannels
Pulldown - it's SelectEvery with the cycle forced to 5, use that instead
SwapFields - the documentation explicitly says it's just an alias for SeparateFields().ComplementParity().Weave()

[Myrsloik]

I have one comment to make about the inline assembler/softwire/mess that is in avisynth. Most of it is of a horribly low quality.

Replacing it with proper C++ code probably wouldn't slow it down that much. You also need a proper C++ code path just to test that the assembler you wrote is correct anyway. But that's something no other posters seem to take into consideration.

Anyway, interesting to see some kind of development going on.

[jpsdr]

Being a big user of pulldown, i personnaly prefer to keep it. Some are like macro in C. When something can be used very often, it's nice to have a more compact syntax. I prefer writing PullDown(0,2) than SelectEvery(5,0,2).AssumeFrameBased.
Even if i don't use it, showfiveversion has the same purpose. They are like macro in C, made to simplify syntax of something which may be used very often.
Seriously, i prefer SwapField, name is explicit, syntax is simple, than SeparateFields().ComplementParity().Weave() !
Think of someone who simply want to swap fields... Good luck guessing SeparateFields().ComplementParity().Weave() when you don't have the "swapfield" function !!
Same for pulldown.
Personnaly, i think these shouldn't be removed.

[TurboPascal7]

jpsdr
All that can be solved by shipping a single avsi script with the core, containing all the removed functions.

[ultim]

Originally Posted by TurboPascal7

All that can be solved by shipping a single avsi script with the core, containing all the removed functions.

I'm not sure putting them into .avsi scripts is how much better then being included in the core native filters. Even if in the core, we can cleanly separate them out into their own filters/shortcuts.cpp file (or whatever the name) to not pollute the main filters. But putting them into a separate script incurs a needless startup cost (the'd be autoloaded anyway, but now they'd need to be separately loaded, parsed and evaluated).

[TurboPascal7]

ultim
I'm not saying they should be definitely separated, just stating that the issue can be solved without any real affect on the user.
I think both solutions are fine: the cost of loading a single avsi is not that high, but having them in a separate cpp file would not be bad either, especially since most of them can be implemented in one-two lines.

[TurboPascal7]

While we're at the question of removing stuff: is there any reason TemporalSoften's mode 1 still exists?
Documentation says mode 2 "has a new and better way of blending frame and provides better quality. It is also much faster." and it looks to me almost everyone is using it anyway, so why keeping it at all?

[ultim]

Avisynth Plugin Writing Tips #1: Exceptions

Exceptions thrown from a module should only be caught in the same module. Otherwise you can experience weird and hard-to-debug errors in the plugin. Not adhering to this advice will result in code that can sporadically fail, or work on your computer consistently but fail on other machines.

Unfortunately, avisynth.h contains the AvisynthError class, giving plugin authors the false impression that it is safe to throw and catch these exception objects. It is not. The problem is not in the definition of this class, but in the implicit encouragement to throw C++ exceptions across DLL boundaries. Here are some tips to avoid getting caught in the deepest pits of hell:
- When throwing exceptions on your own, it is best not to use AvisynthError. Not using it will stop you thinking that AvisynthError has some special meaning, or that it can be used to throw to (or to catch from) avisynth.dll.
- Exceptions thrown by you should always be caught inside your plugin. You should not let exceptions propagate outside of your DLL (unless thrown using ThrowError), to Avisynth.
- Errors thrown by Avisynth should not be caught by you. In specific, don't wrap calls to Avisynth in try-catch blocks, because you cannot rely on it working correctly in every situation. If you need to detect errors, validate user parameters in your plugin, or use other API facilities provided by Avisynth, like IScriptEnvironment->FunctionExists().
- If you want to throw an exception to the user and/or to Avisynth, then only use IScriptEnvironment->ThrowError(). You should not call C++'s "throw" yourself for this purpose (see 2. point), and you should not catch the error thrown by ThrowError() yourself (see 3. point).
- If you want to catch an exception, want to do something based on that and finally raise an exception to Avisynth, don't rethrow. Catch your own exception (unless thrown by ThrowError), then call ThrowError separately.

Ignoring the above tips can still result in a fully working binary, but that is only guaranteed under very specific circumstances, more specifically when you've compiled your plugin with the *exact* same compiler version as the avisynth.dll was compiled with, AND when linking to the CRT runtime dynamically. Given that plugin authors can use whatever compiler they want, and that an avisynth binary can be supplied by any community member, it is unwise to rely on such detail.

These tips apply to all Avisynth versions (e.g. to 2.5 and to 2.6, to "classic" Avisynth and to Avisynth+, etc).