Thanks man, that’s great news. I’ll investigate!
It seems I’m too dumb to figure this out. I downloaded the zip from github, now I don’t know what file to open/how. There’s no .exe to run as far as I can tell.
This is pretty common, that programmers post a github link to a whole project and expect people to know what to do with it. I’m not l33t enough, send help.
You probably downloaded the source code from the main github page.
There is a download section in the main post, use that.
I found it. Github really isn’t noob friendly.
For those that are just as dumb as I am, go to Releases, click the latest one, then scroll down to the bottom for Assets. There you can find .zip files for the code as well as the actual program that you can run (.exe).
I’m a complete newbie and trying to figure out how to install this on my windows PC from GitHub (I’m used to installing from a .exe file). Any tutorials out there?
No need to install anything, just download the self contained zip file on the github, unzip it somewhere and run the exe inside.
Would it be possible for MFP to control the playback speed variable in Heresphere? I’m thinking of a speed limiter that instead of shortening the strokes, slows the playback speed.
Thats an interesting idea. I’ve quickly tested it with mpv and it seems to more or less work, tho I dont know if I would add it to MFP, I think it would be better as a plugin. Also it needs to be tested in VR as I’m not sure the decoder will like the playback rate changing so often with 8K videos.
For now I’ve added shortcut actions to change playback speed so you could change it manually: nightly.link | Repository Yoooi0/MultiFunPlayer | Run #6553384789
2 Likes
Thanks for adding the shortcuts! I think that will make a much more enjoyable edging button than just changing the speed limit. I wish I had the coding chops to make a plugin. Dynamically changing the playback speed to keep full range of motion within the speed limit would be sooo good if it worked. I’d even want to add customizable limit overrides based on starting and stopping position so that say a movement starting 60% or lower and moving downward could move x% faster than the base limit speed, or a movement starting above 80% had to be x% slower than the base limit.
I made a quick plugin if you want to test.
But you need to use this build: nightly.link | Repository Yoooi0/MultiFunPlayer | Run #6567589368
PlaybackSpeedLimit.txt (2.9 KB)
Save to plugins folder then change extension from .txt to .cs.
You can open it in text editor and change alpha which determines how fast the playback speed responds (1 = instant), and maxSpeed which determines maximum stroke speed (basically lower the 0.300 to increase maximum stroke speed, or increase it to decrease maximum stroke speed).
After each change you need to refresh the plugin in MFP ui.
I would try it with mpv first.
Not sure what you mean by that exactly.
1 Like
This doesn’t seem to be working in real time. Forgive me if I’m reading it wrong. It seems to be letting the script play normally, and then analyzing the movement speed to adjust a playback speed variable. So a fast movement is starting fast, and then slowing down during the movement. I think for it to work real time, it would need to look at the time and position instruction before it’s sent to movement, and override the time it’s supposed to finish the movement while sending the playback speed adjustment. There might still be some timing discrepancy, but it shouldn’t show in the speed of the movement at least, just have a slightly different start position than the script expected.
If you want it to work in “real time” then set alpha to 1, but the playback speed will be jumping up/down a lot.
I have it set to 1. It’s still adjusting the speed during the movement. Correct me if I’m wrong, It seems to be looking for a difference between 2 positions to detect speed, so it has to move at the unadjusted speed for it to know the movement is too fast before it adjusts the speed, thus there will always be latency. It would need to evaluate the instruction before movement to stop that.
Even if speed is evaluated the moment the script keyframe index changes there will be latency. (You could maybe decrease the Thread.Sleep time, should help a little)
Because the speed change event needs to be first queued, then sent to the player, then the player needs to update it internally, then the player needs to respond with actual updated playback speed, and then finally the playback speed is applied internally in MFP. That will be probably at best minimum 30ms.
I have not tested it on an actual OSR but I dont see how it can accelerate that fast even assuming 50ms latency. I’m testing with mpv with a script that goes from nothing to insanely fast strokes and looking at the axis value bar you would not be able to feel the fast stroke.
I see one mistake tho is that the plugin does not update its position on each tick and relies only on the player to provide position events. With mpv it might work more or less fine since it updates each video frame, but heresphere updates once per second.
There’s more going on there than I understood. I assumed the regular speed limiter just looked at each new instruction and overrode the destination position, so you could instead override the destination time, send the movement, and send the relative playback speed change to the player. Then if the player got to the next instruction off timing, it would just affect the relative start position for the next movement. The kind of handshake you’re describing would certainly complicate things.
If you have the regular speed limiter on at the same time, it’s masking the mid movement speed change, and turning it into range of motion limtation. It should be pretty apparent without it. Changing the playback offset in MFP also makes the speed change happen outside the motion’s normal timing.
I had thought of this as a replacement for the regular speed limiter, but it’s actually really cool what having both with different limits does. I have the regular one set at .5, and the plugin at .3. Keeping the plugin value lower makes it have a lot less impact on playback of the video. When it kicks in at the much faster movement, if all you had was the regular limiter, the range would be limited to effectively nothing. Using both minimizes the downside to either while normalizing a wider range of speed.
So I’m trying to do both Passthrough while using my SR6 with the MFP. If I try to access SLR through Virtual Desktop, I can’t do passthrough, but if I access SLR through DeoVR app, then I can’t connect the MFP. Any way to get both script and passthrough working?
SLR app and DeoVR are the exact same application. If you run DeoVR on your quest then in MFP you need to expand DeoVR settings and change the IP to your quest IP.
Internally MFP is completely decoupled from the script because of interpolation, so there is no destination position and time like in normal funscripts. Funscripts are sampled at 300-400hz and speed limit just looks at current vs last sampled value and corrects the current if it would cause too fast of a change.
Yea another oversight, it should read actual axis position which includes all the offsets instead of reading the position reported from the video player.
If it was changed to read the actual axis position, would it not work with the regular limiter set = or slower than the plugin?