New AviSynth tool - AvsP v1.4.0 (6/5/07) [Archive] - Page 6

qwerpoi

4th October 2006, 03:37

What I like to do for me in n++ is to separate the functions in coloring categories ; I use all 4 categories available in n++ like that : 1. Internal Avs functions, 2. Definition / Properties, 3. User dll functions, 4. User Avs functions. Examples of what I am talking about : 1 2. Would be great if I could have several categories of functions like on my n++ for separate syntax coloring properties
Ouch, unfortunately we're getting back to the issue that I didn't write a custom AviSynth parser, so it may not be possible until I do. I wonder how notepad++ and other scintilla-based editors pull that stuff off, they must have implemented some sort of generic lexer - it's something I'll look into.

I rarely have a use for resizing other than 100%/200%, though the flexibility is nice for HD or when 150% is "just right". But I'm not that concerned about it. Which python image library do you use?
I'm not using any extra image library, just the functions that come with wxpython, which ultimately wraps the win32 gdi stuff. That means any image scaling is equivalent to a point resize (I think). Anyway, it doesn't seem like a good idea to use a higher quality image library like PIL, since AvsP would have to resize every frame individually, could get slow/intensive. The better scheme is what you and krieger2005 suggested with an AviSynth video resize, if I wanted to do it. Along the same lines you were mentioning, I'm thinking it might be better to allow both the video preview window and the video slider window to be separate dockable windows, but that may be even more work.

I don't need it. It was just an idea. For my taste the editor do now more then enough. Some enchancement of the existing function would be nice, but your to-do list is long enough. Thank you.
Well, when I use AvsP myself, I tend to have enough room for everything. But in this day and age, I guess it's entirely possible to be editing video with roughly the same resolution as your desktop resolution, so I'll be the first to admit that the current way AvsP is organized is not optimal in that regard. So I'll be giving it some serious thought, just don't expect results right away. :)

@qwerpoi
French translation (homepages.nildram.co.uk/~cestial/AvsP/AvsP.1.2.0.translation.rar)
Awesome! I added a link to the download page, I linked to the directory instead of the file itself to make it easier to update for newer versions, let me know if that's a problem.

nibbles

4th October 2006, 05:05

...I'll try and implement it and see how it looks...
Forget about the pointer giving video coordinates back.
You'd be faced with some ugly conversions between display
position and video pixels! (square? dv? pc? zoom? scrollbar?)

Threads are easy in Swing. How about Python? I was really
impressed the way I could be slewing through my video
with an arrow key and simultaneously be rolling the mouse
wheel, switching between tabs and filters with no pause
in the playback!

You might want to take a quick look at JEdit (http://www.jedit.org/), a great Java editor
that has line numbering similar to AvsP and has markers.

Is it possible to preset the width of the line number margin
to support one to three digit numbers without having to widen
itself? If you make 9 blank lines then a 10th, you will see that
the margin gets wider. The problem I often face is that I'll be
comparing scripts, some having fewer than 10 lines, some
more, and when I switch tabs, the text stutters horizontally.
Ok super good. nibbles.

zemog

4th October 2006, 15:57

This is mi first post in the forum. Hello everybody and sorry for my poor english

qwerpoi: Thanks for these great app. I use it a lot last two weeks. It does work fine for most of my needs. I have saved a lot of time in my last MiniDV tape edition.

I attach mi contribution: Spanish translation.

Some comments about these:
- I have add three lines (the last three) that I think are missing in __translation.py file.
- In the attached .rar file I include a .doc file with some screenshots where you can see English words that can’t be translated.

qwerpoi

5th October 2006, 02:26

Threads are easy in Swing. How about Python? I was really
impressed the way I could be slewing through my video
with an arrow key and simultaneously be rolling the mouse
wheel, switching between tabs and filters with no pause
in the playback!
Well, I believe Python has good thread stuff, but I wouldn't know firsthand - I don't have to take care of threads directly for the gui code with wxPython, which has an event handling system that's a bit tricky at first but is pretty straightforward after a while.

You might want to take a quick look at JEdit (http://www.jedit.org/), a great Java editor
that has line numbering similar to AvsP and has markers.
Thanks for the link, I'll look it over when I get the chance. Keep in mind though, I have no aspirations in making AvsP the best programming editor out there, I'd much rather focus on developing the really unique AviSynth-specific features. Then again, most people are stubborn in letting go of their personal editors (with good reason), so I'll try and do what it takes to keep those people happy as well. :)

Is it possible to preset the width of the line number margin
to support one to three digit numbers without having to widen
itself? If you make 9 blank lines then a 10th, you will see that
the margin gets wider. The problem I often face is that I'll be
comparing scripts, some having fewer than 10 lines, some
more, and when I switch tabs, the text stutters horizontally.
Ok super good. nibbles.
No problem, it'll be in the next release.

This is mi first post in the forum. Hello everybody and sorry for my poor english

qwerpoi: Thanks for these great app. I use it a lot last two weeks. It does work fine for most of my needs. I have saved a lot of time in my last MiniDV tape edition.

I attach mi contribution: Spanish translation.

Some comments about these:
- I have add three lines (the last three) that I think are missing in __translation.py file.
- In the attached .rar file I include a .doc file with some screenshots where you can see English words that can’t be translated.
Sorry for the late reply, I wanted to wait until the attachment was approved (still waiting). Thanks for doing the translation, I'll be sure to add the link on the download page when I can access the file. As far as untranslatable messages go, it's possible that some dialog boxes cannot be translated, since they are handled by windows, not by AvsP. If that's the case, you may be able to do something about it by changing the windows regional settings, but I don't know much about it.

nibbles

5th October 2006, 08:24

When the script window is in focus and the preview window is open
and the line by line update is disabled, inserting the current frame
number inside an unclosed argument causes a Shift+Tab sort of
operation and an error because

c1.Trim(0,354998).DeleteFrame(12345

code like that isn't ready for previewing. Would you take a look at
it when you have some free time? Ok, thanks q. I started to think
that your avatar was from The Wall....

krisq

5th October 2006, 12:01

Just a thought. Would be cool if slider like this:
Shadows = (Select([<"Shadows", 0, 1, 0>], true, false))

could show 'boolean' values instead of numbers (like 'true' or else).

foxyshadis

5th October 2006, 16:37

Well, as a workaround what you can do instead is

Shadows=false

Shadows=true

Then if you check it it'll be true.

krisq

5th October 2006, 18:51

Yeah, I know. But i'd like to have everything in one place. And this gives me checkbox above 20 other sliders from different filters.
Besides, this one would be trickier:

Histogram(Select([<"HistogramMode", 0, 3, 0>],"classic","levels","color","luma")))

qwerpoi

5th October 2006, 20:24

@zemog
I took a look at the attached file, you did a very complete job! These are the translation strings I was missing:
"Enter tag name:"
"Tag definition"
"OK"
"Cancel"
You also put down several strings which seem to translate fine on my computer:
"AviSynth plugin (*.dll)|*.dll"
"AviSynth script (*.avs)|*.avs|All files (*.*)|*.*"
It's possible that there's an issue with the open file dialog box; can any other translators confirm this?

Also, you should be aware that the keyboard shortcuts in the menus cannot be translated currently, since the strings are used by the program to register the actual keyboard shortcuts. I'm still working on this issue.

When the script window is in focus and the preview window is open
and the line by line update is disabled, inserting the current frame
number inside an unclosed argument causes a Shift+Tab sort of
operation and an error because

c1.Trim(0,354998).DeleteFrame(12345

code like that isn't ready for previewing. Would you take a look at
it when you have some free time? Ok, thanks q. I started to think
that your avatar was from The Wall....
Hey, you're right - thanks for catching that bug! It'll be fixed in the next release. Oh and my avatar's not from The Wall, I'm not that hip - it's a really obscure reference and I'd be relatively surprised if anyone knew what it was. :)

Just a thought. Would be cool if slider like this:
Shadows = (Select([<"Shadows", 0, 1, 0>], true, false))

could show 'boolean' values instead of numbers (like 'true' or else).
Yeah, it would be cool, but also a bit strange. Essentially, a slider is not ideal for representing arbitrary lists (there's no meaning for the min and max values, etc).

What we're really getting at is that there should be a series of different "scriptable gui elements". In other words, sliders are good for numbers, toggle tags are good for checkboxes, and we're missing a syntax for either radio boxes or drop-down lists. Instead of having three separate syntaxes, it would be ideal if it were possible to combine them or unify them somehow. Of course I'm talking purely theoretically, I don't know how if it's even possible to have a parsable syntax for everything. If anyone can think of a complete scheme, I'm all ears, until then, you'll have to live with integer-mapping sliders. :)

kurt

5th October 2006, 21:07

hm, can't get access to the website: http://www.avisynth.org/qwerpoi/Download.html

is it down? can s.o. confirm?

krisq

5th October 2006, 21:58

hm, can't get access to the website: http://www.avisynth.org/qwerpoi/Download.html

is it down? can s.o. confirm?

yep, down for me also.

If anyone can think of a complete scheme, I'm all ears, until then, you'll have to live with integer-mapping sliders. :)

I think it's fine the way it is, but in this case
Histogram(Select([<"HistogramMode", 0, 3, 0>],"classic","levels","color","luma")))
instead of:

0<--------||---->3 1

I would like to see something like this:

0<--------||---->3 "levels"

qwerpoi

5th October 2006, 22:17

hm, can't get access to the website: http://www.avisynth.org/qwerpoi/Download.html

is it down? can s.o. confirm?
Yeah, avisynth.org goes down occasionally, usually it's fine after an hour or two.

I think it's fine the way it is, but in this case
Histogram(Select([<"HistogramMode", 0, 3, 0>],"classic","levels","color","luma")))
instead of:

0<--------||---->3 1

I would like to see something like this:

0<--------||---->3 "levels"
Yes, but from an implementation perspective it would require parsing the script to check if any user sliders are within an AviSynth Select function, which may be very difficult to do properly. It would actually be easier to make a new syntax like this:
Histogram([<"HistogramMode", ["classic","levels","color","luma"]>])
Not to say it's easy to parse this syntax, it looks doable but tricky (very error prone in terms of validation). But if I were to do this, again I would argue that it would be better to go all out and develop a good generic syntax, one which allows for all the basic gui elements (sliders, check boxes, drop-down lists, etc). Or maybe not - perhaps I'm overthinking things. It just seems the natural extension of things, I think it would be nicer if the section toggle syntax was combined with the slider syntax (the fact that the syntax is totally different is one of the reasons why they show up in separate places).

krisq

5th October 2006, 23:03

Histogram([<"HistogramMode", ["classic","levels","color","luma"]>])

I agree, this would be very neat. I get your thinking now. Very reasonable actually. It's easy for me to propose things when I don't have to 'do' them :D

foxyshadis

6th October 2006, 02:01

Histogram([<"HistogramMode", Select:["classic";"levels";"color";"luma"]>])
For a drop-down. Or maybe Drop:.
Histogram([<"HistogramMode", Select:["classic":0;"levels":1;"color":2;"luma":3]>])
Would give integers a meaningful label.
Histogram([<"HistogramMode", Select:["Plain":"classic";"Spicy":"levels";"Tripout":"color";"luma"]>])
Here the last value would show up as luma since it has no tag.
Histogram([<"HistogramMode", OnOff>])
OnOff, Bool, YesNo, Checkbox, TrueFalse, I don't know.
Histogram([<"HistogramMode", Multi:["Dude":1;"Whoa":2;"Keanu":3]>])
Same, but radio instead of drop-down.
Histogram([<"HistogramMode", [0, 3, 0]>])
Unlabeled it's synonymous with the current method. You could totally skip labeling and encapsulation and just guess each time, but I think that would be pretty nuts. :p

Of course it can be extended to presets...
Histogram([<"HistogramMode", Multi:["Preset 1":mode="color",expand=true;"Preset 2":mode="levels",expand=false]>])
Since in the end, it's just replacing with the relevant text between : and ;.

Just throwing ideas out there.

As an aside, check out TBilateral's GUI for what happens when you thrown in everything and the kitchen sink. :p

Richard Berg

6th October 2006, 03:41

See here for website status: http://status.leafyhost.com/

qwerpoi

6th October 2006, 06:37

I've mirrored version 1.2.0 on rapidshare since avisynth.org is down for the moment:

http://rapidshare.de/files/35670265/AvsP_v1.2.0.zip.html

It seems kind of a waste, since I'll be updating a new version soon, but this will tide you over if you gotta have it now.

I agree, this would be very neat. I get your thinking now. Very reasonable actually. It's easy for me to propose things when I don't have to 'do' them :D
No, I appreciate any and all feature requests, honestly. As a developer I precisely need feedback from people who don't know how difficult something is going to be to implement (otherwise my lazy factor will kick in). I'm not saying I will implement every request, I'm just saying it helps me keep an open mind. Plus, people on the doom9 boards tend to be pretty rational, any requests I have shot down were almost always because difficulty of implementation outweighed the benefit of the feature, not because the idea itself was bad.

Histogram([<"HistogramMode", Select:["classic";"levels";"color";"luma"]>])
For a drop-down. Or maybe Drop:.
Histogram([<"HistogramMode", Select:["classic":0;"levels":1;"color":2;"luma":3]>])
Would give integers a meaningful label.
Histogram([<"HistogramMode", Select:["Plain":"classic";"Spicy":"levels";"Tripout":"color";"luma"]>])
Here the last value would show up as luma since it has no tag.
Histogram([<"HistogramMode", OnOff>])
OnOff, Bool, YesNo, Checkbox, TrueFalse, I don't know.
Histogram([<"HistogramMode", Multi:["Dude":1;"Whoa":2;"Keanu":3]>])
Same, but radio instead of drop-down.
Histogram([<"HistogramMode", [0, 3, 0]>])
Unlabeled it's synonymous with the current method. You could totally skip labeling and encapsulation and just guess each time, but I think that would be pretty nuts. :p

Of course it can be extended to presets...
Histogram([<"HistogramMode", Multi:["Preset 1":mode="color",expand=true;"Preset 2":mode="levels",expand=false]>])
Since in the end, it's just replacing with the relevant text between : and ;.

Just throwing ideas out there.

As an aside, check out TBilateral's GUI for what happens when you thrown in everything and the kitchen sink. :p
Some interesting ideas, I'll give it some thought. If I ever implement this stuff, it's very likely to look similar to what you posted here. In reality, I'd like to go nuts and drop the labeling :), in a vain effort to preserve the simplicity of the syntax. If you look at the screenshot on the first post, you can see how each aspect of the slider syntax (label, min, max, value) directly corresponds with what you see on the graphical slider in terms of physical layout. As you start allowing definition of different gui elements, this tight correlation seems impossible, but I think it's very important to try (not for advanced users, but for newcomers or people who know nothing about AvsP trying to stare at a completely bizarre avs script).

Anyway, the whole concept of scriptable gui elements intrigues me, it's like adding new syntax to the AviSynth language itself. Since AvsP is written in wxPython (a scripted gui framework), dynamically building gui elements is the easy part, the hard part is coming up with a correct, concise, and understandable syntax. Of course in order to do it right, it gets to the point where AvsP would need a complete AviSynth parser (otherwise it's impossible to use AviSynth variables within a slider, etc). Ultimately though, I think the majority of the added functionality comes from the already implemented numerical sliders, so in my eyes we're talking about a lot of work for a little benefit. Not to say I won't ever work on it, just saying that other more urgent feature requests will come first.

foxyshadis

6th October 2006, 08:24

Richard Berg

7th October 2006, 23:13

Small suggestions for the Fonts tab:
- have a master font option, then only bring up the color dialog for each font
- default to a monospace font like Lucida Console

qwerpoi

8th October 2006, 00:00

Fair enough. How about this: On the slider gui, have a radio button for "numeric" and "other", and for other get the name like now, and have a multiline textbox where people can add true/false (maybe a button for that?) or custom items, and generate code just like krisq's Select syntax. It's kind of ugly - and that word wrap will come in very handy - but it works. It could generate a proper syntax at some point down the line, too.

A button to then render the script as currently set might be useful as the sliders and checkoffs pile up, and the actual script gets lost behind the noise. It could show all the generated areas in some other color, I'm picturing red, and be read-only (or a new tab).

Oh, and I don't know if this is really possible, but can you put a box around all the sliders from the same line? One line doesn't always correspond to one function, but it's good enough for government work.
Whew, that's a lot to think about, my brain is kinda fried recently. I'll get to thinking and working on this stuff after I finish the new release, should be a good one (keep reading).

Small suggestions for the Fonts tab:
- have a master font option, then only bring up the color dialog for each font
- default to a monospace font like Lucida Console
Aha, one step ahead of you (sorta). The next release will have much improved syntax highlighting (I am nearly finished with my custom AviSynth lexer), so I'll likely get rid of the Fonts tab in the Program options dialog and make a whole new dialog, where you can configure every font, color, and highlight color individually for each AviSynth style. The styles include strings, triple-quoted strings, comments, built-in filters, external filters, etc (I'm still working out the details, but basically I'm trying to allow you to be able to configure everything I can). It will take me a while to work everything into a release-worthy form, so expect the new release in 3 or 4 days, worst case a week from now.

As far as a monospace font as a default, well, there's a catch. If you look at the default fonts right now, you'll notice that there are different fonts and different sizes for things like comments, strings, etc. This text variation improves readability (well, I guess that's my opinion, the default values in AvsP are the same as the default values in SciTe text editor), but obviously screws with a monospaced font maintaining constant column size. The way SciTe deals with this is by having the menu option to switch to a monospaced font (of your choice) at any time, which overrides the fonts for all the styles (basically the "master font" option you mention), and you can always switch back. I'll try to implement something like this, but I can't guarantee that it will be in the upcoming release.

Richard Berg

9th October 2006, 04:30

Sorry about the server guys. I'm really pissed, but what can ya do.

Since I couldn't work on the site, I spent some time learning Python. Fun language. Can't say the same for Py/C++ interop though...unbelievably annoying...

Good news is I've done all the hard work for you. Here's a taste:

import avisynth

env = avisynth.CreateScriptEnvironment()

def GetAVSList (suffix, lst):
return [sorted(env.GetVar(x+suffix).AsString().split()) for x in lst]

def RemoveAltNames (funcNames):
ret = []
continueFor = False
f = None
for func in funcNames:
f = func + "" # make a copy
while f.find("_") > 0:
f = "_".join(f.split("_")[1:])
if f in funcNames:
continueFor = True
break
if continueFor:
continueFor = False
continue
else:
ret += [func]
return ret

funcTypes = ["$Internal", "$Loaded", "$Plugin"]
allFuncs = GetAVSList("Functions$", funcTypes)

List2Dict = lambda l1, l2: dict((l1[i], l2[i]) for i in range(len(l1)))

allParams = []
nonAltFuncs = []
for names, funcs in List2Dict(funcTypes, allFuncs).iteritems():
allParams += ["%s!%s!Param$" % (names, func) for func in RemoveAltNames(funcs)]
nonAltFuncs += [func for func in RemoveAltNames(funcs)]

allParams = GetAVSList("", allParams)

print List2Dict(nonAltFuncs, allParams)

Output:

{'MVMask': ['c[vectors]c[ml]f[gamma]f[kind]i[Ysc]i[thSCD1]i[thSCD2]i[mmx]b[isse]b'], 'JDL_SpliceVertical': ['cci'], 'UPlaneMedian': ['c'], 'lcase': ['s'], 'MotionFPS': ['c[FPS]f[method]i[chromamethod]i[source]i[motion]c'], 'JDL_ShowFrameOffset': ['c[cycle]i[height]i'], 'Warp': ['[warpinterpolation]i[moveinterpolation]i'], 'TransVenetianBlinds': ['cci[width]i[type]s'], 'LogOpen': ['s[append]b'], 'SangNom': ['c[order]i[aa]i'], 'MotionProtectedFPS': ['cf[mode]i[protection]i[iterate]i[reset]i[initialise]i'], 'Histogram': ['c[mode]s'], 'JDL_SelectTopField': ['c'], 'TBilateral': ['c[diameterL]i[diameterC]i[sDevL]f[sDevC]f[iDevL]f[iDevC]f[csL]f[csC]f[d2]b[chroma]b[gui]b[ppClip]c[kernS]i[kernI]i[resType]i'], 'LoadVirtualdubPlugin': ['ss[preroll]i'], 'TomsMoComp': ['ciii'], 'SumStretchMask': ['c[multiplier]i'], 'TransMarbles': ['cci[radius]i[mag]i[drop]b'], 'Spline36Resize': ['cii[src_left]f[src_top]f[src_width]f[src_height]f'], 'GMC_UnExpand': ['c'], 'FadeIn': ['ci[color]i[fps]f'], 'midstr': ['si[length]i'],......etc.......]

You get the idea.

http://rapidshare.de/files/36038409/AVSPython.zip.html - 6MB

I've included a full debug environment in the download since (a) it's a real bitch to compile everything on Windows; every package required messy template and/or macro workarounds (b) I only ported about 3% of avisynth.h, and you'll definitely want a full debug stack if you continue the work (c) it uses AVS 2.6 + some diffs. Namely, the plugin interface is more consistently named and finally includes dynamically loaded functions & plugins. I also got about 1/3 of the way thru fixing all the MSVC8 warnings. I'm tired and traveling all next week, peace out for now..

qwerpoi

9th October 2006, 18:56

@Richard Berg
Wow, that's pretty damn impressive, considering you just learned python! Well, it took me only a couple of days to learn Python myself, but I was pretty far from lambda functions, list comprehensions, and c++ bindings (which is probably the most complex thing you'll ever encounter with Python).

I see you're using Boost for the c++ bindings, there's also SWIG - I've used Boost before, I've looked at SWIG, I don't like either one. One other possibility is to wrap the c++ code with c code and compile a dll, Python can call c dlls directly using ctypes (used to be a third-party plugin, now part of the standard Python distribution since v2.5). I realize that there already exists avisynth_c.dll, but from my experiments it's not compatible with ctypes.

So, I want to understand what advantages a Python binding to AviSynth can bring to AvsP, beyond function enumeration (something tsp is working on). I realize that I should look at the avisynth cpp source myself, which I will do, just want to avoid any misunderstandings on my part. First, it would be cool to use AviSynth to get the output video, currently I'm using AVIFile functions from avifil32.dll. To display a frame, AvsP requires pointers to a windows bitmap header and data - is this directly possible with AviSynth? Secondly, AvsP would benefit from being able to parse the script for variable information, ie currently it's not possible to use an AviSynth variable within a user slider. I'm not sure how this can be achieved. Thirdly, although this isn't a direct benefit to AvsP, but I believe with a full port you should be able to write AviSynth plugins in Python. The performance hit will make this impractical for most purposes, but it may be cool to script custom plugins either for one-time use or for prototyping, would probably be a good fit with AvsP's macros. I'm sure there are other advantages to a Python binding to AviSynth, this is what comes to my mind right now. Anyone familiar with the AviSynth source, feel free to either correct me or add new ideas.

Edit: Just realized that python bindings to avisynth could result in a significant speed/memory boost for user sliders, since it would be possible to get individual frames as opposed to reloading the entire video with a new .avs file (I actually mentioned this in one of the earlier posts, must be going senile). If this is true then it would be possible to constantly update the video as you drag a user slider, which would be cool.

tsp

9th October 2006, 21:20

So, I want to understand what advantages a Python binding to AviSynth can bring to AvsP, beyond function enumeration (something tsp is working on). I realize that I should look at the avisynth cpp source myself, which I will do, just want to avoid any misunderstandings on my part. First, it would be cool to use AviSynth to get the output video, currently I'm using AVIFile functions from avifil32.dll. To display a frame, AvsP requires pointers to a windows bitmap header and data - is this directly possible with AviSynth?

not directly but you can get an avisynth frame that contains the raw data so it should be easy to convert it to a windows bitmap (or create a c wrapper to do it)

Secondly, AvsP would benefit from being able to parse the script for variable information, ie currently it's not possible to use an AviSynth variable within a user slider. I'm not sure how this can be achieved.

you will need to process the script until just before the filter where the slider appears. When you call GetVar to get the content of the varible and use it with the slider. Then you process the rest of the script
Thirdly, although this isn't a direct benefit to AvsP, but I believe with a full port you should be able to write AviSynth plugins in Python. The performance hit will make this impractical for most purposes, but it may be cool to script custom plugins either for one-time use or for prototyping, would probably be a good fit with AvsP's macros. I'm sure there are other advantages to a Python binding to AviSynth, this is what comes to my mind right now. Anyone familiar with the AviSynth source, feel free to either correct me or add new ideas.

[quote]
Edit: Just realized that python bindings to avisynth could result in a significant speed/memory boost for user sliders, since it would be possible to get individual frames as opposed to reloading the entire video with a new .avs file (I actually mentioned this in one of the earlier posts, must be going senile). If this is true then it would be possible to constantly update the video as you drag a user slider, which would be cool.

you will still need to reload the script every time the slider is moved (unless you are creative with scriptclip) because the parameters you change are used by the filters when the script is created.
if you use scriptclip you can assign the slider value to a avisynth variable using setvar, the problem with using scriptclip is that the filter is recreated for each frame even if the slider value hasn't change.

Richard Berg: qwerpoi will need to use the included version of avisynth to get AVSPython to work or at least avisynth 2.5.7?

Richard Berg

9th October 2006, 22:47

Well, it took me only a couple of days to learn Python myself, but I was pretty far from lambda functions, list comprehensions, and c++ bindings (which is probably the most complex thing you'll ever encounter with Python).
Part of the reason Python was on my list of languages to learn is because it's a friendly intro to functional programming. Test.py make have been my first program, but remember I spent 2 whole days making it work and refactoring it with cool Python features :) Haskell is next...

I don't like either one.
I don't like it either. I actually had to fix a bug in Boost::Python::details in order to make it compile __stdcall / __cdecl decorations correctly. Have you ever tried to debug someone else's template metaprogramming before? I don't recommend it.

But that's behind us now. Translating the rest of avisynth.h will be straightforward with the tools I provided.

I'm sure there are other advantages to a Python binding to AviSynth
From what I've seen of Python, writing video filters would be even more annoying than slow. Lots of people malign C++ raw pointer access, but it makes working with video data quite natural & intuitive IMO, especially now that we have planar colorspaces.

For "big" applications of this line of work, I thought of something even more radical: replacing the AVS scripting language with Python. Didee scripts and AvsP macros would both become a lot more powerful & easy... What do you think?

you will need to process the script until just before the filter where the slider appears.
Correct. In fact, without a lot of work, you'll need to reload the whole script. Partitioning the script by adjustable-filters is a great optimization but will be tricky to get right.

If you use it with avisynth 2.5.7 then you'll need to change the GetVar call.

2.5.7:
$InternalFunctions$ Should contain function names of all internal functions.
$InternalFunctions!Functionname!Param$ Should contain all parameters for each internal function.
$PluginFunctions$ Should contain all plugins.
$Plugin!Functionname!Param$ Should contain all parameters.

2.6.richardb:
$InternalFunctions$
$Internal!Functionname!Param$
$PluginFunctions$
$Plugin!Functionname!Param$
$LoadedFunctions$
$Loaded!Functionname!Param$

Alain2

9th October 2006, 23:58

For "big" applications of this line of work, I thought of something even more radical: replacing the AVS scripting language with Python. Didee scripts and AvsP macros would both become a lot more powerful & easy... What do you think?
Do you suggest that Didee and others start scripting in a python language instead of avs ? If it's the case, do you think it will be easy for others like me to learn python and understand Didee's scripts ? Or to convert my own scripts to python ? Avs is a simple and yet powerful language, very easy for anybody to learn and easy to read, I am not sure about python.. ?

Richard Berg

10th October 2006, 00:06

Python is very easy to read and learn. It's also quite similar to AVS. But don't worry -- if we ever added another language (and that would be a long way off), we wouldn't remove the old one, of course.

Ebobtron

10th October 2006, 05:23

Edit: Just realized that python bindings to avisynth could result in a significant speed/memory boost for user sliders, since it would be possible to get individual frames as opposed to reloading the entire video with a new .avs file (I actually mentioned this in one of the earlier posts, must be going senile). If this is true then it would be possible to constantly update the video as you drag a user slider, which would be cool.

Some months back while I was looking for a solution to my use of the prehistoric MCI (Media Control Interface) video viewer in FilmCutter (http://forum.doom9.org/showthread.php?t=97438). I remembered toying with the following two AviSynth plug-ins.

avsmon "AviSynth monitor" (by johann.Langhofer)
http://forum.doom9.org/showthread.php?s=&threadid=32125

tritical's Tmonitor
http://bengal.missouri.edu/~kes25c/

Neither plug-in when running consumed more than 15 percent cpu resources above what a player / viewer was already using. Two viewers running real time (simple scripts), seem very exciting.

What I saw in the source code suggested to me that a very quick and efficient viewer could be developed using the script environment get frame thing to output frames directly to the screen. But I do suffer from the advantage of not knowing what I am doing.

Lacking help and ability, the inspiration soon deserted me, maybe you will have better luck.

2.5.7:
$InternalFunctions$ Should contain function names of all internal functions.
$InternalFunctions!Functionname!Param$ Should contain all parameters for each internal function.
$PluginFunctions$ Should contain all plugins.
$Plugin!Functionname!Param$ Should contain all parameters.

When Fizick found the bug in 2.56 (http://forum.doom9.org/showthread.php?p=737582#post737582), I discoverd that " $InternalFunctions!Functionname!Param$ " didn't work as advertized, " $Plugin!Functionname!Param$ " does work for both internal and plug-in functions in current builds of 2.57.

@qwerpoi
"Thanks for your works", to quote Fizick
@Richard
Thanks to you too, sir, for AviSynth.org.

rfmmars

10th October 2006, 05:48

In my HDRagc script the "shift_u & shift_v functions work as they should.

I have added sliders for most of the functions without a problem, however when making the sliders for the "shift function" they act only as a color level controls.

HDRAGC([<"max_gain", .1, 5, 2.3>], [<"min_gain", .1, 5, 2.0>], [<"blackclip", 0, 1, 0.5>],[<"coef_sat", 0, 4, 4>],[<"reducer", .1, .9, 0.4>],[<"Shift_u", -44, +44, 33>][<"Shift_v", -44, 44, 35>],corrector=.7)

Is this a bug or can there be a work around?

Richard

qwerpoi

10th October 2006, 07:23

you will still need to reload the script every time the slider is moved (unless you are creative with scriptclip) because the parameters you change are used by the filters when the script is created.
if you use scriptclip you can assign the slider value to a avisynth variable using setvar, the problem with using scriptclip is that the filter is recreated for each frame even if the slider value hasn't change.
I thought that may be the case. Still, that's better than what is being done now, using AVIFile functions AvsP has to write out a new .avs script to the hard drive every time a slider value is changed, which is obviously problematic for instantaneous updating.

For "big" applications of this line of work, I thought of something even more radical: replacing the AVS scripting language with Python. Didee scripts and AvsP macros would both become a lot more powerful & easy... What do you think?
Wow, that's is a radical idea. Given the similarities between the languages, and given the fact that Python is an absolutely complete language, I think it would be very cool (at the minimum there would no longer be a need to hack for loops in AviSynth :) ). It seems to me that it would be possible to make the Python syntax nearly 100% compatible with the AviSynth syntax (although I'm not sure how the implicit "last" variable would work out), which would be awesome.

Avs is a simple and yet powerful language, very easy for anybody to learn and easy to read, I am not sure about python.. ?
I am in complete agreement about AviSynth as a language, I would argue it's the best way to teach a beginner how to program :eek: . Python is a very easy to learn language, in many ways it removes much of the complexity out of programming, but in reality it is geared towards people who are already familiar with an object oriented language like C++. I don't think many people will agree with me, Python is often recommended as the ideal programming language for beginners. Again, I would say AviSynth is better - you get to learn the concept of variables and program flow, no need for a compiler, all syntax errors are caught and displayed with a video, and most importantly, you can immediately see the benefit of learning how to program (improving video quality or compressibility is something that absolutely anyone can appreciate). Of course after understanding the basics with AviSynth, you could move on to other languages for advanced programming concepts, I would clearly recommend Python for that.

Some months back while I was looking for a solution to my use of the prehistoric MCI (Media Control Interface) video viewer in FilmCutter (http://forum.doom9.org/showthread.php?t=97438). I remembered toying with the following two AviSynth plug-ins.

avsmon "AviSynth monitor" (by johann.Langhofer)
http://forum.doom9.org/showthread.php?s=&threadid=32125

tritical's Tmonitor
http://bengal.missouri.edu/~kes25c/

Neither plug-in when running consumed more than 15 percent cpu resources above what a player / viewer was already using. Two viewers running real time (simple scripts), seem very exciting.

What I saw in the source code suggested to me that a very quick and efficient viewer could be developed using the script environment get frame thing to output frames directly to the screen. But I do suffer from the advantage of not knowing what I am doing.

Lacking help and ability, the inspiration soon deserted me, maybe you will have better luck.
Hah, I have no idea what I'm doing either :) . Really a lot of the stuff being discussed in these last several posts are a bit over my head, it's certainly interesting, a lot of exiting possibilities, and I will spend effort trying to make the most of it, but I will again stress that I'm not a great programmer on a technical level. Stuff like compiler issues and dll compatibility give me a headache, I never was even able to successfully make an AviSynth plugin (I guess mostly because I quit, though :p ). The reason I eventually went to python/wxpython is because I don't need to be a technical whiz in order to get impressive results.

In my HDRagc script the "shift_u & shift_v functions work as they should.

I have added sliders for most of the functions without a problem, however when making the sliders for the "shift function" they act only as a color level controls.

HDRAGC([<"max_gain", .1, 5, 2.3>], [<"min_gain", .1, 5, 2.0>], [<"blackclip", 0, 1, 0.5>],[<"coef_sat", 0, 4, 4>],[<"reducer", .1, .9, 0.4>],[<"Shift_u", -44, +44, 33>][<"Shift_v", -44, 44, 35>],corrector=.7)

Is this a bug or can there be a work around?

Richard
In the script you posted you are missing a comma between the shift_u and the shift_v slider.

If that doesn't solve the problem, then try these things out. First, you should make sure that you don't have any other sliders in your script with the same names. Second, you should get rid of ALL user sliders, and test whether the filter behaves as you expect when you change the numbers manually. If this does not solve the problem, then you may need to post some screenshots, since I am not certain about the expected behavior of the hdr agc filter.

Pookie

10th October 2006, 08:45

qwerpoi

10th October 2006, 08:53

May I add a request to your "when I get around to it" list? What about a menu choice like "Transcode with External App" which would have a path field for a command line app (FFmpeg, x264, Mencoder come to mind), a field for switches, and a place to add an output file name - everything could be typed in manually.

Thanks, man. :)
Haha, you read my mind (or did I read yours?). In the next release there will be a way to do this via macros, so you can have as many external apps as you want in the menu and assign them whatever keyboard shortcuts you want. I'll supply a sample macro, all you would have to do is change the path to the app and the command line arguments. The new release is coming soon, perhaps in 2 days...

rfmmars

10th October 2006, 17:53

"In the script you posted you are missing a comma between the shift_u and the shift_v slider.

If that doesn't solve the problem, then try these things out. First, you should make sure that you don't have any other sliders in your script with the same names. Second, you should get rid of ALL user sliders, and test whether the filter behaves as you expect when you change the numbers manually. If this does not solve the problem, then you may need to post some screenshots, since I am not certain about the expected behavior of the hdr agc filter."

Sorry for the comma missing but that made no difference. I deleted all non "HDRagc" scripting and the problem remained.
Moving the "shift functions to an earlier position of the code line gives an "avisynth" error with no other information. The same script without the AVSp notation works fine. All the sliders appear but the first shift slider acts like a colour level control, and the second does nothing.

I will post a picture but I don't think it will help.

Richard

Ignus2

10th October 2006, 22:39

Great program! Just what I needed, EXACTLY what I needed.
Thank you for it!

And now my problem:
The video preview always closes, when I switch tabs.
Is this intended?

--
Greets,
B.

qwerpoi

10th October 2006, 22:59

Sorry for the comma missing but that made no difference. I deleted all non "HDRagc" scripting and the problem remained.
Moving the "shift functions to an earlier position of the code line gives an "avisynth" error with no other information. The same script without the AVSp notation works fine. All the sliders appear but the first shift slider acts like a colour level control, and the second does nothing.

I will post a picture but I don't think it will help.

Richard
The reason I need a picture is that since I'm not familiar with the filter, I can't tell whether the slider is working or not based on the output video. So if you could post a picture of AvsP with a script with no sliders, and another picture of AvsP with a script with the problematic slider set to the same value, I can see for myself how the video outputs are different when they should be the same. Also, it would help if you could post any scripts that cause unexpected errors.

The video preview always closes, when I switch tabs.
Is this intended?
The video preview will close when you switch tabs IF the two videos do not have similar properties (same width, height, and framecount). This is done to avoid any confusing behavior when comparing multiple script outputs. I would give you a link to the online docs for more info, but avisynth.org is down for the moment :( .

rfmmars

11th October 2006, 00:51

[QUOTEThe reason I need a picture is that since I'm not familiar with the filter, I can't tell whether the slider is working or not based on the output video. So if you could post a picture of AvsP with a script with no sliders, and another picture of AvsP with a script with the problematic slider set to the same value, I can see for myself how the video outputs are different when they should be the same. Also, it would help if you could post any scripts that cause unexpected errors. :( .[/QUOTE]

I have shorten the script, it all shows in each pic.

Here are the shots, The first is without the Shift_xxx sliders, everthing is normal

http://www.uploading.com/files/QKMVIZE1/No_Shift.jpeg.html

Here is the problem, the one shift slider act like a level control, depending where you put it, is effect is never correct but different, even alone, and the other has no effect, good or bad.

http://www.uploading.com/files/6SAR87OW/Shift.jpeg.html

This is what it should look like. The shift settings are manually set

http://www.uploading.com/files/MGZ7WLWH/Shift_Manualyy.jpeg.htm

I am not saying its your program, I am looking for a solution, and the problem may be with HDRagc.

Richardl

qwerpoi

11th October 2006, 01:20

I have shorten the script, it all shows in each pic.

Here are the shots, The first is without the Shift_xxx sliders, everthing is normal

http://www.uploading.com/files/QKMVIZE1/No_Shift.jpeg.html

Here is the problem, the one shift slider act like a level control, depending where you put it, is effect is never correct but different, even alone, and the other has no effect, good or bad.

http://www.uploading.com/files/6SAR87OW/Shift.jpeg.html

This is what it should look like. The shift settings are manually set

http://www.uploading.com/files/MGZ7WLWH/Shift_Manualyy.jpeg.htm

I am not saying its your program, I am looking for a solution, and the problem may be with HDRagc.

Richardl
Thanks for posting the pics! It looks like the HDRAGC plugin has all optional arguments, so you must specify the names if your arguments are not in the default order. Something like this script should fix your problem:
AVISource("C:\hdragc.avi")
HDRAGC(shift_u=[<"shift_u", -30, +30, -22>], shift_v=[<"shift_v", -30, +30, -2>])
Most likely you got accidentally confused with the slider name and the optional argument name - the user sliders do not automatically input optional argument names into the filter. Let me know if there are still issues.

rfmmars

11th October 2006, 01:25

Thanks for posting the pics! It looks like the HDRAGC plugin has all optional arguments, so you must specify the names if your arguments are not in the default order. Something like this script should fix your problem:
AVISource("C:\hdragc.avi")
HDRAGC(shift_u=[<"shift_u", -30, +30, -22>], shift_v=[<"shift_v", -30, +30, -2>])
Most likely you got accidentally confused with the slider name and the optional argument name - the user sliders do not automatically input optional argument names into the filter. Let me know if there are still issues.

Just super, that did it...........EXCELLENT

Richard

qwerpoi

11th October 2006, 06:28

avisynth.org may be down, but we must continue onwards! New version 1.2.1, get it from here (http://rapidshare.de/files/36377094/AvsP_v1.2.1.zip.html) (rapidshare). It's another big changelog:

* custom syntax highlighter, more than 30 individually configurable fonts/colors

* added ability to override all fonts with a monospaced font (suggested by Richard Berg)

* added recent files menu (suggested by check)

* added shortcut for moving lines up/down (suggested by communist)

* added method to disable video preview (suggested by Alain2)

* added option to specify initial line margin width (suggested by nibbles)

* added optional arguments to pass to external player

* updated several macro functions, see new examples and macros_readme.txt for info

* added option to disable frequent calltips, show only upon typing open parentheses

* added ability to use keyboard shortcut for filter help file (suggested by Alain2)

* added option to wrap the text (suggested by Alain2)

* added option to highlight current line (suggested by Alain2)

* added 25% and 50% zoom levels (suggested by communist)

* moved line-by-line update mode to menu option, to allow for keyboard shortcut

* changed data format for options files to editable text files

> fixed minor bug with improper video updating (thanks nibbles)

> fixed small mistakes with some messages (thanks zemog)

> fixed minor bug with tabs and spaces

> fixed minor bug with session saving/loading

> cleaned up minor issues with tooltip code

The biggest change is the custom syntax highlighter which I finally got around to implementing. All the tiny issues with things like triple-quoted strings and % coloring should be handled properly now. You can configure practically every font and color in the menu option "Options -> Fonts and colors...". The info is stored in a separate file, textstyles.dat. Be aware that I implemented the highlighting code in Python, not c++, so it may be slower (I didn't notice any performance issues). If it turns out that there are issues with the new highlighter, you can revert back to the old one in "Options -> Program settings..." under the "Misc" tab.

Another noteworthy change is that you can now have as many external players that you want, via macros. There's a new sample macro called "Secondary player.py", make a copy of it and change the exe path and arguments to whatever you need. There are also new sample macros which show how to feed the current script in AvsP to an encoding program, good stuff if you use command-line encoders.

One final thing I'll mention is that now the data format for the options files is text instead of binary. It's not necessarily human readable (not much worse than xml imo :) ), but it is editable if that sort of thing is appealing to you.

As always, with big changes come big bugs, so report back with any problems with the new version.

niiyan

11th October 2006, 16:27

@qwerpoi
When I type ")", AvsP v1.2.1 always displays "(".:o

Henrikx

11th October 2006, 17:12

Update German translation to AvsP 1.2.1

qwerpoi

11th October 2006, 20:07

@qwerpoi
When I type ")", AvsP v1.2.1 always displays "(".:o
Whoa, that's a big problem! I believe it only affects certain non-us keyboards, sorry about that. I updated the links with a fixed version (same version number, does not affect translation work), you can get it here (http://rapidshare.de/files/36377094/AvsP_v1.2.1.zip.html). Just to be clear, if you are not experiencing this problem, there is no reason to re-download version 1.2.1.

Update German translation to AvsP 1.2.1
Wow, that was fast, I thought this one would take a bit longer, there were a lot of new messages! Hope you are liking the new version.

Henrikx

11th October 2006, 20:36

@qwerpoi
The sense of the sentence in German language is sometimes difficult. Example : Triple-quoted string..but a Thread ,called Translate Technical terms, by Forum Gleitz help me much ...special LigH and Doxville

Therefore I only can answer No to I thought this one would take a bit longer and Yes to Hope you are liking the new version.

communist

11th October 2006, 21:55

Just to be clear, if you are not experiencing this problem, there is no reason to re-download version 1.2.1.
Thanks! English XP SP2 with german keyboard setup, had the problem - was fixed with the 'latest' 1.2.1.

New version just rocks!

krisq

11th October 2006, 22:23

Excellent update, as always :D
Thanks!

Alain2

12th October 2006, 01:35

French translation updated :)

Good work again ! Thank you ;)

Do you think it would be possible to make the video window independant of the editor window, and maybe put the sliders / block tick boxes in a separate window or to the right of the editor window, with a fixed width selectable in the options ? That way the sliders wouldn't change when we resize AvsP window or when the video window is resized. Also this may enable an easy video resizing with its window size ^^ (ok that's the last time I bother you with this video preview resizing business ^^)

Let me quickly explain how I usually compare filters effects in a script : What I usually do is to use the interleave function (or my own clipcomp script); a simple script like this would be:mpeg2source("mov.d2v")
# some filters here..
a=last
filter1(arg1=a,..)
b=last
a
filter1(arg1=b,..)
interleave(b.subtitle("a"),last)
I open this in vdubmod, find some interesting positions to look at, and flick through the interleaved frames to see the différences (thanks to avosynth keeping in a buffer the frames it's possible to go back and forth at a position very quickly when the frames have been processed once). That way it's very fast so you clearly see the effect (I often resize with a 1:1 ratio the vdubmod window to the width of my screen to beeter see the effect). And to change an argument and see the effect I just do alt+tab to come back to n++, do the change, alt+tab to come back to vdubmod, and hit F5 to refresh at the current position. This proves very effective, and I am nearly able to do it with AvsP.

What I currently don't like with the duplication of a script in several tabs for comparing is that although it's fast to switch tabs, everytime I seek to a new position, all scripts need to be reloaded to that position, and with slow filters (motion compensation etc) it is rather slow to reload all these full scripts rather than the interleave function (that save rebuilding all filters before the part you're interested in, and avoids duplicating frames in memory at a position as its only one clip that contains it all). But I love everything else in AvsP ^^ That's why if I could reproduce something similar to what I have with n++/vdubmod, I would be really happy; but if you don't do it I understand, I am probably in minority for this request anyway, and all the syntax highlighting + calltips + filters help access you've added to AvsP already qualify it as an excellent avisynth dedicated editor that will very effectively replace my n++ for avs editing :)

Ah a small thing: when I toggle the disable preview window, it first goes back to frame 0 and then switch it off, thus it takes some time to go to frame 0, and it looses the current position..

qwerpoi

12th October 2006, 02:27

Thanks! English XP SP2 with german keyboard setup, had the problem - was fixed with the 'latest' 1.2.1.

New version just rocks!
Whew, glad that is fixed now, and glad you like the new version :) .

Excellent update, as always :D
Thanks!
You're welcome, as always!

French translation updated :)
Excellent! Thanks!

Do you think it would be possible to make the video window independant of the editor window, and maybe put the sliders / block tick boxes in a separate window or to the right of the editor window, with a fixed width selectable in the options ? That way the sliders wouldn't change when we resize AvsP window or when the video window is resized. Also this may enable an easy video resizing with its window size ^^ (ok that's the last time I bother you with this video preview resizing business ^^)
No, it's a valid request, and it's probably the next big thing I need to work on. As I mentioned in an earlier post, the way the preview and sliders are currently layed out works fine with me, but I certainly can understand how it is not ideal when working with large resolution files. It won't be easy to rearrange all the layout code, but it's something I will have to do eventually (but I can't make any guarantees as to when, let's just say it's getting near the top of my todo list).

Let me quickly explain how I usually compare filters effects in a script : What I usually do is to use the interleave function (or my own clipcomp script); a simple script like this would be:
I open this in vdubmod, find some interesting positions to look at, and flick through the interleaved frames to see the différences (thanks to avosynth keeping in a buffer the frames it's possible to go back and forth at a position very quickly when the frames have been processed once). That way it's very fast so you clearly see the effect (I often resize with a 1:1 ratio the vdubmod window to the width of my screen to beeter see the effect). And to change an argument and see the effect I just do alt+tab to come back to n++, do the change, alt+tab to come back to vdubmod, and hit F5 to refresh at the current position. This proves very effective, and I am nearly able to do it with AvsP.

What I currently don't like with the duplication of a script in several tabs for comparing is that although it's fast to switch tabs, everytime I seek to a new position, all scripts need to be reloaded to that position, and with slow filters (motion compensation etc) it is rather slow to reload all these full scripts rather than the interleave function (that save rebuilding all filters before the part you're interested in, and avoids duplicating frames in memory at a position as its only one clip that contains it all).
I see the problem, but I'm not sure what the solution would be. Clearly you can use the interleave function in AvsP in a single tab just like you would when using notepad++/vdub, it would be identical. As far as I see it, using multiple tabs requires loading multiple frames (the first time), I don't see any other way around it. Perhaps I'm misunderstanding your request, so feel free to correct what I'm saying here.

Ah a small thing: when I toggle the disable preview window, it first goes back to frame 0 and then switch it off, thus it takes some time to go to frame 0, and it looses the current position..
Yeah, this was done to avoid strange behavior when changing scripts. In other words, if you disable the preview and it stays at frame 5000, then you switch tabs to a script with only 200 frames, the video slider is in a position which doesn't exist. If you think that behavior is acceptable, I'll do some tests to see if it doesn't cause any problems and change the behavior in the next release.