Getting stuff included with the main AviSynth distribution?

[stickboy]

(or: Who does he think he is? The nerve!)

Just when I thought my SelectByString (http://www.avisynth.org/stickboy/SelectByString.zip) plug-in was as simple as a plug-in could get, I wrote a plug-in to provide variable-argument Min and Max (http://www.avisynth.org/stickboy/MinMax.zip) functions. (Behold the culmination of my AviSynth abilities! Yeah, I suck.)

Anyhow, I was (egotistically) thinking that these sorts of functions--functions that aren't likely to change much and that (hopefully) provide some utility to script-writing in general--might be good to include in the AviSynth distribution (either directly or as separate plug-ins).

It also might be useful to bundle some user-level functions (maybe my Trim2/Trim3, NullClip, and SetParity functions) to get them into the standard lexicon.

Would doing so be worthwhile? Or would it be unnecessary bloat?

[Richard Berg]

I'm a bit leery, but I realized if we want the nice properties of your wrapped functions the only other option would be to change Trim() et al., which is not acceptable for compatibility. We're already moving to include standard plugin-directory items like DirectShowSource, so let's see what others think.

[Bidoche]

I am thinking about providing strickboy Trim behavior in 3.0.

For leagacy purpose the old behavvior could be optained through overload and an appropriate avsi file (or a parser directive ?)

[stickboy]

Originally posted by Richard Berg
I'm a bit leery, but I realized if we want the nice properties of your wrapped functions the only other option would be to change Trim() et al., which is not acceptable for compatibility.There shouldn't be any compatibility problems; I don't want to replace anything. I think Trim is perfectly fine as it is for the way most people use it (e.g. Trim(5158, 14825)). The only big problem is when it's used in functions that are meant to be reusable--cases where the end-points aren't known ahead of time. Those are the cases that Trim2 and Trim3 are meant to address, and those are the cases where the clumsiness of the functions' names plays less of a role.

Unfortunately, those are also the cases where code is likely to be shared, so now there's a dependency issue. Anyone who wants to share a function that uses Trim2/Trim3 needs to add, "Oh, go to stickboy's page, download this file, blah blah blah." (Or, since I PD'd all my stuff, they could copy and paste the functions directly, but then there's a maintenance problem.)

It would be cool, though, if they (and specifically SelectByString and Min/Max, which are what I'm focusing on) could be bundled with the distribution, if everyone's willing and has no objections. My goals are to try to enrich the language and to make it easier for other people to write their own scripts.

BTW, on a completely separate topic: I am quite pleased (and rather surprised) that AviSynth handles function overloading. I was worried that user-defined Min/Max functions of two arguments would conflict with variable-argument versions, but they don't. :)

[esby]

How about defining an autoImport for avsi file that could be in plugin Directory?

Or maybe in an avsi dedicated directory...
And including the shared function in the distribution
That might be a workaround solution to port 'script' function
in the distribution...

esby

[Richard Berg]

There shouldn't be any compatibility problems; I don't want to replace anything.
I know. I was looking at it from the opposite perspective, "I want these new features, but can't change the core," making your suggestion look like a good one.

esby - How would your AutoImport differ from current .avsi autoloading?

[esby]

@richard berg

Good question :)

I never used it actually, (blame me for not knowing it).
I do all my import and plugin load by the hand.
If my suggestion is already 'implemented' forget what i said...

esby

[Richard Berg]

After some time to ponder, here's what I think:

Not yet. Adding functions to the popular lexicon has always worked more democratically than anything. Examples like Decomb tell us that great documentation and frequent posting can help, but ultimately people will use what they see others using. Besides, adding to the core won't help -- my guess is most people don't read the packaged docs, else we'd get more bug reports about PeculiarBlend.

And when we do add them: they should be prepared to be treated as equals to built-in functions. New users need not know the difference at all if autoloading works correctly and example scripts are provided intelligently. For everyone else, their documentation should be alongside the other functions, built into the html and chm files, with according standards.

(comments welcome)

@esby, you should try autoloading, it's invaluable

[stickboy]

Originally posted by Richard Berg
Not yet. Adding functions to the popular lexicon has always worked more democratically than anything.Fair enough. (That's why I'm asked.)Besides, adding to the core won't help -- my guess is most people don't read the packaged docs, else we'd get more bug reports about PeculiarBlend.I don't follow. I read the docs and don't file bugs for PeculiarBlend because I've never used it and probably never will. :)

Adding to the core still could help people who don't read the docs, though; it'd make it easier for others to share scripts with them.

Of course, going back to the democracy thing, I suppose that there probably is not enough interest/demand to make it an issue. (AFAICT my UnfoldFieldsVertical/FoldFieldsVertical functions are more popular than anything else I've written. Alas.)

(To any thread lurkers: if you have an opinion, say something!)And when we do add them: they should be prepared to be treated as equals to built-in functions. New users need not know the difference at all if autoloading works correctly and example scripts are provided intelligently. For everyone else, their documentation should be alongside the other functions, built into the html and chm files, with according standards.I agree; whether functions are provided as built-ins, plug-in DLLs, or auto-imported scripts should be transparent.

[DDogg]

Stickboy, I wonder if the Advanced Script Writers (ASWs) could work together and somehow consolidate the work so that it is more accessible to the average user?

For democracy to work the average user needs better access to the final approved versions of these advanced scripts and functions. Presently, as so many are works in progress, it is difficult to find the finished jewels. They are scattered about in multiple threads, web pages, etc. I believe this work could quickly become more used, and democratically acknowledged, if it could somehow be cataloged with short descriptions and suggested quick start instructions.

Whether this would be done in a sticky, avisynth reference page, or on an offsite webpage, I don't know. All I do know is that it is needed so please consider it.

Btw, the ASWs (you know who you are) are a huge asset to this community. I'm sure I can speak for all of us when passing on thanks and appreciation for this important work.