You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So when iterating through different startframe values in fluid.bufampslice~ I noticed that when sending negative values for startframe, they get internally clamped to zero (this is good IMO). However, if you having a startframe + numframes that exceeds the duration of the file, you get a red error message plastered to the console.
This leads to inconsistent behavior where when programmatically moving through positions in a buffer one needs to be careful of the ending of the file, and not the beginning.
I get that what is being clamped is different (clamping startframe at zero (though not at the top end) vs having a numframes that exceeds the duration), but the UX is awkward as you have to be careful in one direction only.
So when iterating through different
startframe
values influid.bufampslice~
I noticed that when sending negative values forstartframe
, they get internally clamped tozero
(this is good IMO). However, if you having astartframe
+numframes
that exceeds the duration of the file, you get a red error message plastered to the console.This leads to inconsistent behavior where when programmatically moving through positions in a buffer one needs to be careful of the ending of the file, and not the beginning.
I get that what is being clamped is different (clamping
startframe
at zero (though not at the top end) vs having anumframes
that exceeds the duration), but the UX is awkward as you have to be careful in one direction only.IMO a more consistent behavior would be:
That way you can still analyze whatever you want programmatically without having to count samples at edge cases.
Example patch:
The text was updated successfully, but these errors were encountered: