Question about AVISource

[jollye]

Hi,

Maybe this question has already been asked? Why is this not fully supported:

clip=AVISource("myscript.avs")
return clip

I've noticed it seems supported however if in myscript.avs there is the same kind of construction, an exception related to the file opening can occur.

Could this been fully supported in the future?

[mikeytown2]

Use Import() for scripts
http://avisynth.org/mediawiki/Import

[jollye]

Hi,

I know that. Sorry for not clearly stating that I was not asking for a solution but rather asking for explanations.
This was just a question to know the reasons why this doesn't work.

Suppose you're working and testing some scripts and then you want to add the results of the scripts together. This would be very convenient. I must admit this is a problem only if we use the return syntax within the script. Otherwise it should work fine with import.

[jollye]

I've just checked AviSynth's documentation and this seems to be supported whereas I have problems when using it.

AVISource takes as argument one or more file name in quotes, and reads in the file(s) using either the Video-for-Windows "AVIFile" interface, or AviSynth's built-in OpenDML code (taken from VirtualDub). This filter can read any file for which there's an AVIFile handler. This includes not only AVI files but also WAV files, AVS (AviSynth script) files, and VDR (VirtualDub frameserver) files...

Does anybody have clues on this subject?

[kemuri-_9]

I must admit this is a problem only if we use the return syntax within the script. Otherwise it should work fine with import.
why do you have return in the script?
it's unnecessary to have return at the end and having return in the middle of a script is bad practice ('unreachable code')

so you should never realistically have a reason to not be able to use import() on another script

[IanB]

Sourcing secondary scripts is supported but I strongly recommend avoiding the practise.

Doing so causes multiple instance of Avisynth to be loaded within the process with the associated waste of memory.

Import() is the weapon of choice here.

[stickboy]

I disagree. It might be wasteful, but I think AVISource is more correct in principle.

Using Import seems like #include to combine .c files rather than using a linker.

[Gavino]

I must admit this is a problem only if we use the return syntax within the script. Otherwise it should work fine with import.
I don't get your point here. Import returns a value from the imported script, so it can be used with 'return' just the same as AviSource.

In all contexts where AviSource("xxx.avs") can be written, it can (and should, for reasons explained by IanB) be replaced by Import("xxx.avs").

[jollye]

@Gavino
I don't get your point here

Sorry for reviving an aged thread just for the sake of the discussion.

Except if I'm missing something, when you use import to import an avs script ending by return, then the parent script (where the import "test.avs" line is present) will simply finish when it reaches the return line of the imported clip whereas with a syntax not using return this would not occur.

Do you agree?

[neuron2]

Do you agree? No. Here's proof:

rat.avs:

dgsource("rat.dgi")
return last

import.avs:

Import("rat.avs")
tweak(sat=0)

Opening import.avs shows a grayscale image.