Vapoursynth

[asarian]

Originally Posted by Myrsloik

No, there's no way to silence them.

That's too bad. (R57 never had this) But I'll live. And thanks for the great VS tool!

[Myrsloik]

Originally Posted by asarian

That's too bad. (R57 never had this) But I'll live. And thanks for the great VS tool!

If there's actual popular demand I could add a silent option. So reply to this if you care.

[asarian]

Originally Posted by Myrsloik

If there's actual popular demand I could add a silent option. So reply to this if you care.

For the record, I care.

Reason I'd love to see a silent option, is because many scripts keep importing the stuff everyone else imports too; so the VSPipe output almost always starts with a sheer endless barage of WARNINGS (none of which I can resolve myself, mind you, short of editing all side-packages individually).

[Z2697]

Originally Posted by asarian

For the record, I care.

Reason I'd love to see a silent option, is because many scripts keep importing the stuff everyone else imports too; so the VSPipe output almost always starts with a sheer endless barage of WARNINGS (none of which I can resolve myself, mind you, short of editing all side-packages individually).

It should have nothing to do with the packages, it's for duplicated plugins. Unless the package ships with plugin included and calls std.LoadPlugin to load it in side the python code, which I haven't seen one like this.
The better thing to do is check and remove duplicates your auto load folder, or clear your script (from std.LoadPlugin) or auto load folder (completely rely on std.LoadPlugin)

[amayra]

is it not possible to have plug-in that run every platform and architecture ?

just like some mods in games

[LigH]

Only if they are written in an architecture-independent programming language. Like, in Python; but not in C/C++ which would create CPU dependent byte code. But that would be faster. CPU dependent binary plugins can be optimized for speed using SIMD instructions (like SSE or AVX on intel x86-64 architecture). Plugins in an interpreted script language will always be less performant.

[Selur]

@Myrsloik: Question regarding "https://www.vapoursynth.com/doc/installation.html#os-x"
Can there be only one 'UserPluginDir' or can I (how?) specify multiple dirs with plugins?
In case, there can only be one: "Feature request: Please support multiple user dirs. "

Cu Selur

[Myrsloik]

Originally Posted by Selur

@Myrsloik: Question regarding "https://www.vapoursynth.com/doc/installation.html#os-x"
Can there be only one 'UserPluginDir' or can I (how?) specify multiple dirs with plugins?
In case, there can only be one: "Feature request: Please support multiple user dirs. "

Cu Selur

GOOD NEWS EVERYONE!

I've now beaten the frivolous spam allegations and can once again answer you questions.

Why do you need multiple dirs? Why isn't LoadAllPlugins good enough? If you have a sane workflow that needs it maybe I'll add it.

[ChaosKing]

I always wanted either a custom dir with loading priority or simply the ability to unload a plugin.

In case of FrameSeeker https://forum.doom9.org/showthread.php?t=176231, I could use it to test the source filter installed by the user or test an "external" source filter without Appdata dll copy/delete/rename hacks.

[Myrsloik]

Originally Posted by ChaosKing

I always wanted either a custom dir with loading priority or simply the ability to unload a plugin.

In case of FrameSeeker https://forum.doom9.org/showthread.php?t=176231, I could use it to test the source filter installed by the user or test an "external" source filter without Appdata dll copy/delete/rename hacks.

Unloading is quite unlikely to happen since it's very complex and generally not required/a good idea.
If you want to load multiple different copies you have the secret arguments forceid and forcens in LoadPlugin to override a plugin's unique id and namespace which will let you get around the unique requirement.
Maybe that's helpful. Please only use this for testing/development or I'll have to kill you all.

[ChaosKing]

Originally Posted by Myrsloik

Unloading is quite unlikely to happen since it's very complex and generally not required/a good idea.
If you want to load multiple different copies you have the secret arguments forceid and forcens in LoadPlugin to override a plugin's unique id and namespace which will let you get around the unique requirement.
Maybe that's helpful. Please only use this for testing/development or I'll have to kill you all.

Finally the secret knowledge is mine!

I use windows, I was killed by Bill long ago

[asarian]

Originally Posted by Z2697

It should have nothing to do with the packages, it's for duplicated plugins. Unless the package ships with plugin included and calls std.LoadPlugin to load it in side the python code, which I haven't seen one like this.
The better thing to do is check and remove duplicates your auto load folder, or clear your script (from std.LoadPlugin) or auto load folder (completely rely on std.LoadPlugin)

My bad. I had installed R70, after a thorough cleanup, as there were many stubs left of various Python and VapourSynth versions. Apparently there was still one of those 'stubs' left for a plugins dir in AppData somewhere.

'Care' withdrawn, as the issue is resolved now.

[Selur]

Why do you need multiple dirs? Why isn't LoadAllPlugins good enough? If you have a sane workflow that needs it maybe I'll add it.

Would be useful on to load for example the plugins installed by homebrew and https://github.com/yuygfgg/Macos_vapoursynth_plugins and maybe vsrepo on MacOS.
Not really much of a problem.
But you are right LoadAllPlugins (https://www.vapoursynth.com/doc/func...llplugins.html) should work fine. I simply wasn't aware of it.

Thanks!

Cu Selur