I have no idea.
I just tested on a clean win10 and I just had to install .net6 from my link, no restart required.
Maybe also try to install x86 desktop runtime from here: Download .NET 6.0 (Linux, macOS, and Windows)
1 Like
If it is working on your end, then I will keep troubleshooting lol. These are features I have been waiting for for a loong time. If anybody else on this thread can verify that this is working on their machine with no issue would be great.
Thank You for your work. If this works, I will re-sub your patreon 
PSA: Anyone having issues make sure to install the SDK version of .NET 6.0 (link right above this post). The Runtime one for some reason didnt work for me. This is working now for me now! Thanks again!
1 Like
Any more detail on these features? Noticeable to end user (OSR2+)?
I have actually not yet used the precise update rate due to lack of free time, but this is the old behavior that was in some early versions of MFP.
Basically is sacrifices CPU time to send data at even 3ms (at 333hz) intervals, with precise disabled is all over the place between 2-6ms.
It should technically be smoother since OSR would not wait for the next command since they would be perfectly chained. But on the other hand its only 2-3ms of wait so the inertia might smooth it out anyways.
I’ve added it as an option to test, maybe it will make a difference.
Is it possible to make the auto connect feature rotate faster? so that if i start my video and the MultiFunPlayer detects mpv, it instantly plays? Like im playing 2-3 seconds into the video until the program recognizes my mpv player
^ i mean to make this faster/instantly. (without adding an executable, it goes through a .conf on my player.)
I am a fan of and a connoisseur of random strokers.
Having said that, if you are looking for a great random stroker for OSR, look no further. The LoopingFunscript motion provider combined with a speed offset keybind (so that you can increase or decrease the speed) and Axis::Bypass::Toggle keybind to play/ pause does the job soo damn well.
This application can also be combined with BusDriver if you are into VAM. I have not tested the Motion Provider with the BusDriver plugin, but I assume it should work as intended. I am not being paid to say this, just singing praise for something that I know took a lot of work, and works very well.
2 Likes
Yea sounds like a good idea.
Added as todo on github.
1 Like
Sorry if i ask to much, but is it also possible to add “launch with windows startup” and “minimize to tray”?
You can create a shortcut to MFP executable and put it in C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, it should auto start on logon.
About tray icon, I’ll add it to consider, will have to see how much work it takes.
1 Like
I use MFP to “sync” the pitch and roll axis and had some questions around the functions.
Script blending - What does this do?
Seed - What does this do?
Speed - Guessing this is the rate of randomization along the axis?
Range - How does this relate to the range set in the “output range” section in the lower section of MFP?
Script blending - What does this do?
If you have a script loaded on an axis and enable motion provider on that axis, you can blend the two together.
Basically allows you to add variation to the script with motion providers.
Seed - What does this do?
Each seed value will generate the same random motion each time you run MFP.
I guess that makes it not really random… I think I will just remove that option and randomize the seed.
Speed - Guessing this is the rate of randomization along the axis?
Yes, its how fast the time advances for the motion provider.
Range - How does this relate to the range set in the “output range” section in the lower section of MFP?
This setting makes motion provider output values in the specified range. If you change the range you will see the values be limited in the “axis values” display.
The outputs expect the values to be between 0 and 100% which then gets mapped to the output range.
So if you have output range of 20% → 100% and motion provider range of 0% → 75%, the resulting range will be 20% → 80%.
Basically you align motion provider range slider on top of output range slider, kinda like so:
1 Like
You can change scan delay and scan interval in this build: nightly.link | Repository Yoooi0/MultiFunPlayer | Run #1584464122
Accessed via “cog” buttons on the right side.
Hey, thanks for your help!
I recently tested Multifunplayer and i got this weird issue with my handy. The length is set to full i think (1-100) but whenever i play a script, it stutters and doesnt go all the way up. Im using buttplug.io to connect. I also redownloaded the programm and did no changes to see if i messed up the settings. And advice?
Buttplug issues were reported by a few people but I dont know if its a MFP issue or not yet as I had no time to test, iirc it was something with bluetooth in buttplug.
Buttplug integration was made mainly for vibes, not for OSR/handy so the behavior might not be the best.
Any partilcar reason why the program only work with dotnet runtime 6.0.0 and not the latest 6.0.1?
Nevermind, it is just that the installer is pointing to regular dotnet, and not desktop version.
Does Update Rate in MFP, have anything to do with Servo Frequency setting in Krull’s firmware? Should they match or doesn’t matter.
Doesnt matter if they match or not, high update rate will mostly benefit scripts that are very detailed, since the update rate determines how well the sent values follow the source funscript.
Those very detailed scripts will be marked by the “RAW” text turning red next to the loaded script file name.
I made a desmos graph a long time ago that might help you visualize the relation: Position vs Frequency
Black curve: ideal/script positions
Red points: positions sent by mfp to firmware
Green points: positions sent by firmware to servos
Appreciate it. That is a wonderful visualization of it. In your experience, are there any negatives to running servo frequency and update rate maxed out? I was trying to chase down some random jerky movements and was wondering if this was a troubleshooting stop that I should fiddle with.
are there any negatives to running servo frequency and update rate maxed out?
Dont think so. An edge case might be when using UDP with very high update rate the data might arrive out of order. But that should be pretty rare.
I was trying to chase down some random jerky movements and was wondering if this was a troubleshooting stop that I should fiddle with.
If you use tempests firmware there is an issue in his firmware that causes random jerky movement.
Does that mean is better using a different firmware/version for the time being?