Avisynth 2.6 Trim not working in function script

[goorawin]

Since installing Avisynth 2.6 (version 130918) Script error :invalid arguments to function "Trim", occurs.
The line in question in an avsi script is:
mclip = Trim(source, startFrame, endFrame)
In Avisynth 5.8 it worked fine and even reinstalling 5.8 it still works.
So what has changed and what arguments will work in 2.6?
Thanks in advance

[Reel.Deel]

The line in question in an avsi script is:
mclip = Trim(source, startFrame, endFrame)


It'd be nice to know what script you're talking about.

[goorawin]

The script is a ramped slow motion one that comes in handy at times. Which is:

# Gradually slows a clip down
function Slowmoe3(clip source, float startFrame, float endFrame, float startRatio, float endRatio)
{
# Get the clip's original framerate
mfpsn = FramerateNumerator(source)
mfpsd = FramerateDenominator(source)

# Convert and trim clip
mclip = Trim(source, startFrame, endFrame)

# Flip frames
GScript("""
if (endFrame < startFrame) {
temp = endFrame
endFrame = startFrame
startFrame = temp
}
""")

# Do the MVTools SlowMotion
super = MSuper(mclip, pel=2)
backward_vec = MAnalyse(super, isb=true)
forward_vec = MAnalyse(super, isb=false)
slowdown = MFlowFPS(mclip, super, backward_vec, forward_vec, Round(mfpsn * 1.0/endRatio), mfpsd)
slowdown = AssumeFPS(slowdown, mfpsn, mfpsd)

# Initialize values
startFrames = (mfpsn * 1.0/startRatio)/mfpsd # Starting frames in a second
endFrames = (mfpsn * 1.0/endRatio)/mfpsd # Ending frames in a second
framesRange = endFrames - startFrames # Difference in frames
currentFrame = 0 # The current frame in the final clip
counter = 0 # The total frame counter
lastFrame = Framecount(slowdown) # The total frames in the slow mo clip
desiredFrames = 0 # The current desired frames
removeFrameCounter = 0 # The frame removal counter
removeFrameThreshold = Float(endFrames)/Float(startFrames) # The number of frames to remove
overflow = 0 # Overflow from the frame threshold

GScript("""
while (counter < lastFrame) {

# Increment the frame removal counter
removeFrameCounter = removeFrameCounter + 1

# Check if the frame removal counter is over the threshold
if (removeFrameCounter >= Floor(removeFrameThreshold + overflow)) {
# Store the overflow
if (overflow > 1) {
overflow = overflow - 1.0
}
else {
overflow = overflow + removeFrameThreshold - Floor(removeFrameThreshold)
}
# Calculate the desired frames. You could use a higher power to make the transition even smoother.
desiredFrames = startFrames + Pow(Float(counter)/Float(lastFrame), 4) * framesRange
removeFrameThreshold = Float(endFrames)/Float(desiredFrames)
# Stop the threshold if it gets too low
if (removeFrameThreshold < 1.1) {
removeFrameThreshold = 1.0
overflow = 0
}
# Reset the counter
removeFrameCounter = 0
}

# Delete or Keep frame
if (removeFrameCounter == 0) {
currentFrame = currentFrame + 1
}
else {
slowdown = DeleteFrame(slowdown, currentFrame)
}

# Increment the counter
counter = counter + 1
}
""")

# Delete the last frame
slowdown = DeleteFrame(slowdown, Framecount(slowdown))
# Return the clip
return slowdown
}
If you know a better method of doing it in Avisynth I like to know about it.
In the mean time I would like this one to work.
Thanks

[Wilbert]

I don't understand why it should work in 2.58 and not 2.6. However the arguments of Trim (startFrames and endFrames) should be integers. So you need to round them in your function Slowmoe3 (and they should be of type int):

startFrames = (mfpsn * 1.0/startRatio)/mfpsd # Starting frames in a second
endFrames = (mfpsn * 1.0/endRatio)/mfpsd # Ending frames in a second

[goorawin]

If I reinstall 2.58 that script works fine. But then some other plugins do not work.
I know they have altered trim functions in 2.6 (its on the changes list) but there is no detail about it.

[Gavino]

I don't understand why it should work in 2.58 and not 2.6.
I expect it's because, although the arguments are declared as float, he always passes integers as the actual values in the call.

In 2.58, such values retained their int type inside the function.
This was regarded as a bug (see thread float parameters are not always floats) and it was changed in 2.60 to convert the values to float on entry to the function.

[goorawin]

I expect it's because, although the arguments are declared as float, he always passes integers as the actual values in the call.

In 2.58, such values retained their int type inside the function.
This was regarded as a bug (see thread float parameters are not always floats) and it was changed in 2.60 to convert the values to float on entry to the function.

If this is the case what would be the solution, any ideas?
Thanks

[Gavino]

Simply change the types of startFrame and endFrame in the function header from float to int.

I don't think Wilbert's change (which affects startFrames and endFrames) is necessary.

[goorawin]

Simply change the types of startFrame and endFrame in the function header from float to int.

I don't think Wilbert's change (which affects startFrames and endFrames) is necessary.

Thank you very much, that solved it. Life will be much easier now!!!
By the way, no one came up with a better solution for ramped slow motion using MVTools. I wonder if there is one out there, somewhere? I only found this one by luck, three or four years ago.