Restim: e-stim audio generation software

[edger477]

Is this helpful?

Screenshot 2024-12-04 223358.png

I can see that your line "no viable protocols for hardware" does not exist for me, instead it says: "Found protocol "tcode-v03 for user specifier Websocket (WebsocketSpecifier { name: "restim" }). And then it says how restim is connected.


Obviously it takes protocol from here:

It must be that in your case either intiface is not configured correctly or it appears to be configured correctly but is not using correct configuration.

You could try their troubleshooting before re-adding restim device:
At the bottom of the Settings panel is a Reset Intiface Configuration button. This will delete all settings from Intiface Central.

[Corndogville]

Is this helpful?

Screenshot 2024-12-04 223358.png

I can see that your line "no viable protocols for hardware" does not exist for me, instead it says: "Found protocol "tcode-v03 for user specifier Websocket (WebsocketSpecifier { name: "restim" }). And then it says how restim is connected.


Obviously it takes protocol from here:

It must be that in your case either intiface is not configured correctly or it appears to be configured correctly but is not using correct configuration.

You could try their troubleshooting before re-adding restim device:
At the bottom of the Settings panel is a Reset Intiface Configuration button. This will delete all settings from Intiface Central.

Yeah, alas, I've deleted the config and readded Restim, both, numerous times. Are you guys sure you're on the newest version of Intiface? Can't help thinking they broke something.

[diglet]

I updated to the newest version when troubleshooting your issue a few days ago. These have been no new versions since.

Does your buttplug-user-device-config-v3.json (%appdata%\Roaming\com.nonpolynomial\intiface_central\config) look like one of these?

Code: Select all

{
  "version": {
    "major": 3,
    "minor": 0
  },
  "user-configs": {
    "protocols": {
      "tcode-v03": {
        "communication": [
          {
            "websocket": {
              "name": "restim"
            }
          }
        ],
        "configurations": []
      },
      "": {
        "communication": [],
        "configurations": []
      }
    },
    "devices": []
  }
}

Code: Select all

{
  "version": {
    "major": 3,
    "minor": 0
  },
  "user-configs": {
    "protocols": {
      "tcode-v03": {
        "communication": [
          {
            "websocket": {
              "name": "restim"
            }
          }
        ],
        "configurations": []
      },
      "": {
        "communication": [],
        "configurations": []
      }
    },
    "devices": [
      {
        "identifier": {
          "protocol": "tcode-v03",
          "identifier": "restim",
          "address": "00000000"
        },
        "config": {
          "name": "TCode v0.3 (Single Linear Axis)",
          "features": [
            {
              "description": "",
              "feature-type": "Position",
              "actuator": {
                "step-range": [
                  0,
                  100
                ],
                "step-limit": [
                  0,
                  100
                ],
                "messages": [
                  "LinearCmd"
                ]
              }
            }
          ],
          "user-config": {
            "allow": false,
            "deny": false,
            "index": 0
          }
        }
      }
    ]
  }
}

Try overwriting the file with one of these and see what happens.

[edger477]

Yeah, alas, I've deleted the config and readded Restim, both, numerous times. Are you guys sure you're on the newest version of Intiface? Can't help thinking they broke something.

I know you tried deleteting config. That is why I asked to try reset all settings (which should be similar to deleting or replacing configs that diglet just proposed).

[Corndogville]

Yeah, alas, I've deleted the config and readded Restim, both, numerous times. Are you guys sure you're on the newest version of Intiface? Can't help thinking they broke something.

I know you tried deleteting config. That is why I asked to try reset all settings (which should be similar to deleting or replacing configs that diglet just proposed).

Sorry, I was meaning say I had reset Intiface application settings (and the user settings) many times, and as you noted, the config.

I will look at the file diglet asked about soon. Thanks again guys.

[Corndogville]

I updated to the newest version when troubleshooting your issue a few days ago. These have been no new versions since.

Does your buttplug-user-device-config-v3.json (%appdata%\Roaming\com.nonpolynomial\intiface_central\config) look like one of these?

Code: Select all

{
  "version": {
    "major": 3,
    "minor": 0
  },
  "user-configs": {
    "protocols": {
      "tcode-v03": {
        "communication": [
          {
            "websocket": {
              "name": "restim"
            }
          }
        ],
        "configurations": []
      },
      "": {
        "communication": [],
        "configurations": []
      }
    },
    "devices": []
  }
}

Code: Select all

{
  "version": {
    "major": 3,
    "minor": 0
  },
  "user-configs": {
    "protocols": {
      "tcode-v03": {
        "communication": [
          {
            "websocket": {
              "name": "restim"
            }
          }
        ],
        "configurations": []
      },
      "": {
        "communication": [],
        "configurations": []
      }
    },
    "devices": [
      {
        "identifier": {
          "protocol": "tcode-v03",
          "identifier": "restim",
          "address": "00000000"
        },
        "config": {
          "name": "TCode v0.3 (Single Linear Axis)",
          "features": [
            {
              "description": "",
              "feature-type": "Position",
              "actuator": {
                "step-range": [
                  0,
                  100
                ],
                "step-limit": [
                  0,
                  100
                ],
                "messages": [
                  "LinearCmd"
                ]
              }
            }
          ],
          "user-config": {
            "allow": false,
            "deny": false,
            "index": 0
          }
        }
      }
    ]
  }
}

Try overwriting the file with one of these and see what happens.

That fixed it! I didn't even have to scan for device. Thanks!

When I opened up the file in notepad++ there was no formatting, it was all on 3 lines. I pasted your first one in, saved it, and started Intiface and it connected as soon as I hit the play button.

I don't know if it'll stay that way, but at least I have a fix!

[diglet]

Update of the progress last month and future direction. I have been working on a new open-source stim device, called FOC-Stim (viewtopic.php?t=27397). This device generates exactly the same waveforms as the threephase pulse mode in restim.

The big advantage of the new device is that it is current controlled. From here on you may start seeing more funscripts with the carrier frequency axis, initial testing indicates this works well on the current controlled box, but we've always found it to not work on conventional stereostim boxes.

Another new device that is on the horizon is the NeoDK (https://github.com/Onwrikbaar/NeoDK). This is a 4-electrode pulse-based design, I hope the API will be released in a few months. I will be working on implementing support for this device in the future. First with three-phase, and later 4-phase signal generation. This hardware cannot generate analogue waveforms and will require an entirely new signal generation approach, a nice math/coding challenge

I have removed support for 4-phase and 5-phase audio generation from the software. This feature was a big technological achievement, but stereostim hardware just isn't good enough for this level of signal generation complexity.

[darthjj]

A comment I wrote in a different thread made me think about volume calibration, but I thought it might be better to discuss it here..

If I don't do anything to calibrate the volume, i.e. I keep limit min and max in Restim to 0 and 1 respectively, then I don't feel any funscript volume less than 60-ish. So I set limit min to 0.5 to "normalize" the range, so that a funscript 0 is not noticeable but once it goes up to 10-20 I can feel it. To me this feels like the logical thing to do, but I would guess that most Restim users don't do this, so if a content creator makes funscripts for estim then they might only use higher higher volume values. And having to know what values a specific script was made for, and change your settings for each file, is of course not ideal.

Another thing is that I want the nerves to rest at some points in the funscript, so that they regain their sensitivity, and I'm not sure if I get that with my current calibration where funcscript volume 0 gets remapped to limit min which is 50% software volume. The only solution that I can think of would be to have a nonlinear volume remapping, for example funscript volume 0-10 would be remapped to 0-0.5, and 10-100 to 0.5-1.0, but possibly using some kind of smooth curve.

So the question is, would it be possible to add some kind of volume calibration when setting up Restim? I think it could be a good idea to try to standardize what different funscript volumes are meant to feel like.

[edger477]

Another thing is that I want the nerves to rest at some points in the funscript, so that they regain their sensitivity, and I'm not sure if I get that with my current calibration where funcscript volume 0 gets remapped to limit min which is 50% software volume.

Hehe this is something that in my files I abuse in some way, I don't put volume to 0, I actually put it to 60 or so where you don't really feel it but it actually still works, it keeps arousal levels high and gives ceratin feeling of rush. I also don't want the total regain of sensitivity since then the total volume progression from start to end can become very subjective.

[diglet]

I recently thought about this in the context of FOC-Stim.

FOC-Stim being a device with absolute volume controls is really nice, you can experimentally determine the volume which causes you to climax with decent accuracy, it seems to be about 10% range between sessions (for science ). At the start of every session you set the volume to that level and then you climax when the funscript approaches 100% quite reliably.

When the volume decreases, the current in FOC-Stim decreases linearly. I start to feel something at like 10%. I don't remember the exact figure, but there is about a factor 10 difference between the detection threshold and pain/cum threshold.


It's not so nice with a stereostim box. The box controls the voltage and there are many factors (winding ratio, voltage, electrode material, electrode size, moisture) that determine the current. So it's possible you don't feel anything at 50%. Everyone that tried the FOC box seems to agree the volume range is less compressed with FOC (meaning increasing from 80% to 90% results in a much bigger increase in signal strength on stereostim than on FOC). This is particularly noticeable with mistress and the remote control box. The 'good boy' sections don't pack much of a punch on FOC.

There are two ways to fix this. Option 1 is to keep FOC-Stim as-is and define volume as linear with current. This makes it exceptionally easy to program future boxes (neoDK, noisy cricket..) with identical volume ramps. The disadvantage is that this breaks all existing funscripts since they were made for the nonlinear response of stereostim boxes as Edger477 points out.

The second approach is to apply some sort of calibration adjustment to FOC-Stim so it has the same wacky volume-intensity curve as stereostim (or more accurately, one particular stereostim box which I characterized at one particular frequency). Initially this sounded like a good idea because it allows us to re-use all existing .volume.funscript, but I'm not really a fan. It seems nearly impossible to agree on a standardized curve because it depends on so many factors.



If you want to make volume funscripts today, I recommend using the full 0-100% range in restim and take Edger477's advice. I don't want to create a situation where every funscript requires different restim settings, that would be annoying.

[darthjj]

Hehe this is something that in my files I abuse in some way, I don't put volume to 0, I actually put it to 60 or so where you don't really feel it but it actually still works, it keeps arousal levels high and gives ceratin feeling of rush. I also don't want the total regain of sensitivity since then the total volume progression from start to end can become very subjective.

Has this been tested btw? Because I could easily see the opposite being true as well, i.e. how much and how quickly one adapts to stim varies, so the ramping needed to compensate would be individual. And if that is true, resetting back to baseline between chapters, could give a more uniform experience since the initial volume is something the user has calibrated.

In either case, I think having a non-linear volume map and a way to calibrate it would be good. You could still do the "active but unnoticeable" signal if you want that, but it might be at volume 10 instead of 60.

[edger477]

Has this been tested btw?

I only have anecdotal evidence from one user :D

In either case, I think having a non-linear volume map and a way to calibrate it would be good.

I fully agree, having just one mapping point (i.e. funscript value 10 - configurable maps to volume value 50 - configurable) you can do whatever you want (set dynamic range of script quickly to wherever you feel like it).

But we could easily make a python "converter" that does that, you input it volume funscript and it spits out the adapted one, if you would use that I can make one.

[darthjj]

There are two ways to fix this. Option 1 is to keep FOC-Stim as-is and define volume as linear with current. This makes it exceptionally easy to program future boxes (neoDK, noisy cricket..) with identical volume ramps. The disadvantage is that this breaks all existing funscripts since they were made for the nonlinear response of stereostim boxes as Edger477 points out.

This sounds like just the way I want stereostim to also work, i.e. what I wanted to achieve with the volume map and calibration. Breaking changes are unfortunate, but sometimes it's better in the long run :) To make it easier to talk about, let's call this "linear" (becomes noticeable at around 10%) and the stereostim volume curve as "stereostim" (becomes noticeable around 60%) for now. Even though there isn't a huge number of Restim scripters, I think it might be difficult to get everybody to do it the same way, so perhaps the most flexible solution would be to implement remapping in both directions in Restim. That way you could play linear volume funscript on a DIY box, and stereostim volume funscript on FOC-stim, and get a similar experience with minimal effort from both the user and the content creator. Funscript files already have a metadata field where it's probably possible to add a new tag describing which volume curve it targets.

It also ought to be quite easy to write a converter script to remap existing files if one want to do that.

[diglet]

That sounds good. What I want to do is introduce a new funscript (xxx.intensity.funscript ?) that is a linear map to the signal current adjusted for a few factors (mostly carrier frequency, possibly pulse width/frequency). And then have some default conversion between .volume.funscript and .intensity.funscript, that can also be customized if we want. If both are present it will pick the best one for your device.

There are a few other details I need to figure out. NeoDK needs to have the signal generation redesigned from the ground up, which probably involves replacing pulse width and pulse frequency funscripts with something else that has a better mapping to the actual sensations you feel. This sounds like a good time to implement the volume/intensity funscripts as well. Anyway, it will take a few months to get there, don't want to rush things and redo it again next year

[edger477]

That sounds good. What I want to do is introduce a new funscript (xxx.intensity.funscript ?) that is a linear map to the signal current adjusted for a few factors (mostly carrier frequency, possibly pulse width/frequency). And then have some default conversion between .volume.funscript and .intensity.funscript, that can also be customized if we want. If both are present it will pick the best one for your device.

There are a few other details I need to figure out. NeoDK needs to have the signal generation redesigned from the ground up, which probably involves replacing pulse width and pulse frequency funscripts with something else that has a better mapping to the actual sensations you feel. This sounds like a good time to implement the volume/intensity funscripts as well. Anyway, it will take a few months to get there, don't want to rush things and redo it again next year

This sounds like future "intensity" will be some "envelope" for signal (i.e. pulse width * pulse voltage * duty cycle or something like that) and restim/box cares about increasing/decreasing voltage when we alter width/frequency etc?