@tonnyhu, valid point but I’m thinking most people will be using a commercial product here and not messing much or at all with hardware.
Right, last week has been nuts but I did manage to do some figuring and testing for fun as well. I’ll have to look into the discord when I have some more time. For starters here what I more or less found out.
Following is a long post of ideas, and be forewarned I don’t really know how feasible they are to execute. But maybe there will be some useful stuff in there.
Synkydink and Script Player handle things a bit differently. Script Player sends the vibrator to full power at the bottom of a stroke, while Synkydink does so at the top of a stroke. Synkydink makes repeated strokes feel much more ‘pulsey’ which is a good thing.
One peak intensity on the vibration per stroke (up and down or down and up) feels best and most like matching the screen. For hands, the most intense point at the top makes sense. For mouth or intercourse the most intense point should be at the bottom of each stroke.
For repeated, more or less steady strokes synkydink works really quite well. It’s for any other action it starts to kind of break down a bit.
Current Lacking Elements:
No motion on screen causing flat vibrator output. This is common to both players - if the action stops at a position, the vibrator just stays at whatever speed that position corresponds too. So with Synkydink, if the model goes to the top and stops, the vibrator just stays on at full power.
Most intense point at the top feels odd for oral or intercourse. Most intense point at the bottom feels odd for hands.
Intensity generally does not correlate. Lazy, slow but long strokes on screen give a more intense vibrator output than fast, somewhat shorter ones when we should see the opposite. Again, common to both players but less pronounced in Synkydink since most fast action hits the top point (and thus full vibe power).
This exact scenario shouldn’t be too hard to fix. If the script shows no movement, vibrator goes off.
Not sure there is an easy way to handle this one in all cases, since the script doesn’t tell us what is going on, just positions and times. Possible idea here is a manual ‘invert’ button so people can choose whether they want the intensity to peak at the bottom or top?
The tricky one. Stroke peed is likely a good measure to use to determine intensity, and easy to get from position and time points ( [p2-p1]/[t2-t1] should work just fine). However, the speed number will really just be a relative indication, since that still needs to be translated to vibrator power. And that begs other questions such as - what is the minimum effective power of toy XYZ?
Without bogging down in specific considerations, the basic premise I have here is:
a) Figure out the speed of the stroke using a linear approximation. Just distance divided by time.
b) Use some formula to determine peak vibrator intensity for the stroke from this speed.
c) Apply this peak intensity at the correct point (bottom or top of stroke depending) and then use whatever method to ramp the vibe power from there to zero at the other end of the stroke. So every stroke would see a pattern of 0 -> peak -> 0 -> peak2 -> 0 -> and so on.
b) is the hand wavey part. I suppose we know the Launch has a maximum speed of 180 bpm, and could use that to create some sort of relation for speed to vibe power. Maybe something like 100% power for anything over 90 bpm, and just linearly decrease vibe power down to 20% for the slowest speed the Launch can go? I think others might have better ideas than me for this.
c) Once we have that peak intensity at the bottom (or top) of the stroke, vibe power can ramp from zero to that peak or that peak to zero in the same way Synkydink already does it. Sure, we could add to this and maybe use a cosine wave instead of a linear ramp (A nice quick approximation would be 100%, 85%, 50%, 15%, 0% of the peak intensity, evenly spaced over the stroke time from peak to zero) on each up or down part of the stroke for a possibly better feel, but just getting the intensity correlation working at all is more important.
A new problem:
Let’s say we get all that working. We’ve solved no movement, and strokes have some intensity which hopefully makes sense with what’s on screen. But we’ve now created a new problem - what happens if you have two, three or more up motions in a row in the funscript? Or down motions?
If a stroke doesn’t go from peak intensity to zero or zero to peak, we still need a way to deal with that. Being honest, I don’t have a good solution here. The only way I can think of doing this is just calculating a new intensity based on the speed of the stroke and ramping between this new one and the old peak. Probably linearlly, since using a cosine curve would give odd transitions at each point in the script.
What does this all look like?:
Writing that out in a general sense for position P, time T and intensity I all at point j, j+1, etc here’s the logic flow I see happening. For this example, I assume peak intensity at the bottom of strokes.
If P(j) = P(j+1), set I(t) = 0 for the entire stroke (or non-stroke really).
If P(j) < P (j+1) and P(j+1) >= P(j+2) it’s a up-down or up and stop stroke.
I(j) should already be known and is Ipeak for this stroke.
I(j+1) = 0
Ramp between j and j+1.
If P(j) > P(j+1) and P(j+1) < =P(j+2) it’s a down-up or down and stop stroke
I(j) should be given and = 0
I(j+1) = Ipeak = calculated from formula
Ramp between j and j+1
If P(j) < P(j+1) < P(j+2) it’s an up-up motion, or if P(j)> P(j+1) > P(j-1) it’s a down-down motion.
I(j) should be given.
I(j+1) = calculate as a new intensity Inew, using the Ipeak formula
Ramp between j and j+1
Assuming that is all understandable and not just a big mess, the logic of it should give some sort of continuous vibe output with at least some correlation to what is on screen.
The big sticking points are how to figure out Ipeak from some approximate speed value, and what to actually do with up-up or down-down motions. What I have here should function, but won’t necessarily feel right.