I use reaper for many things and one of them is looping with pitch/rate changes. When the rate is changed and pitch is preserved, reaper momentarily screws up, that is:
When the item is finished playing and the play rate then changes to some new value, one hears: A temporarily sped up version of the new sound that then goes a bit bonkers and then the correct version. This lasts about 1 second.
It is worse the more drastic the change.
Also, one notices reaper red lights:
and sometimes this just progressively gets worse and worse until reaper freezes(rare though, I've only had it happen a hand full of times). Sometimes it does not show the red linking bar(it may or may not depend on performance issues but I sometimes get even when the computer is doing nothing but playing an item).
One can't hear the audio but it does what I've described.
Now, I just remembered that I am using my own setPlayRate function that attempts to set the playrate value exactly which has to set it to 1 first to do so, since we can only get action commands that add or subtract a fixed amount.
This is most likely why it goes back to standard pitch then changes. I have to do this because there is no way to set the playrate exactly using the api.
e.g., I do this
while i < N do
reaper.Main_OnCommand(40524, 0)0.6%/10cents
end
Which increases the playrate by 0.6*N.
Again, I have to do this because there is no set play rate api function that lets one set the playrate. I've already brought this problem up but it hasn't been addressed.
The main issue is this: Reaper seems to crap out either when doing this playrate change hack or for other reasons. I have had it do it when I do not use this script and do the play rate changes but that might be from other causes.
In any case, reaper seems like it could do a better job of handling looping.
Maybe the playrate setting can be filtered a big so quick changes are "ignored"(unless it is the last one given a small period of time).
This is relatively easy to do and will smooth out glitchy behavior and probably should be done for all UI interactive elements such as sliders but even buttons work.
In the mechanical world, the same problem happens for push buttons, say, where a capacitor(a low pass filter) is used to smooth out the "bounce".
For code, it is something as simple as
OnsliderChanged()
if currentTime - valueTimeChangedLast < epsilon
valueTimeChangedLast = currentTime;
else
{
valueTimeChangedLast = -1;
setValue = value;
}
Which effectively removes all intermediate changes to the the value that happen within epsilon seconds.
This would work well for simple stuff like the play rate slider since there is never a reason when it should have to be changed after than within a few hundred milliseconds.
There are better ways and the above technique might require calling it in a thread(since it needs to be called one more time so it can actually set the value when necessary).
Of course, it would still be nice to have a function that can set the play rate absolutely.