v3.7.3 r4003 - TimeStretch does not have a named argument "rate"

[FlintEastwood]

The TimeStretch filter is broken. It doesnt recognize the arguments tempo, rate, pitch.
I always get the message:
TimeStretch does not have a named argument "rate"

The integer arguments like "rate_n", "rate_d" are still recognized.

Or are the arguments tempo, rate and pitch depreciated but the doku has not been changed?

[pinterf]

TimeStretch still has two different versions. How to read: type characters 'i'=integer, 'f'-floating point, they follow [parameter_name].

c[tempo]f[rate]f[pitch]f[sequence]i[seekwindow]i[overlap]i[quickseek]b[aa]i
and
c[tempo_n]i[tempo_d]i[rate_n]i[rate_d]i[pitch_n]i[pitch_d]i[sequence]i[seekwindow]i[overlap]i[quickseek]b[aa]i

It seems to me if you'd provide floating point for rate and floating point for the preceding tempo (and not tempo_n), it would recognize?

Provide please your calling line.

[FlintEastwood]

I used this line:

TimeStretch(rate=100.2059891)

Is that wrong?

[pinterf]

Works fine on my system. r4003 was the 3.7.3 release, and I used the bundled TimeStretch.dll

Colorbars()
TimeStretch(rate=100.2059891)

There must be another TimeStretch.dll on your system. Download AVSMeter64.exe (for 64 bit systems) and run it with the avsinfo option, it will list all your plugins and dates and versions.

My version:
C:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll [2023-02-23]

[FlintEastwood]

Your version is older. It is not the version shipped with the 3.7.3 installer.

64 bit:

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021

VersionString:              AviSynth+ 3.7.3 (r4003, 3.7, x86_64)
VersionNumber:              2.60
File / Product version:     3.7.3.0 / 3.7.3.0
Interface Version:          10
Multi-threading support:    Yes
Avisynth.dll location:      C:\Windows\SYSTEM32\avisynth.dll
Avisynth.dll time stamp:    2023-07-15, 22:48:08 (UTC)
PluginDir2_5 (HKLM, x64):   C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+   (HKLM, x64):   C:\Program Files (x86)\AviSynth+\plugins64+


[C++ 2.6 Plugins (64 Bit)]  [Version, Time stamp]
...
C:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll  [n/a, 2023-07-15]
...

32bit:

AVSMeter 3.0.9.0 (x86), (c) Groucho2004, 2012-2021

VersionString:              AviSynth+ 3.7.3 (r4003, 3.7, i386)
VersionNumber:              2.60
File / Product version:     3.7.3.0 / 3.7.3.0
Interface Version:          10
Multi-threading support:    Yes
Avisynth.dll location:      C:\Windows\SysWOW64\avisynth.dll
Avisynth.dll time stamp:    2023-07-15, 23:00:38 (UTC)
PluginDir2_5 (HKLM, x86):   C:\Program Files (x86)\AviSynth+\plugins
PluginDir+   (HKLM, x86):   C:\Program Files (x86)\AviSynth+\plugins+


[C++ 2.5 Plugins (32 Bit)]  [Version, Time stamp]
C:\Program Files (x86)\AviSynth+\plugins+\equlines.dll  [0.3.0.0, 2025-02-06]

[C++ 2.6 Plugins (32 Bit)]  [Version, Time stamp]
...
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll  [n/a, 2023-07-15]
...

[qyot27]

What application are you using to open the script when you see the parameter errors, and who built it?

[FlintEastwood]

I nailed down the problem a bit more.
It is NOT application dependent. It happens with VirtualDub, AVSPmod, MPC-HC, etc. .
It is a problem with the 3.7.3 TimeStretch.dll's.
I wrote a short test script, that didn't crash:

ColorBars(width=720, height=576,pixel_type="YV24")
TimeStretch(rate=100.209)

But that is not the usual way I'm writing avisynth scripts. My scripts look like this:

cv = ColorBars(width=720, height=576,pixel_type="YV24")
cv = TimeStretch(cv, rate=100.209)
return cv

And that script crashes. I tried this on a second PC with a fresh 3.7.3 install and it crashed there too.
That is the error with my video script:

But now the best:
If I'm using the TimeStretch.dll's from the 3.7.2 release (2022-03-18), then I don't get the error:

[pinterf]

Getting interesting... I tried the files from both the plain x64 and the XP versions, and I didn't encounter any issues. Could you please upload your DLL somewhere so I can take a look?

[FlintEastwood]

I can't believe, that I'm the only one having this problem.
I tried a third PC today and running into this issue!
All three PC's are using a german Win10 64bit 22H2. Two of them Pro and one Home.
I downloaded the installers on each device separately, so it should not be a transmission error.

Use one of those installers and do a clean Avisynth+ install (I selected german, but should this make a difference?):
https://github.com/AviSynth/AviSynthPlus/releases/download/v3.7.3/AviSynthPlus_3.7.3_20230715.exe
https://github.com/AviSynth/AviSynthPlus/releases/download/v3.7.3/AviSynthPlus_3.7.3_20230715_vcredist.exe

Use this script and it should throw the error:

cv = ColorBars(width=720, height=576,pixel_type="YV24")
cv = TimeStretch(cv, rate=100.209)
return cv

[pinterf]

Yep, using the installer, I got the error message.

[pinterf]

I have installed the non-vsredist version, choosing German
Seen the bug
Reinstalled, English
Still "no named param"
Copied over the today compiled avisynth.dll
Error.
Copied over an actual TimeStretch
Error.
Uninstalled AviSynth, reinstalled English
Copie over the latest dlls. Still error.
Not I'm unable to go back to a working version :) (and :( )
All because I chose German for the installation? I admit, this requires Mr Poirot.
EDIT: or just never tried exactly the same cv. syntax

[FlintEastwood]

I don't know another syntax way to work with multiple clips. So I use clip variabes like cv, ca, c1, c2, etc. .
But it makes me a bit calmer now, that you can reproduce my issue.

[pinterf]

It seems to be a special unhandled case when a function has multiple forms and the core is trying to find out which one to choose from the possible variants. It tries with and without putting 'last' as the first implicite parameter and then looking into the oop variants as well (oop is the clipvariable.function() format).

I see the problem, but it's too difficult for me to fix it at the moment.
So let's leave open this ticket.

This part is quite complex, don't expect the solution within a very short period.

Thanks for the report.

[qyot27]

My gut reaction before the latest comments would have been that it might have something to do with MBCS...but that was changed long before 3.7.2. Since it seems to have some correlation to the codepage, it might still have some connection to MBCS, but probably in a more 'happened during utf-8 conversion loop' way.

If it is connected, it may be worth checking whether enabling system-wide UTF-8 fixes it.

Come to think of it, I don't think there is any way to list all functions with their parameters, which would have honed in on this quicker than it did. I know that there was some sort of script that StainlessS over on Doom9 used (and probably used it on the source code itself) to yank out that info for documentation changes, but I don't think there is any mechanism to do this inside the core. VapourSynth (or maybe it's the Python layer) does have this capability in the form of core.list_functions().