New estim tracks for CH videos

[edger477]

then I take that as a sign that I'm missing important features.

Don't, that is exactly what I tried to say but seems missed the point.

My point is that funscript format can hold information about stroking sensation (their speed/intensity/position).

Sometimes they create files that have no stroking at all. Information that cannot be encoded into funscript. You are running fft and saving that information, and probably can reduce whole file to several lines that numerically describe each section, and you sound like you know well what you are doing, I think your time would be better invested into doing that. It does not have to be funscript file, just create a new format that your tool will support. If format is straightforward, then DPL can use that to describe and create new files, maybe even their job will be easier if these sections can have proper parameters (ramp, tremolos, stroking), and if you do fft then you can describe one section with more than one line of new format (if there are 2 signals that are in superposition).

Also their files often change carrier frequency throughout the file. That too introduces case for new format even if is just a file composed of 3 different funscript converts on different frequencies.

[diglet]

I created a new release which runs a command server on TCP/UDP port 12347, which can be used with ToySerialController, let me know how it goes.

https://github.com/diglet48/restim/releases/tag/v1.2.0


@edger477 I think we agree on most counts, but I have a slightly different viewpoint. From my point of view, a funscript describes the sensations felt, and it's up to the software or hardware device to generate the corresponding audio or device movements to best reproduce the sensations. If we think that vibration maps well to tremolo, we can add xxx.vibration.funscript and use that to control tremolo. If we think carrier frequency is an important component for scripting, we can add xxx.frequency.funscript. The challenge is figuring out which abstractions leads to the best scripting experience.

DPL might not have intended for his stimfiles to contain stroking sensations. But at the end of the day a stroking sensation is just a change in relative amplitude and phase between L/R, which can be 100% described with xxx.alpha.funscript and xxx.beta.funscript. And indeed, analysis show that the majority of [Vi89]'s variations in phase consists of relatively simple movements in alpha/beta space. When I run analysis about the carrier frequency and modulation frequency on DPL's files, I can clearly see that this part of the file uses 25hz modulation and that part uses 41hz. This would be easy to control with a separate modulation_frequency.funscript and carrier_frequency.funscript. I might be missing something, but this all sounds relatively trivial to implement. I'm wondering what other things there are that I can't see.

I actually did some tests with carrier frequency control via funscript, and my conclusion was that the impact is marginal at best. But this definitely needs more testing.

I'm sticking to the funscript format for compatibility with existing software, in particular MFP and OpenFunScripter.

[Niceguy_LondonUK]

I created a new release which runs a command server on TCP/UDP port 12347, which can be used with ToySerialController, let me know how it goes.

https://github.com/diglet48/restim/releases/tag/v1.2.0

Hi Diglet, thank you for doing this... and so swiftly... What settings do I put into the plugin? Its asking for an IP address and Port number?

I've tried 'localhost' and port number 12347, and I keep getting an invalid IP address error?

Can you let me know.

Thank you.

Niceguy.

[diglet]

As far as I can tell, it should work with localhost or 127.0.0.1 in the address field, and 12347 in the port field, but I don't have VAM to test.

Do you see the message "UDP server active at localhost:12347" in the restim console on startup? If you see an error instead, there might be another application using this port.
Can you try connecting multifunplayer to restim with an UDP target with these settings? (test if the green dot moves). These settings work on my machine.

[Niceguy_LondonUK]

I've used the Ip address 127.0.0.1 and port 12347 in the plugin and can see the green dot in Restim responding...to the action in the scene... I haven't hooked myself up to it yet... but looks promising!! I'll report back.

Niceguy.

[edger477]

I tried MFP + restim last evening. I am not sure I understood the calibration screen, it seems it is fixed and the right image is not interactive nor it does anything? The left one is nice and I like how you mapped visualised representation of output.

I have feeling that most of my feedback was due to not knowing how to configure something.

I did notice some desync between image and signal when I switch calibration shape to circle and increase speed to 3-4.

I noticed almost no difference when moving center volume from -0.7 to 0.
All funscripts I have are one-axis so I only tested that. I did not find a way to remap vertical movement of single-axis funscript to anything else, and moving the green dot left or right seems to have same effect as changing left/right volume on amp.

The biggest issue I experienced is inability to sync properly with on-screen movement. For CH videos where the funscript is synced to beats that is not a problem but for pov videos where it is supposed to sync with what you see is immersion breaking.

I have bluettoth box, so there is some latency there. For example, I used Halcyon Daze, which has some nicely synced movements in acompanying mp3 after 1:50, and those perfectly sync with estim in Script Player, where I have -500ms offset for estim. In MFP I tried with offsets of 0, -.5, +.5, -1 and +1 and none seemed to help with making the sensation closer to the screen, I could not even figure out whether is before, after or random. I also tried inverting the funscript in mfp but did not achieve anything.

I tried to check without using output, and the green dot and the mfp visualisation match, and on offset 0 they perfectly match the screen. However I am not sure if MFP counts the offset same as ScriptPlayer (-.5 being playing script half second ahead of screen), and how big buffer you use in restim? I remember doing pull request for ScriptPlayer to increase desired latency of sound device from 50 to 150 (to eliminate crackling), and I use -500 to accomodate for additional latency introduced by bluetooth. Do you know what is the latency of your sound generator, or what eyeball value should I try for offset in MFP?

EDIT: I used restim.exe, but that seems to not contain the calibration gui?

EDIT2: I now see I missed that alpha and beta scripts are required... I will try again next time... I thought convert tab is to produce mp3 :D

[edger477]

Ok after being dumb and not reading the "mfp setup" page... I now configured L0 and L1 as instructed, and converted the funscript.


Now, before I try this, how do you do calibration? Play circle and then go to fine tuning and tune it until you get average sensation during whole circle? Reduce all to 75 before start then go from there?

[diglet]

I did notice some desync between image and signal when I switch calibration shape to circle and increase speed to 3-4.

That is correct. The green dot moves immediately when a command is received from MFP, there is a delay before the audio is actually output, I measured 260-280ms (May be different on your machine, depends on hardware and drivers). A delay of -0.30s in MFP works well for my setup, I think bluetooth adds 200ms more, so -0.50s?

I'm working on some latency and display improvements (configurable display and audio driver latency) right now.

An easy way to measure the audio latency: output to speakers, setup a recording in audacity. Use the mouse button to change the position in the left diagram, and then measure the delay between the mouse button sound and change of speaker sound in audacity. This works better if you have a loud mouse. Restim adds 40ms for commands received over tcode to interpolate the position smoothly.

EDIT: I used restim.exe, but that seems to not contain the calibration gui?

That's old code, no longer used.

Now, before I try this, how do you do calibration? Play circle and then go to fine tuning and tune it until you get average sensation during whole circle? Reduce all to 75 before start then go from there?

I set the modulation to 60hz at 100% depth. Then I use the circle pattern with low speed and adjust the calibration values (neutral and right) until the sensation is equally strong in all locations. Then I use the mouse "pattern" to adjust the center calibration. My last session used -6.4 for neutral, -0.8 for right and -0.7 for mid. (same electrode setup as fileflax).

It's a bit fiddly the first time you use it, on the next session it's much easier, I simply enter the approximate values and then I adjust during play. The graphic on the right shows a visual of the calibration parameters, but it's a bit hard to interpret. I will probably scrap it at some point because it's not very useful.

Volume tab is self explanatory.

Ignore the fine tuning tab.

[edger477]

Ok so don't use restim.exe? Get python and build myself?

Also, feature request: ability to convert all funscripts from all subfolders that don't have -alpha and -beta, or at least, when you press ... to open folder, open it in the folder that is in the current path (last file converted) so it is faster to manually go through all of them.

:)
Thanks

[diglet]

Ok so don't use restim.exe? Get python and build myself?

no no no. Get restim.exe. You don't need to run from source.

I demo'd a calibration GUI a month ago, I thought you were asking about that.

Also, feature request: ability to convert all funscripts from all subfolders that don't have -alpha and -beta, or at least, when you press ... to open folder, open it in the folder that is in the current path (last file converted) so it is faster to manually go through all of them.

Good idea.

[edger477]

Now that I have seen how this is configured, I have another idea.

I don't know if you checked out @Rillo's work, his videos mostly have dual-channel estim, and he does very nice work syncing the stim to music. Example: viewtopic.php?t=26040

Now, when I saw your .alpha and .beta funscripts... gives me idea, maybe we don't even have to use restim but I want first to put it out there... if we add another device in MPV, that would take dual-left and dual-right as funscript names, then we could reproduce the dual channel estim from them. But maybe we would need 2-axis for each (one for amplitude and other for frequency modulation). I am now assuming that whole file has same carrier frequency, which is a compromise Rillo might accept in future if he could use funscript tools to produce estim (I think it might be faster and easier than Audacity).

[diglet]

There are vague plans to offer multiple audio generation algorithms.

For threephase, the inputs are alpha/beta, I spent a long time thinking and this is really the best solution. We can add carrier and modulation. But it's impossible to specify the carrier frequency separately for the left and right channel (too many constraints).

For dual channel, the strict control of the relative phase between the left and right channels can be dropped, this gives us one new degree of freedom: the ability to choose different carrier frequency for the left and right channel. So you would have carrier, volume and maybe modulation separately for each channel (however many channels you want).

This actually is quite easy to implement. The annoying part is the GUI stuff.

I also have plans to look at 4-phase or 5-phase algorithms, but it will probably take a long time to figure out how to generate such signals, if it's even possible.

[edger477]

The annoying part is the GUI stuff.

I imagine different version of program (on another port) might be easier to maintain for dual channel, and gui could be 2 boxes like the triphase one with a dot that shows volume axis and freq modulation axis, one for each l/r channel. You could have both running but current listens for L0 and L1 axes, while the second could use some other ones, so you only start audio in the one you are wired for.

Maybe carrier frequency could be fixed (same as now) since if one axis is for amplitude and one for frequency modulation, you can increase/decrease frequency with it.

I think with funscript frequency of 60hz you can describe practically any effect they are using.

And can you add icon for taskbar so it looks like i.e. that circle with red black red dots instead of windows default one? :)

[edger477]

Also, am I wrong, or restim has no setting for ramp up duration for when there is no movement received and then starts, and ramp down duration when it stops?

[diglet]

I prefer to integrate it in one app.

I like using amplitude modulation with 40-80hz frequency, there are some theoretical reasons (higher neuron activation rate) why this is better than no modulation. This would be impossible to script with funscript, also scripting amplitude modulation via volume control in OFS would be a terrible experience.

There is no automatic ramp up/ramp down on inactivity. I think this is a very useful feature, but potentially dangerous, really want to take the time to build this in such a way that it's safe with all possible interactions in the program. As a workaround, you can use the auto home feature in MFP to move the position somewhere less intense.