Another problem with recording scripts is how to ensure that the actions in the video are consistent when recording. When making the script, I need to be accurate to at least about 2 frames, which means that a maximum error of 1 frame is allowed. Another question that comes to my mind is how to control the number of recording points. If there are too many, it may be compatible with OSR.But not compatible with the handy
This is capable of < 14 ms latency while independently controlling the 4 onboard rgb LEDs. If I disable the LEDs it does < 3 ms. Last time I checked, and there is lots of room for optimization. So it should be more than capable timing wise for 30 - 60 hz videos.
I focused on reliably producing a low latency signal to a computer for use in other applications. For example a scripting program can take the raw signal (as a numerical value for depth levels 0 + 1-4 with 1- 2 ms latency) then quantize that to sync with 30, 60 fps then interpolate those 5 levels to whatever. Many of the scripts I see could be expressed in 5 levels anyway.
I don’t think the latency in your solution will be the culprit. The most noticeable “latency” with all on-the-fly style scripting is actually the reaction time of the person scripting. That’s why on-the-fly requires you to run the video in slow motion and why some software support a delay adjustment to be applied on all recorded points to compensate for reaction time.
Yes “skill issue” latency.
I can only focus on producing a reliable instrument for others to perform with.
I am aiming at the majority of users for the first most basic and affordable device. Anything could be added on. What % of users would you say are capable of multi axis playback and would benefit from dof sensing? What % of scripters would require more than 5 level, software interpolated scripts?
To be able to create detailed quality scripts you need at least 11 levels (0, 10, 20, … 100).
Regarding device usage. The following post is from Oct 2022, but should give an indication at least. I think the major issue with multi axis is that it takes much longer to script combined with a smaller market share for OSR. If you add VR vs flat and genre/actress preferences to that it becomes even more complicated to find a multi axis script of your liking.
Thanks. It looks like roughly 80% is single variable depth or intensity.
Do you think people would find value in it for scripting at least in producing a usable template for scripts? Instead of it needing to be a perfect script as is, such a recording may be useful for providing a good first draft for artists to manually touch up and fine tune. I can only assume that would be better than needing to manually script everything, plus its way more fun.
These are my reflections on this. Everyone might not agree with me on this (but I think many do).
I script frame by frame because I find it equally tedious and time consuming to touch up a script after using e.g. motion tracker. I strive for quality when it comes to sync, precision and details. Therefore any tools must support that. Recording on the fly with only 5 levels will force the scripter to go through everything and add the details. That is probably equally cumbersome as doing it from scratch.
You will also still need to manually script blowjobs since you need to be creative when it comes to translating what you see to a single axis. Similarly, the devices can’t release its grip like a human hand so you need to be creative to handle that as well as when hands/mouth move in different directions or out of sync. This is very hard or impossible to script with on the fly scripting, which this device equals to.
IMHO, your device is probably not for scripting and more for interactive games where you control the action and want the motion replicated on screen (in opposite to when what happens in the game is replicated to the device, much like when watching a video with a script).
This, just all points are invalid and too many of them.
Yeah don’t think it will be much helpful for scripting yet but a keyboard for penis sounds hella cool. I remember there were numerous depth-sensing onaholes marketed to interact with games (USB Onacon, Ju-C Air, Chu-B Lip). Most sufferred from latency and poor software support. Since this thing uses key switches I imagine it’ll be more responsive?
Also not sure if these DIY designs interests you:
I think it is feasible to provide a first draft. However, based on my current experience, it will also take time to fix an incorrect first draft, but it is better than nothing. In general, I think it is necessary to conduct an actual case to know whether it has any effect on efficiency
Especially when it comes to JOI videos, this type of device (after much revision), would be THE device to have for content creators.
Creating a dildo with sensors for camgirls would probably be a better use of development time.
We’re patiently waiting for the announcement of Teledong’s official release xP
How much did you spend in total to make it?, I hope there will be one day when we will make our own onaholes with video sync just with a mini-computer and a 3d printer, in just one $200 is very expensive especially if it is not the currency of your country, in this case we could print more if the first one broke
I think this is a neat idea and could be cool for interactive games - however for scripting, agree needs more keys for incremental measures but still cool none the less and appreciate by using a custom key board this can be achieved. However, please check out the handy discord… i similarly want to create something to enable live hip movement to handy strokes and this to be able to be used for scripting too as well as interacting with vr games.
So far advice has been to get a accelerometer, get data from physical movement to be calculated for handy movement … but then is the hard bit… you have keys doing the measuring work here… then turning this to script… i’d have the xyz measures then would use z (standing missionary) and y (laying up pumping cowgirl) - a mixture of axial measures then turn this to scripting … can you help me understand how to do this please without me needing to loose my hair trying to understand python
I made it affordable and easy to make. The electronics cost about $30 (no soldering required) plus around 300g of printer filament, 14 m3 heat set inserts and m3 screws ~ $10. It costs less than a fleshlight to make. For sleeves I have it working with regular fleshlights and generic pump sleeves for penis pumps like ones by LeLuv. Fleshlights are expensive so I wanted an affordable option. I could create adapters for other toys too, it is fully modular so you just have to swap out a few pieces and screw it together.
Thanks. I have seen some other designs out there. I decided against light sensors because there really isnt a target to sense. You could try to sense the tip of the penis but that would be unreliable because of fluids and a wiggling plastic sleeve between the sensor and the tip. If it was used to sense the body of the sleeve the sleeve moves around and different materials interact with light diferently so it would be unreliable. It’s not an easy problem. However, I was able to create a solution with mechanical switches and adapters to control the space the penis passes through so the switches reliably set and reset with natural motion.
The way I have it programed now, in one mode it sends a user selected key press to a computer when a switch is pressed (a,b,c,1,2,3 etc.) as a usb hid keyboard. In another mode it does the same but as a bluetooth keyboard. In the third mode it sends a signal to a serial monitor on a computer.
I could reprogram it to do pretty much anything so the switches could send 25, 50, 75, 100 or whatever. Or recording software could understand that a keyboard press of 1 is 25%, 2 is 50% etc.
Vr and multiaxis is kind of a pain right now. The user is usually locked into a position and cant move. Plus the range of motion reproduction is restricted so you exponentially increase the amount of data and work for a few degrees of motion. Almost every vr game that I have played uses a different control scheme and way of orienting the model in vr. Then you have to match up where the stroker is in real reality with virtual reality, its hard.
That is partly why I decided depth was good enough.
The vagina is an input device, the penis is an output. I think we have been approaching the issue backwards. I would rather perform on a fleshlight and watch a machine reproduce my performance on a camgirl. Why stop at one though, why not 100 camgirls at once. Or we could become cam boys where women log in and get devices controlled by men.
But both approaches are good. If I put this on a stroker I could have the best of both worlds switching back and forth between input and output on the fly.