Is there a way to connect an android phone to MFP now? I used to use DeoVR and MFP together and that worked great… until it didn’t. I’d like to be able to watch VR videos with my GearVR/cardboard and I’m wondering if there are any current android apps that are able to connect to MFP like DeoVR did. I tried installing the heresphere android demo on my samsung s10, but the app would never open on my phone. Any ideas would be appreciated.
Well MFP only supports DeoVR/HereSphere/Whirligig as VR players so I guess you can only use those on android if they are available.
What doesnt work with DeoVR? Maybe you need to enable remote server in DeoVR settings?
Is there a way to only output the raw funscript points to the t-code device, without the interpolation?
(i.e. L00000I500 L09999I450 L00000I300 L05000I250)
I’m using a stepper servo system and the controller needs this for the correct acceleration values, currently it’s working but it’s far from smooth.
Currently no, but I might add it as an option in the future as I thought about it before.
The problem is that sending only script actions would have to bypass pretty much all of the other features, so it would work a little weird.
Ive used interpolated motion like this with a stepper before and I just set some constant acceleration, it worked pretty well, didnt have any problems with smoothness.
You could try maybe lowering the update rate so the steps are not so fast, and probably disable the “offload elapsed time” toggle so that TCode commands include step duration.
I think servos should not have any problems with following an interpolated curve.
1 Like
When I monitor the STEP interpolation output, I think it almost does what I need, it just doesn’t update the interval part. (ie L0000I33)
It always stays at the set update rate, shouldn’t this have been dynamic? The update rate isn’t fixed anymore when using STEP.
18:09:18.263 L07999I33
18:09:18.577 L02000I33
18:09:18.810 L07999I33
18:09:19.021 L02000I33
18:09:19.175 L07999I34
18:09:19.379 L02000I33
18:09:19.851 L07999I33
18:09:20.232 L02000I33
18:09:20.443 L07999I33
18:09:20.595 L02000I34
18:09:20.832 L07999I33
18:09:21.077 L02000I33
18:09:21.504 L07999I33
18:09:21.925 L02000I33
18:09:22.126 L07999I33
18:09:22.298 L02000I33
18:09:22.515 L07999I33
18:09:22.766 L02000I33
18:09:23.196 L09999I33
18:09:23.648 L00000I34
18:09:23.989 L09999I33
18:09:24.333 L03000I33
18:09:24.809 L09999I33
The update rate is fixed, it just gets optimized to only send when the value actually changes. This can be changed with “send dirty values only” toggle, you will then for example receive many repeated L02000I33 commands.
If step interpolation works for you then I guess you could just leave the “send dirty values only” option enabled and calculate the time between commands in your device firmware.
Tho next command could be at most late by the update interval, so you would probably want to set the update rate as high as possible.
But then I would be one command behind every time, and I have no way to really optimize that.
This is the effect I’m currently getting with the current setup:
[picture from f86k]
Yea, im just throwing some options.
You cant really make MFP suddenly look ahead in the script since it was made to live interpolate the script from the ground up.
Well, not really. JFP doesnt inlcude the I part in TCode so yea the movement is the red line with very fast servos, but MFP does include it and if the device handles it then the movement is the green line.
With low update rate like 30hz I dont see how the stepper cant be made smooth.
When I was using steppers I think I didnt even use the interval I between commands, I just updated stepper target position on each received command.
I appreciate the help! 
I still have to deal with constant acceleration and de-acceleration of the servo stepper, the interpolation doesn’t help in this case, if there would be some kind of raw mode in the future of MFP, that would be great.
1 Like
Sending just script actions will probably not fix that. They wont be perfectly chained anyways.
Basically the same thing will happen no matter if you update at 100hz or update only on script actions: Large output sleep jitter can cause device stutters · Issue #77 · Yoooi0/MultiFunPlayer · GitHub
If the output is raw, on script actions, the movements are very clean and smooth.
I can get those result if I use XTPlayer, but XTPlayer is not really usable on a VR device.
(Right now the command interpreter in the firmware calculates the acceleration and speed for each command from the I modifier, and the result is mostly within a ms or 2. After that the next command awaits in the serial buffer)
So that depends how detailed the script is then?
If the script has in between actions instead of only peaks it will also be not smooth?
Do you have an example what do you consider not smooth stepper?
Why its not possible to do the same with MFP at for example 30hz?
1 Like
If the script is smooth and has long strokes, the device will be smooth. Instead if the script wants it to be rough, the result can be very rough. It can be made to vibrate like a mini earthquake if the script commands it to. (servo power is 180watt and a FL isn’t exactly lightweight)
Like the following:
Yes it won’t be smooth then, I think it’s very true to the exact script, it tries to follow the script points exactly. (within reason, if the action is out of the capabilities of the device it reduces the stroke to keep it in sync)
For every command MFP sends it tries to do an acceleration and de-acceleration, the result is always very rough, like the script pictured above. One stroke could have as many as 10+ unintended accelerations and de-accelerations in it.
If MFP would update the I in STEP mode (and send dirty axis only), I believe the output would be like XTPlayer, if i’m right. And one script point would be one action and one acceleration and de-acceleration.
Thanks for taking the time and discussing this with me Yoooi! 
DeoVR was working well on android at one point, but I thought that they removed the remote server functionality a few months back? Maybe they brought it back? I’ll take a look and let you know.
Looks like I was wrong. I opened up my DeoVR cardboard app on my android phone and can connect just fine to MFP running on my laptop. I must have messed something up at some point. Thanks for helping me see the error in my ways, and thanks for building and supporting this awesome app and community!
1 Like
Hi @Yoooi,
thanks for creating such a fine piece of software. I was browsing your code on github and saw that the HDSP mode is currently used. This mode allows for direct streaming but needs a fast direct connection. Would it be possible to operate the Handy via the HSSP mode? The micro stutter issue should be solved by using this mode as the script is uploaded to the device and only time sync information are exhanged via their API.
Is this something you would integrate in an upcoming release?
Cheers
HDSP should technically work somewhat decent even on slower connections.
But I dont have the handy so I cant really debug it, it probably needs some changes to the timing loop so that the commands are send at correct times.
I wouldnt call it micro stutter, from what ive seen HDSP is completely unusable, just doing some random movements.
Yea you would just have to listen to ChangeScriptMessage, MediaPositionChangedMessage and MediaPlayingChangedMessage inside TheHandyOutputTargetViewModel, and send the events with HSSP mode.
Eh, maybe someday. I’d rather have the handy team implement local wifi connection.
Also another fix might be to Implement sending data only on script actions (look ahead) · Issue #92 · Yoooi0/MultiFunPlayer · GitHub to limit number of commands sent.
I will try to reserve some time and go through your code. Maybe I can create a pull request. I’ve got a handy in my disposal and can debug it.
I think a local wifi connection is somehow possible. I haven’t taken a deep look into their API but I think you can setup a local webserver and redirect the Handy to a local websever. The Scriptplayer use this approach I guess.
If you do, please make an issue first before a PR so that the implementation can be discussed, or we can do that here.
Tbh I think HSSP mode could be a simple MFP plugin since 1.24.0 supports plugins. It wont really fit the OutputTarget code since they are all update/tick based.
You can host scripts locally so that the handly loads them from a local server instead of having to upload them to handy servers, but there is no “HDSP” like api that works locally and doesnt go thru handy servers.
A plugin would be the better choice then, i guess 
I just tested MFP with initface and got the same stuttering movement. Using the initface (buttplug) connection with Scriptplayer, everything works as it should. Maybe there is a issue with how the positions are extracted or calculated?
1 Like