How to set the transport playback rate value with a Python script

[Erriez]

How can I set the transport playback rate value with a Python script? I found functions to decrease or increase the playback rate in steps of ~0.6% or ~6%, but I'd like to set the playback rate to fixed values like 75% or 110% with a function call.

Any ideas?

Thanks,

Erwin

[Erriez]

Anyone an idea how to set the playback rate in a Python script? Or is this not implemented? I'm creating a speedtrainer, but without this function, I can't continue with this project.

[EvilDragon]

Why not run those actions in a loop, to execute them multiple times which will set playrate to a certain value you want?

I guess you can try querying the current value of playrate somehow, and then run a loop to get your percentage done.

[Erriez]

My speedtrainer opens a dialogbox to input the begin speed, end speed and increment speed in %. So when I start the speedtrainer for the first time, I set the playback rate to 1.0 (100%), then decrease the playrate in several steps in a loop to set the begin speed. However, this is absolutely inaccurate. The document describes in steps of ~0,6% or ~6% steps.

curPlaybackRate = 0

def SetPlaybackRate(startSpeed):
	global curPlaybackRate

	# Set playback rate to 1.0
	RPR_Main_OnCommand(40521, 0)
	
	# Decrease playback rate to startSpeed
	curPlaybackRate = 100.0	
	curPlaybackRate = curPlaybackRate - 0.6
	while curPlaybackRate > startSpeed:
		# Decrease playrate with ~0.6%
		RPR_Main_OnCommand(40525, 0)
		curPlaybackRate = curPlaybackRate - 0.6
		RPR_ShowConsoleMsg('%f\n' % float(curPlaybackRate))

So when you test this function with SetPlaybackRate(25) for example to set a playrate of 25%, it results in a speed of an inaccurate speed of 0.48577.

I'd like to set the playbackrate to a decimal value 25...400 in % for example.

So why is a decrease speed not exactly 6% or 0,6%?

[EvilDragon]

Originally Posted by Erriez

So why is a decrease speed not exactly 6% or 0,6%?

Because it's resulting in exactly one cent/one semitone pitch change. It's pitch based, not speed based.

[Diogo Azevedo]

Exactly...

A = 400 hz
A# = 400 * 2^(1/12) hz
.
.
.

2^(1/12) = 1,0594630943592952645618252949463 = approx 1 + 6%

Then pith one semitone is increase approx 6%.

2^(1/120) = 1,0057929410678534309188527497122 =approx 1 + 0.6%. This pith 1/10 semitone.

[Erriez]

Thanks a lot!

A = 400 hz # I think this should be 440Hz, right?
A# = 400 * 2^(1/12) hz
.
.
.

2^(1/12) = 1,0594630943592952645618252949463 = approx 1 + 6%

Then pith one semitone is increase approx 6%.

2^(1/120) = 1,0057929410678534309188527497122 =approx 1 + 0.6%. This pith 1/10 semitone.

I didn't realize that the playback rate is related to the note pitch.

However, AFAIK, the middle A note is 440Hz, but that's a minor detail. See this Wiki page

Now I've improved my Python script:

SEMI_NOTE = 0.0057929410678534309188527497122

def SetPlaybackRate(startSpeed):    
    # Set playback rate to 1.0
    curPlaybackRate = 100.0
    # Transport: Set playrate to 1.0
    RPR_Main_OnCommand(40521, 0)

    # Decrease playback rate to startSpeed
    while curPlaybackRate > startSpeed:
        # Transport: Decrease playrate ~0.6% (one semitone)
        RPR_Main_OnCommand(40525, 0)
        curPlaybackRate = curPlaybackRate * (1 - SEMI_NOTE)
    
    RPR_ShowConsoleMsg('New playbackrate: %f\n' % float(curPlaybackRate))
    
    return curPlaybackRate

def IncrementPlaybackRate(endSpeed, incSpeed, curPlaybackRate):
    startSpeed = curPlaybackRate
    endSpeedDiff = startSpeed + incSpeed

    if (curPlaybackRate < endSpeed):
        while (curPlaybackRate < endSpeedDiff):
            # Transport: Increase playrate ~0.6% (one semitone)
            RPR_Main_OnCommand(40524, 0)
            curPlaybackRate = curPlaybackRate * (1 + SEMI_NOTE)
            DebugMsg('%f' % curPlaybackRate)

Note: Arguments are not checked in this code.

[Diogo Azevedo]

Nice! The correct is Hz (Hertz) and not "hz" (sorry! ), and the A is that A440 (the middle A). Tanks!

I think the code could be improved, optimized, increasing (decreasing) the rate of 6% until no longer possible, and then increasing (decreasing) at 0.6%. You understand?

[Erriez]

I think the code could be improved, optimized, increasing (decreasing) the rate of 6% until no longer possible, and then increasing (decreasing) at 0.6%. You understand?

Yes, I understand your comment. That's a nice optimazation. Thanks!

[sfzgeek]

Originally Posted by EvilDragon

Why not run those actions in a loop, to execute them multiple times which will set playrate to a certain value you want?

Be good if we didn't have to use a workaround though, yeah? Be much simpler if we had a function that simply set the master Play Rate slider to whatever arbitrary value we desire without any looped action calls and the like. Would make the Erriez's scripts more straight forward (and perhaps more accurate).

Off course, I might just be posting this because there are some things I'd like to be doing with this not-yet-existing API call myself... How about it ReaScript gods?

[EvilDragon]

Of course that would be a good thing, to have an API call that would set the playrate to a certain value!

[Erriez]

+1 Exactly! That's what we need.

[sfzgeek]

I use the Play Rate control as a rehearsal tool. The ol' start slow and work the tempo up in a stepwise fashion (much like a speed trainer tool ). To control this during rehearsals (up until now) I used a custom made AutoHotkey script that allowed me to adjust the "actual" tempo (as in, Play Rate * Tempo) by percentage and also by BPM units. I setup hotkeys for +/- 1 BPM, 10 BPM, 1 percent and 10 percent. My script would change the Play Rate slider by interfacing directly with REAPER's window controls. I could read the values directly from REAPER's text edit class controls using AHK. As a results, the relevant info was able to be shown in my AHK GUI, even if REAPER wasn't the focused window. Very cool. Unfortunately for me and my script, recent versions have changed the internal control structure for the transport toolbar and I can no longer get or set those controls without actually sending a mouse click to those dialog boxes to expose the text.

It would be a bit silly to make a FR asking to re-arrange the windows control layout in order to expose those text value to AHK again. Rather, my new found problem could be solved by the availability of an API to read and write values for the master Play Rate slider.

I guess that was a long-winded bump... and FR reminder. Glad I'm not alone on this one.