Can Avisynth plugins have their own GUIs?

[stickboy]

I've seen a few attempts at graphical front-end/editors for Avisynth. In the ones I've seen, the approach is for the front-end to provide a dialog for each filter. Clearly this isn't an ideal approach.

Can each Avisynth plugin DLL export a function for each filter that, when called, generates a Windows dialog with its configuration options and, upon return, generates the corresponding string? Has this been explored already? (I admittedly know almost nothing about Windows programming, so I have no idea if this is feasible.)

The burden would then be distributed among the plugin authors, and each plugin would have a consistent interface across front-ends. In the end, you could have a plug-in system that looks like VirtualDub's, and eventually have a VirtualDub-like editor that internally uses Avisynth instead of Sylia.

[neily]

stickboy,
I can't answer your original question, but as a half way house, having a framework for a parsable text file to be distributed with plugins would be helpful. Sometimes help files are a bit deficient. Having just added a plugin manager to AVSGenie, I am thinking of something along the lines of:

Heading
-------
Plugin name - unique identifier
Author
Helpfile name
AviSynth version compatability

For each function, as some dll's contain more than one function

Function
--------
Function name
Colourspace compatability
Comments

Parameters
----------
ParamName - could be more meaningful than "lcthr"
ParamPrefix - ie 'lcthr=' or ''
ParamReq - whether the parameter needs to be stated
ParamType - int,string,float,bool etc
ParamMin,ParamMax - for numerical params
ParamList - for enumerated parameters
ParamDefaultValue
ParamDependencies - some parameters are only valid dependent on other parameter values.

Obviously, having such a file would help me, but would help other GUI writers as well. Additionally, it would usefully supplement help files, which are sometimes a bit thin.

[Nic]

Both options are feasible and sound. But I can't see guys like Tom wanting to write a nice Windows GUI after coding some hardcore assembly ;) I suppose it could be added as an optional extra and other people, who don't mind writing GUIs could add them to other peoples filters.

might be worth exploring?

-Nic

[neily]

As an afterthought, if some sort of descriptor file could be standardised, it would be no bad thing to have one for AVISynth itself.

[Bidoche]

We talked some times ago about having plugins export an XML description about themselves.

[stax76]

AviSynthEditor by Ajakob (maintained by Dark Cracker) and DVX (powered by M$ .NET :devil: ) share the xml filter descriptions. DVX features a full featured visual editor to create and edit the xml filter descriptions and Ajakob and Dark Cracker work currently on a standalone (VB6) xml filter description editor. Dunno how many filter descriptions are available, quite a lot (most done by seewen :) )

[WarpEnterprises]

Another thought: what about a simple database (e.g. at AviSynth.org) where all plugin properties are shared and extensions (new properties,...) can be transparently added?

[stax76]

imo it would be optimal if AviSynth/plugin developer would provide their dll file along with a xml file. Another idea is to generate a htm documentation automatically with the plugin description editor

[Richard Berg]

A central database would be a workable solution, albeit one that requires constant updating.

Programmatically speaking, there are basically two options: have filters export DLL callbacks with Win32 window commands (like VDub); or have filters export metadata (ideas have been proposed ranging from a standardized struct to XML). The former requires a big rewrite for internal filters; plugins could add additional DLL exports but a GUI would have to autoload them directly (not through AVS). The latter I believe can be done in the existing framework. There's already some simple string feedback added by Tobias Minich; there's also a "void* user_data" that every AVSFunction passes around that to my knowledge is completely unused, though I'm not sure if it can be adapted to pass information "upward."

My vote goes to XML, since once in place it can be easily (and human-readably) extended. Either stuck into string variables, or assembled on avisynth.org, in the end it's less important. Something like:

<plugin>Crop
<name>"Crop"</name>
<author>"BenRG"</author>
<desc_short>"Crops a clip"</desc_short>
<desc_long>"Crop crops excess pixels off of each frame."</desc_long>
<arguments>
<clip type="listbox">clip</clip>
<int type="slider">left_offset
<min>0</min>
<max>clip.width</max>
</int>
...
</arguments>
<colorspaces>
<rgb32 />
<rgb24 />
<yuy2 />
<yv12 />
</colorspaces>
</plugin>

[stickboy]

How much control over the widget layout would plug-in authors have? Would the XML approach be able to support custom widgets?

For example, I could see histograms, preview windows, and vertical sliders being useful.

XML probably would be easier from the development standpoint, but I'm not so sure it would be from the user-experience/usability standpoint.

[neily]

2 points. Firstly, I still go along with the idea of a central database, which would benefit all levels of users. Yes it needs updating, but along with all the other reasons people write plugins, one is the hope that others will use and appreciate them. Having a database entry would greatly increase the chance of that happening.

Secondly, stickboy's last comment points to the fact that possibly a more integrated approach is required, looked at from both the plugin and the GUI point of view. Though it has been suggested before, what is the prospect of an official collaborative GUI being developed? Is there a definite standpoint, or just a lack of desire/resources?

Though I have done my best with AVSGenie given my limited programming skills, and though I appreciate that AVISynth's great strength is it's scripting simplicity, I would love to see what the "big guns" could come up with. Or is it that the "big guns" think on such a higher plain than mere mortals as myself, they have no use for GUI's, and therefore have little interest in developing one. I am not trying to be sarcastic, honestly.

[Richard Berg]

A little of both. Scripting is really cool, and right now my efforts are focused on making it even more powerful (atomic operations). At the same time, it really sucks for key operations like cropping, trimming, and adjusting levels.

I think a good GUI is beyond the capabilities of any single person -- VDub might be a counterexample, but (1) Avery's smarter than us (2) our application needs to be more complex, and not take 5 years to get there. Thus we run into the problem of coordinating efforts across the Internet, for which there's no good solution (especially when everyone thinks their individual ideas are best ;)). Moreover, the "big guns'" (or at least my) expertise is with raw C++; my knowledge breaks down when it comes to interfacing with the Windows API, which only comprises about 5% of Avisynth but more like 90% of a GUI.

[stickboy]

One problem I have with a separate database, centralized or not, is keeping versions in sync.

What happens if different versions of a plug-in have filters that take different arguments? Would the database keep track of them all? Would the user need to figure out exactly which version they have to determine what to download? Would only the latest version of a plug-in be supported?

Keeping everything in sync seems like extra work for the maintainers and extra steps for the end user. I think this sort of thing needs to be bundled with the plug-in itself.

Originally posted by Richard Berg:
plugins could add additional DLL exports but a GUI would have to autoload them directly (not through AVS)That's what I had in mind.

[Richard Berg]

Doesn't help internal filters, without major changes.

[stickboy]

If the internal filters are a problem, then they might warrant another mechanism. They don't change much anyway.

For the internal filters, what if avisynth.dll provided a single, public dispatch function that takes the name of an internal filter as an argument, generates an appropriate dialog, and returns the corresponding string?

[Richard Berg]

That counts as "major changes" to me. More specifically, changes that are beyond my current abilities.

[Bidoche]

@stickboy

I don't think it's appropriate for the core to concern about dialogs, a plugin maybe...
Besides who will do them ? We don't have a GUI guru in the core team.


For 3.0, I was thinking about about another virtual member in the AVSFunction class :
virtual string GetXMLDescription() = 0;
And have a method in the COM ScriptEnvironment wrapper to get them


@Richard Berg

user_data are used by script functions, I don't remember exactly for what (the expression graph of the function, maybe)

[WarpEnterprises]

What happens if different versions of a plug-in have filters that take different arguments?

That should not be a problem, especially in a database.
We had to agree to a proper unique key (e.g. function_name + version_date), and a database design with function versions (I mean being able to enter that version 3.1 is the same as version 2.87 except the additional entries).
In the XML format it seems nice to implement such hereditary information.

In any app using the XML there should be a check for the right version (and the date of the DLL is really good for this as I saw in my filter collection).

[stickboy]

Originally posted by Richard Berg
That counts as "major changes" to me. More specifically, changes that are beyond my current abilities. Well, it'd certainly be a major addition. I wouldn't expect that it would break anything or require much changes to existing code...
Originally posted by Bidoche
I don't think it's appropriate for the core to concern about dialogsThat's a good point. Hmm.

WarpEnterprises, what interaction would the end-user need to have with the database?

[MrTibs]

I've been throwing around the idea of a GUI capable editor for Avisyth for some time. What I imagined was a text editor that popped up a user designed dialog box when double clicking on a filter name.

The filter configuration dialog boxes could be designed either inside the application or in a seperate application with the dialog layout parameters being saved to a standard text file (XML, ini style...). These dialog box templates could be uploaded to a site [by users or filter writers] for anyone to download. This way, any user could download their favorite version of the configuration dialog box. They could easily design their own for any filter [internal or external] or write a dialog for their own Avisynth macro.

Each dialog box could use the built in dialog box objects but could also load DLL's with dialog components (dropdown lists, fancy buttons,...).

If we added the idea of wizards on the same design principals, well...

[Richard Berg]

One issue that's come to mind every time I think about GUIs is updating a preview window. Right now, the only way to draw new images in Avisynth (eg in response to dragging a slider) is to re-render the entire filter graph, which probably wouldn't provide the performance we'd like.

[MrTibs]

Yea, that is a limit. My "vision" wouldn't be dynamic in that way. The filter developers could provide an object dll to simulate that feature but that is more work for them. As a poor work around, the dialog box could have a standard "Preview" button that would open the modify and load a copy of the script into a viewing window using the view filter. This would hardly be dynamic but still quite a bit better than what we have now.

On the DLL object idea, since most plugins have a standard format (by default), a "Dynamic" preview object template could be written. A junior developer like me could cut and paste the filter's source into this template and compile. Voila, a dynamic preview object. (Perhaps a wizard would be better here)

On the other hand, if a very simple viewing program was written that could call avisynth filters, it could be used to respond dynamically.
(i.e. no sound, shows single frames only, no internal filters, no scripting - just load frame->load fitler with params>process frame->show frame)

If course this could "break" filters that use internal filters to do their work.

[neily]

Are we getting a bit ahead of ourselves? Whatever form the filter data takes (seperate file, database, dll export) isn't the first concrete step we can take to decide on whether it is an idea genuinely worth pursuing , and secondly a naming convention and what information to include?

On the point of form, I would still vote for a seperate file, as it could apply to existing dll's that are no longer in development. It would be relatively easy then to develop a small app that scans a plugin directory, and builds a database, presenting all the relevent info in a compact but comprehensive form. Sometimes this is all you need rather than having an editor, preview, and help file all open on screen at the same time. This is sort of how AVISynthEditor works, and it for what it sets out to achieve, works quite well.

[esby]

The idea crossed my mind some times ago,
but what about filters dedicated to variables.

The main problem of some filters is to tweak their parameter efficiently...
Eg: I almost never use tweak() because it is a pain to setup it...
when i can do the same using Hue/Saturation/Intensity in vdub
and load the plugin in avs with the settings i want...

Now the idea,
myvar = myfilter('myVariableName',defaultValue=1)
blur(myvar)

Then we could have an appplication that would:
Preview the clip,
Allow to change the variable value pointed by 'myfilter' maybe via a trackbar
Redraw the frame (or recall it) if some variable monitored got changed etc.

Of course the main problem being if i am right that the variables
are only evaluated once in avs(Is that still right or ever been?)

A filter modifying variables could allow more complicated application to be created without too much interaction with the avs 'kernel',
we could imagine an intelligent GUI handling an avs script and creating the items associated with each filter automatically.

esby

PS: 'myReferenceName' should be for referencing the var inside the application checking its state,
allowing multiples changes of a same var name,
eg:
myvar = myfilter('myVariableName1',defaultValue=1)
blur(myvar)
myvar = myfilter('myVariableName2',defaultValue=1)
blur(myvar)
there you could tweak the first blur with a given value and the second one with another one, and have two sliders to modify the values.
the full syntax could be :
myfilter('myVariableName',default,min,max,step)
PS2: edited - was refering to Hue/Saturation/Intensity and not HSV, since this one is an internal vdub filter.

[neily]

Having gone away and done a bit of reading about XML, an XML descriptor doesn't seem to be a bad idea, but as a first step does an "officially sanctioned" DTD need to be designed/agreed upon?

[WarpEnterprises]

What's DTD?

Quite important to me seems the scope of the GUI. There are 3 levels coming to my mind:

1) text-editor with features like those already present (syntax, parameter info, context help,...)

2) visual building the filter graph. much more demanding, as there should be checks on the result and the input of the functions

3) considering the (non-linear) timeline with thumbnails,...

[stax76]

What's DTD?


that's the advantage not knowing english very well, you have always to run Babylon in the background, it tells "document type definition"

[WarpEnterprises]

And this is the common syntax/structure of "our" XML?
maybe you have a nice XML link at hand...

[stax76]

I'm not a expert here, I worked not even more than 3 hours with a XML like "language" so far, only thing I know XML is very popular nowadays for dealing with structured data so I used it to create the filter descriptions for DVX in a simple fashion without using attributes, I thought this way the files would be easier to parse.

[neily]

And AVISynthEditor uses XML for filter descriptions. I have myself only spent a few hours reading up on XML and associated tools after Richard (Berg) suggested it.

Rather than individuals having to reinvent the wheel, why not have an agreed (but extensible) descriptor format (a DTD by my understanding). That way, it would help plugin writers, as it would provide a framework starting point for documentation, the most tedious part of plugin writing after debugging I would imagine. It would also help anyone writing ancillary programs, as much neccessary information would be easily parseable rather than having to be manually entered and updated.

In the first instance, it would be nice to see a compact application that could scan a plugin directory and tell you what plugins and versions you have, their syntax, ranges etc, without having to have numerous help files simultaneously displayed.

Though starting from a point of near zero knowledge, I could invisage doing something like this myself, but a) it would be a lot of work to write the xml files as some plugins aren't terribly explicit about such things as ranges, and b) it would be good to do it in a consensual way rather than unilaterally.

Umm, I can feel AVSAssistant v0.0.0.1 coming on.

[stax76]

I don't know the difference between DTD, XML scheme, XML structure etc., so I will use DTD in my following explanation

again, there is already a large amount of xml filter description files shared by AviSynthEditor and DVX, there is a full featured visual editor to create and edit the XML files build in in DVX and a standalone editor is currently developed by Dark-Cracker, so you would indeed reinvent the wheel. Of course it's good to have several applications but the DTD should be same. Before I started to work on this there were a lot discussions something to describe the filters is required but there was never much more than discussions and since I needed something to discribe the filters for the AviSynth script editor I was coding I took the opportunity to create a DTD. I don't know how good or bad the DTD is which is currently in use because when I created it my knowledge of AviSynth and XML was rather poor (and still is), the current DTD is quite simple and straight forward. The only thing missing I'm aware of are the colorspaces, could look somethink like this:


<Plugin>
<Filters>
<Filter>
<Colorspaces>
<Colorspace>YUY2</Colorspace>
<Colorspace>YV12</Colorspace>
</Colorspaces>
</Filter>
</Filters>
</Plugin>


I would be more than happy somebody is willing to do some work on this topic because I'm not planning to do any work on AviSynth related things at all in the near future. Of course I would be happy the DTD don't has to change much so I don't have to change my code much

[mf]

I've had an idea for this for some time as well. I've drawn it out here: http://nabeshin.ddo.jp/vdubmod_avs_easy_n00b_script_editor.png
This goes slightly beyond what you guys are thinking about (my idea was to have two interfaces, one with syntax simplification as shown in my concept art, and the other one as just an editor with syntax highlighting and filter properties like you're talking about, activated by the little notepad with wheel icon), but still it could be a nice idea? :D

[morsa]

Well MF's style with an associated preview window should be enough, isn't it?

[Belgabor]

The problem I see with mf's version is that this will give people the impression of writing valid avisynth scripts while in truth its some heigher level pseudo-code that gets translated to the real thing by the app. In my opinion there should be only two possible GUI/editor versions, a basic text based one (with possibly a lot of doodads, like dialogs for filters, syntax highlighting etc.) and a full graphical one, primarily completely detached from the actual script.

About the descriptions. I'm against a central database. Lets be realistic, its probably out of date for the filter you currently need. In my opinion this is an option for filters out of development. New filters should export a function that works like what Bidoche defined for 3.0, call it and get an description in xml. A separate file should also be an option for said filters out of development but should be discouraged for active development. Therfore it would be really nice to centralize this function via AviSynth which filles some accessible varable with, depending on availability

the xml data from the filter function
xml data from a file
educated guesses from the filter interface (eg what type of variables the filter expects)

[WarpEnterprises]

would it be possible and useful beeing able to get the clip/var values of each intermediate var?
Then in the text editor could be added not only syntax checks but also smarter checks for validity (dimensions, colorspace,...)
(Maybe some way to get the error asserts and more back in the editor)

And since the slowest thing is the opening of a source would there be a way to make this faster so a prewiev of a new filter chain is faster?

[sh0dan]

Previewing could be made considerably faster by writing a "preview" plugin.

It would be a plugin that invokes the filter currently being adjusted. That would make the filter chain static, as long as settings for one filter is adjusted.

Information would of course then have to be sent from the application to the preview plugin.

[Bidoche]

In 3.0, I use DescriptionPrototype objects to provide prototype info.
For internals they are hardcoded, but for plugins, i was planning to import an xml description from somethere and make them up from it.

It would be the same description that would be passed up to a GUI for him to use.


About previewing, repeated invoking may be slow and not very effective in some cases, so we may want to design an advanced system for filters to be tweaked in place when it makes sense.

Maybe something like that (in Clip):
virtual vector<string> GetTweakableParamsList() = 0; //return list of params we can play with
virtual AVSValue GetValue(const string& param) = 0;
virtual void SetValue(const string& param, AVSValue value) = 0;
virtual string GetSourceText() = 0; //return source text to produce the clip...

[neily]

Wherever a description may come from, what work has been done on setting an agreed standard for the description? As for whether xml information would become out of date, I would encourage distribution with the dll. If one of the fields was a dll CRC or filesize, then it would be possible to autocheck that the description was appropriate for the dll. I am in 2 minds as to whether dll/help file names should have an appended version number, which would be an alternative. Sometimes it is a help, sometimes it is a hindrance.

[WarpEnterprises]

a true version number seems too much for me.
There is only the need to check if the description is suited anymore.
So the best would be indeed that the filter itself exports the description, then it can't be out of date.
For the helpfile the date of the DLL should be quite unique and more readable than a checksum (or am I wrong?)

[zyrill]

isn't discussing this matter irrelevant if most filter-author do not want to add some XML exporting function? some basic "market" research should be done before agreeing on a format - if people don't mind writing those extra 50 or so lines and do some layout coding using xml then there we have our standart.
the other possibility is to make the xml-exporting function a requirement for avisynth 3.0 - easy as that - just like plugins have to be slightly adjusted for 2.5 they'll have to incorporate those gui-funtion.
either way: i think it's time to think about what information needs to be stored in xml and what options should be made available. a DTD is the right way i believe and to give a push in the right direction here's a link to a DTD tutorial: http://www.w3schools.com/dtd/default.asp as a very good example to start working on i can recommend USF which is a subtitle format based entirely on XML... ( http://usf.corecodec.org/ ) - just download the .zip containing the specification here ( http://usf.corecodec.org/usf-specs.zip )

[sh0dan]

@zyrill: You are not going to have an easy time convincing authors to do extra work.

Even though 2.0 -> 2.5 only required very small changes, it took ages for some devs to take the 30 mins required to do a 2.5 version. Getting them to understand/write XML might take even longer.

[Bidoche]

the other possibility is to make the xml-exporting function a requirement for avisynth 3.0 - easy as that - just like plugins have to be slightly adjusted for 2.5 they'll have to incorporate those gui-funtion This is what I planned, but I don't see these exports as gui fonctions.
I use them to document plugin functions for the linker to work, being usable by guis is just bonus for me.


Anyway, in my mind, gui developpers wouldn't have to use them. They would use an env from avisynth and ask him what he knowns about the world (and eventually make it load plugin).

[Kurosu]

Originally posted by sh0dan
@zyrill: You are not going to have an easy time convincing authors to do extra work.

Even though 2.0 -> 2.5 only required very small changes, it took ages for some devs to take the 30 mins required to do a 2.5 version. Getting them to understand/write XML might take even longer.
Absolutely true. In my case, dealing with framework is a waste of time until I reach the part where a new idea is implemented.
I do hope a limited but simplier interface will be available for those like me who aren't very interested in OO programming. I haven't checked, but on the other hand, a DCOM-like interface would make AVS x(x>3.0) backward-compatable with filters written for AVS y (y<x and y>3.0).

The C interface written by Kevin Atkinson is an example of such alternative possibility, and also shows that people aren't likely to often learn APIs. That's why I didn't want to deal with the Intel/GCC intrinsics either. The more you force people to deal with an API, the less motivated they will be to work on it until they reach the part where the processing is done. And this even if the API is really powerfull.

[Bidoche]

3.0 is supposed to expose all relevant classes as COM objects, in order to establish backward compatiblity from this point.
For now, no work has been done on it (I am not a COM guru), any help is welcome.

[Si]

@sh0dan
I think 30 mins once it was worked out that you needed to include more than Avisynth.h to get the plugins to compile at all :)

And I personally felt that you "encouraged" people to make they filters handle YV12 (which took us at least another 5mins :) )

And we're not all core developers you know - some of us play in the second string section :p

regards
Simon

[WarpEnterprises]

That was why I came up with a central database idea, but equally good would be a way that other than the DLL-author can create such a description and publish it (there are many around that don't program C++ very well but do other valuable assistance...)

[Bidoche]

I don't think people really need help to write something like this :
<Function>
<Name>MyFunction</Name>
<Prototype>
<Return>Clip</Return>
<Argument>
<Name>c</Name>
<Type>Clip</Type>
</Argument>
<Argument>
<Name>value</Name>
<Type>int</Type>
<Default>0</Default>
</Argument>
</Prototype>
</Function>

A couple examples should be enough.
They already had to provide this information before, this is just a change of the format.

[temporance]

Originally posted by Bidoche
They already had to provide this information before, this is just a change of the format. If the information has been provided before, then surely it should be an automated process to generate the XML?

[Bidoche]

Yes, the automated process is to take your brain in one hand, and your keyboard into the other and translate "cci" into that...

In fact, it can't really be automated, the xml provide more info, names for all args, even not optionals (just added them, I forgot before) and eventual default values.

Defaults being passed there make it the work of the parser to regenerate them, which I believe is a simplification for developpers.

[temporance]

I guess I'm just a stickler for tidiness! Relying on someone to input the same data in different place is error-prone, especially when someone makes changes down the line. In an ideal world, you'd also have the documentation generated automatically, at the same time and from the same original data, as the XML!