So, a random idea occurred to me while responding to another topic in this forum regarding using the GHR with actuating toys. The majority of games out there output only vibration which is useless when using actuating toys with the GHR. It got me to thinking though, how would we make actuating toys work with the GHR if we could?
I mess around with making custom funscripts for videos on occasion and find them a pretty versatile and robust way of making actuating toys work since they’re highly customizable to personal preference and toy setup for a coding simp like me to mess around with in funscript editing software and thought, “what if while you play your game and it outputs different vibration intensities, the GHR played different looping funscripts when the vibration hits certain ranges or thresholds that could be customized by the user?” It got me to thinking more and I thought, “what if for each game you hook into, there was some sort of customizable profile saved in some sort of exchangeable and easily editable file format for the toys and their associated customized vibration-triggered funscript patterns?” I don’t know how much work this would be for qdot and co. to implement for the GHR, but would it be possible for there to be some sort of “funscript profile system” like above to be added to the GHR?
If the idea is too crazy to implement; no problem. Just throwing out an idea! 
Funscript is way too limiting here. This needs something that can do actual signal processing that also is user customizable. Basically, a user accessible programming language. XToys already does this with blockly and it works out pretty well. I’m looking at something similar using dataflow languages (aka a “lines and boxes” interface), though it won’t be built directly into Intiface (because intiface needs to stay simple since hardware is already complicated).
Thanks for the reply and your perspective on the matter q!
I’m pretty sure when compared to an actual programming language, funscripts are indeed probably more limited in what they can do to process the vibration signal into actuating motions. But then again, to the average user enjoying their toy via GHR, do we really need anything more complex than a looping or singularly played funscript to add to the experience? The reason I was thinking funscripts is simply because there seems to be a larger community of people currently familiar with how to make them given the popularity of that format for videos and due to that popularity might be more intuitive to the average user to work with if they want to customize their gaming experience. I mean, if you wanna make an actuating sex toy mod for a game using vibration signals, but then need to learn a new programming language to do it, it might turn a lot of users off on making that mod for the game to begin with if you know what I mean. Funscripts on the other hand are really easy and intuitive to learn and make things with using the funscript editing programs out there (I literally learned how to make them work in a few hours during a weekend afternoon). Plus, there are a lot of games out there and not all users wanting to add actuating sex toy support in said game’s modding community may be interested in learning how to code unfortunately…
In any case, whatever you are working on right now for making actuating toys work with vibrations signals sounds interesting especially if there is some sort of visual scripting or well-designed GUI program that comes with the language that the average user can use to manipulate the code with.
Good luck with whatever you’re working on q! 
So…
Just thought a little bit about new features that could be added to the GHR that would make it better interface with all the games out there.
One thing that occurred to me looking through all the games that I like randomly window shopping on the various platforms I frequent is that a surprisingly small number of games (including AAA ones oddly enough) nowadays actually even bother to add rumble output at all unlike in the good ol’ days of gaming back when I was a child! 
(And don’t even get me started on how pretty much NO NSFW/Adult themed games which are mostly made by small indie devs have the time or money to bother adding rumble into their games yet unfortunately would be really good fits for the GHR!)
So, that got me to thinking more… In addition to something like a way for funscripts to play in response to certain rumble signal intervals outputted by the game (and possibly even a way for those script values to be modulated by the outputted rumble signals maybe…), could there be some feature added to the GHR that can control the toys (possibly via funscript) via sound or audio cues isolated from the game saved in some library of isolated sounds or something or perhaps a way to watch for certain UI elements to trigger patterns/vibrations? (since frankly those two are the only other output options out there for games to really interface with something like the GHR if no rumble output is present. Otherwise, we gamers will just have to market pressure game devs into adding rumble or weird niche features like gamelogs for the GHR to watch for game events which may not work… Or I guess there’s modding and hacking, but I assure you modders and hackers can be very unreliable people… 
)
P.S. Congratulations @qdot on finishing Intiface V3! 
I hope you’re okay and less grumpy now that the ~3.5 year ordeal is over!
Okay, yes, less grumpy, no.
So, that said, yeah, this is a fine idea, and is basically what I want to grow the GHR into. To abstract it a bit more, we should be able to take game events through some method (rumble events, sound tracking, mods w/ some sort of IPC, etc) and turn those into whatever the user wants. This was originally the idea of buttplug (I pitched it in 2007 lol), then we got mired down in the device control part for a decade. It’s what things like XToys and PlayfulPlugins do now, and they seem to have pretty good luck with it.
Now that v3 is done, we’ll see if I can actually get anywhere with that. Not quite sure what it’ll look like yet though.