Plugins + Scripts MFPButtDriver: MultiFunPlayer drive Person hip/butt bone movement

[nb9527]

Looks promising.
Would be nice you you could provide a little demo scene with script to test it out and better understand how it works.

Thanks for the suggestion. Unfortunately a demo scene for this plugin would be difficult to make, since it relies on MultiFunPlayer.
I did consider creating a demo scene for my other plugin FunSequencer. I spent nearly an hour trying to put one together but gave up, as I don’t have much experience building VaM scenes. You might see a demo scene sometime in the future. In the meantime, I will try to record a usage‑video to show how it works.

 

[rokoc]

It looks like you are building scenes with MFPButtDriver. I don’t have much hands‑on experience creating scenes myself, so I really appreciate all your testing. I have a few questions I’d like to discuss with you.
Are you generating motions via MFPButtDriver and then recording those motions into Timeline? This workflow has two notable drawbacks:

1. The T‑Code streamed from MFP is not the raw funscript data. MFP applies smoothing to funscript, plus configurable fade‑in / fade‑out at playback start and stop. On top of that, recording baked animations discards the original funscript entirely, which is critical for OSR hardware users.
2. There is no obvious way to preserve audio synchronized with motion, and I am not aware of native Timeline functionality for this purpose.

That led me to design an alternative solution: FunSequencer. The workflow works like this:

1. Create segments (seg1) clipped directly from the source funscript file — this covers exactly the motion range you would otherwise record as Timeline keyframes.
2. Place triggers at the start and end of your Timeline animation: fire StartSegment(seg1) and StopSegment(seg1) respectively.
3. For synchronized audio, use the extract‑audio feature. It extracts the matching audio range from your source video and saves it as seg1.wav. The audio will play automatically when StartSegment(seg1) gets triggered.

I understand this workflow may feel unintuitive for existing Timeline users, so I would love to hear more of your feedback and suggestions.

hey thanks for sticking with this. I realize my use-case might not be what other people or yourself have in mind for this plugin but as I see it it can be many things

tech side I can setup a scene but when it comes to animating I suck. it's not too bad but it could be so much better.

to answer your questions, I am generating motions via buttdriver and recording in timeline. my plan is to record ~10 second loops of some of my favorite funscripts, tweak out problematic keyframes, reduce keyframes and use these loops in the weaver plugin with an aim to making an interactive procedurally generated infinite sex scene and safer when using a multi-axis osr devices. safer since all the middle men are taken out (no players, no mfp, or bridges, funscript files and videos etc) then less to go painfully wrong.

Weaver - Plugins + Scripts -

🕸️ WEAVER v0.6 Timeline Animation State Machine Weaver is a state machine plugin built around Timeline that handles animation flow for you. Instead of manually wiring triggers and transitions, it organizes your clips into states, manages...

hub.virtamate.com

by recording animations and using toyserialcontroller (the forked version with virtual dildo) during playback you can control osr devices from within vam without any outside interference and again is safer imo (see my post here: https://hub.virtamate.com/threads/auto-masturbators.77055/#post-241347)

ToySerialController: Driven Dildo Fork - Plugins + Scripts -

Passerby: What does this plugin do? MahiroOyama: Before I introduce this plugin, I need to introduce the original ToySerialController. In short, ToySerialController can drive your real-life sex toy to move by capturing a reference pose from one...

hub.virtamate.com

as for audio, again my use-case doesn't require it. vammoan2 plugin will handle this and ill control through weaver/timeline.

I totally see were you are going with the both your plugins though. I wouldn't want to tell you what direction to take with it. I don't know how other scene creators would see things. discussion is pretty slow here, i could just be a weird outlier but if you removed the Direct mode I wouldn't be able to record in timeline since physics mode is, well, physics.

v3 is doing what I need but with a few niggles/bugs that I can work around, ive already recorded some loops. looking forward to trying v4

p.s.
eroscripts.com is a great resource for everything to do with funscripting and devices. im guessing you already know that though

 

[rokoc]

I almost forgot. your alternative solution: FunSequencer.

I'll experiment more with it as it could be tool for the job. reliance on bridge and potplayer is holding me back but i might just put up with it for the sake of recording a loop.

 

[nb9527]

hey thanks for sticking with this. I realize my use-case might not be what other people or yourself have in mind for this plugin but as I see it it can be many things

tech side I can setup a scene but when it comes to animating I suck. it's not too bad but it could be so much better.

to answer your questions, I am generating motions via buttdriver and recording in timeline. my plan is to record ~10 second loops of some of my favorite funscripts, tweak out problematic keyframes, reduce keyframes and use these loops in the weaver plugin with an aim to making an interactive procedurally generated infinite sex scene and safer when using a multi-axis osr devices. safer since all the middle men are taken out (no players, no mfp, or bridges, funscript files and videos etc) then less to go painfully wrong.

Weaver - Plugins + Scripts -

🕸️ WEAVER v0.6 Timeline Animation State Machine Weaver is a state machine plugin built around Timeline that handles animation flow for you. Instead of manually wiring triggers and transitions, it organizes your clips into states, manages...

hub.virtamate.com

by recording animations and using toyserialcontroller (the forked version with virtual dildo) during playback you can control osr devices from within vam without any outside interference and again is safer imo (see my post here: https://hub.virtamate.com/threads/auto-masturbators.77055/#post-241347)

ToySerialController: Driven Dildo Fork - Plugins + Scripts -

Passerby: What does this plugin do? MahiroOyama: Before I introduce this plugin, I need to introduce the original ToySerialController. In short, ToySerialController can drive your real-life sex toy to move by capturing a reference pose from one...

hub.virtamate.com

as for audio, again my use-case doesn't require it. vammoan2 plugin will handle this and ill control through weaver/timeline.

I totally see were you are going with the both your plugins though. I wouldn't want to tell you what direction to take with it. I don't know how other scene creators would see things. discussion is pretty slow here, i could just be a weird outlier but if you removed the Direct mode I wouldn't be able to record in timeline since physics mode is, well, physics.

v3 is doing what I need but with a few niggles/bugs that I can work around, ive already recorded some loops. looking forward to trying v4

p.s.
eroscripts.com is a great resource for everything to do with funscripting and devices. im guessing you already know that though

I roughly understand your workflow. I have one small suggestion: since the motions are originally generated from funscripts, would it make sense to preserve the original funscript data and use it to drive the OSR hardware directly?
I know someone who feels that motions generated by ToySerialController are not ideal and keeps working on improvements for it. Driving hardware directly from the raw funscript could avoid inaccuracies introduced by both ButtDriver and ToySerialController.
BTW: I will keep the Direct mode intact.

 

[rokoc]

I roughly understand your workflow. I have one small suggestion: since the motions are originally generated from funscripts, would it make sense to preserve the original funscript data and use it to drive the OSR hardware directly?
I know someone who feels that motions generated by ToySerialController are not ideal and keeps working on improvements for it. Driving hardware directly from the raw funscript could avoid inaccuracies introduced by both ButtDriver and ToySerialController.
BTW: I will keep the Direct mode intact.

I'm always open to suggestion but the random playback of the recorded sections and other interactions makes the original funscript useless. I could stitch together a funscript but it then wouldnt act randomly or transition(weaver) the loops properly I'd have to rethink my entire scene and rework other areas.

I've got quite a few ideas in my head how to utilise your plugins. thanks for keeping direct mode, such a win to bake the funscript to vam if you want.

in the case of both your plugins for just playing back funscripts as you intended I'd definitely be controlling the toy from multifunplayer. the controls for limiting the axis(bottom dual sliders) is super intuitive. toyserial controller not so much.

The person you know ain't wrong it's not ideal. Overall it felt really janky, constantly fiddling with it and never being satisfied. in the end when it was set properly my animations translated very robotic to the osr.

Things improved when I switched to the dildo fork version of toyserialcontroller and using the virtual dildo(actually no dildo, think of it as a ghost dick)

 

[nb9527]

I'm always open to suggestion but the random playback of the recorded sections and other interactions makes the original funscript useless. I could stitch together a funscript but it then wouldnt act randomly or transition(weaver) the loops properly I'd have to rethink my entire scene and rework other areas.

I've got quite a few ideas in my head how to utilise your plugins. thanks for keeping direct mode, such a win to bake the funscript to vam if you want.

in the case of both your plugins for just playing back funscripts as you intended I'd definitely be controlling the toy from multifunplayer. the controls for limiting the axis(bottom dual sliders) is super intuitive. toyserial controller not so much.

The person you know ain't wrong it's not ideal. Overall it felt really janky, constantly fiddling with it and never being satisfied. in the end when it was set properly my animations translated very robotic to the osr.

Things improved when I switched to the dildo fork version of toyserialcontroller and using the virtual dildo(actually no dildo, think of it as a ghost dick)

I totally agree with you. That’s why FunSequencer is mainly oriented toward motion‑creation workflows. A few days ago I built a small demo with it, and found that using the original audio from video works really well.
Regarding how to drive OSR smoothly and effectively using the original funscript, I actually released the FunTimeline plugin some time ago. It is designed for full‑length funscript playback. I have introduced a timeline‑style keyframe system, which supports scene dynamics and pose switching during funscript playback.
I’ve recently been trying to put together another demo with it, so we’ll see how it turns out in the end.