I released Intiface Central v3 last night. This is the culmination of ~3.5 years of work, most of which won’t be very obvious to anyone who isn’t working on developing Buttplug software. Almost all of the changes are in the backend, in how clients communication with servers, how we deal with configs and backward compat, etc… Boring but very important stuff.
One big addition is that our sensor system now actually works. We can get depth/pressure/etc data from hardware that supplies it. Just don’t get your hopes up too much there too begin with, as most of the hardware that has sensors doesn’t do a very good job in presenting the info, but it’s a capability we’re hoping more developers will leverage soon.
Now, that said, this work had been blocking literally everything else since 2023 (which is why I’ve been so grumpy and turning down all new feature requests for the past 3 years. Note that this release will probably not change the grumpy part.). You’ve probably noticed that there’s been no work on UI/UX in Central, no real new features in the system, etc. We’ve been plodding along with our vibrate/rotate/linear movement framework while constantly spinning on this new stuff in the background.
Now that this is all released, we can get back to trying to make life better in other ways. Initial plans include:
Documentation for Intiface Central, so you can finally know what all of the random UI actually does.
Actually show what devices are currently doing in Intiface Central
Creation of simulation devices for testing
Creation of prebuilt configs for TCode Devices (one-button additions for OSR-2, SR-6, SSR-1, as well as custom configurations for complicated/multi-part OSR-2/SR-6 configuration)
Implementation of a REST server so you can control devices from plain ol’ http.
Other small tool implementations and centralization in Intiface Central (like possibly trying to do cross-platform audio processing?)
If you have anything you’d like to see, now’s the time to throw it out, while I’m working on roadmapping. Please feel free to throw ideas in this thread, and I’ll try to let people know what is/isn’t viable.
First off, great work to you and everyone else involved. Happy to see you guys planning ahead for new features.
I have a question about the rest server idea. I will preface my question with telling you I have just about no idea how most of this works.
The question is if it would be possible to connect lovense games with http options to the server you’re planning. I’ve been looking around and trying to alter a spoofer to work for the handy. But as I said, I have no clue how most of it works so no luck there.
Absolutely stellar work! Can’t wait to give it a go. I’ve been having issues using the Handy on the latest firmware via Intiface - is this likely to work better in this version?
The question is if it would be possible to connect lovense games with http options to the server you’re planning.
The REST server is a direct translation of our own system to something that’s a little easier to access for some devs, so it doesn’t really have anything to do with Lovense’s systems.
That said, I’ve heard several devs in the community are looking at lovense game mode emulation.
I’ve been having issues using the Handy on the latest firmware via Intiface - is this likely to work better in this version?
Yes, we’ve updated to using the newer Handy protocols, that also work with the Oh. This means you no longer need to use legacy bluetooth mode on the device.
Thank you for everything you do for the community. I have something that might possibly count as a feature or might be wildly off base, but this seems as good a time as there is to bring it up.
When using the fantastic unofficial firmware for the original launch(Play "Handy" scripts on a Fleshlight Launch), it’s 150ms command delay is removed and using it with older versions of scriptplayer which enable direct connections and the setting of parameters manuallly, I have had great results (much better than I personally get from my handy 1) from setting a minimum of 35ms or sometimes a bit less.
When connected via intiface however it performs like the 150ms limit was still there (which is to say absolutely terribly with almost all modern scripts and game content)
I believe you have previously mentioned that the launch has a fine-tuned custom implementation that some other contributors worked on in the early days instead of a generic implementation that other devices get. Is this likely to be the culprit of the still limited performance?
If so, is it possible to get a setting in intiface to treat a launch as a generic device instead of using the old custom profile that was made for the official firmware?
I read your post a few months ago about the powerblow. Just wanted to say, sorry for all the entitlement of some users and sorry if this message is already bothering you.
I just wanted to ask: if i understand correctly, will the new version make an implementation of the powerblow easier?
A prebuilt TCode config for Tempest MAx’s T-Vibe would nice to have, but most people even know it exists. When I was looking it up to find the name I realized it wasn’t even on the IoST Index (I just put in a feedback request for it)
Here’s the Thingiverse page for it:
BTW if anyone wants to actually make one, if the vibration motor you use can be safely run on 5V power you can skip the battery pack and make it bus-powered by connecting the Romeo’s onboard 5V and GND pins to the VIN+ and VIN- respectively.
If so, is it possible to get a setting in intiface to treat a launch as a generic device instead of using the old custom profile that was made for the official firmware?
So actually, pretty much all of our stroker implementations that use “PositionWithDuration” (aka “LinearCmd”) that don’t implement the controls in their own hardware are derived from that first Launch implementation. Basically, the problem is that instead of the hardware taking a goal position and time, these devices, including the Launch, took a combination of “speed” (with no actual measurement units) and “position” (same), with no relation to time. We had to figure out that last variable ourselves.
So I guess the question is, what does the new Launch firmware take? We may just need to make an extra protocol implementation for that takes advantage of whatever that firmware allows.
Also: Any clue of how many people are actually using the launch with this new firmware? I think I still actually have a new-in-box launch kicking around my storage, heh.
Yeah, for Tcode, the plan is just to provide a bunch of prebuilt settings for Tempest’s builds, as well as what’s available from YourHobbiesWhateverItIs, FunSSR, etc… So you can select the device, the serial port, and just go (versus the nightmare it is currently). I’ll try to remember to add this to that.
I don’t have the technical knowledge to understand what exactly you did on the back end to cause this, but with v3 the Keon is noticeably more capable of a device. Mine can actually do slower scripts now, as well as keep up with some faster scripts(not all though), at least with what I’ve been able to test through FapTap. Definitely a lifesaver of an update, this’ll hold me over until I can get my hands on a Handy
The major problem with the powerblow is that it isn’t a device that directly does a thing. It augments another device that does a thing. We… don’t have a good way to communicating that to devs that use our library, because out of the ~750 devices we support, it’s the ONLY one that does something like that. Even the pressure cap on the OSR-2/SR-6 is part of the device in our eyes, not a completely separate one.
Without a way to communicate what that does and how it needs to work to devs making apps/games with buttplug, it basically would just get left out of support and the devs would get yelled at instead of us. So we’ve just kinda left it until we can figure out what to do.
That said, the major problem here is that buttplug works at the wrong level for this, but also, the way buttplug is presented makes it seem like it’s supposed to handle everything. It’s not and it can’t. What we need in front of the library is a light scripting or config layer so that users can combine whatever they want and make that aggregate thing look like a single device (so for instance, you could have a script that combines the Keon and the Powerblow in a way that apps/games think they’re just controlling the stroker but the powerblow does pressure regulation too).
Now that this release is done, I’m doing more thinking about how to make that happen. It’s not an easy problem, but it’s also been tackled before by places like Xtoys or buttplug projects like Beadi and playfulplugins. So just gonna take some thinking.
but with v3 the Keon is noticeably more capable of a device.
… Huh.
Overly technical answer ahead:
The only thing I can think of that we changed there was the way we do bluetooth communication. We now regulate how many packets we send to a device in the server versus expecting devs to know how to do that (we do not give them programmatic feedback to know this because we don’t get it either; like I cannot tell you when a device receives a bluetooth packet without a ton of latency in my answer. BLE sucks.), so we now give the device a chance to stay up with the commands being sent. With Bluetooth LE, if you send too many commands to a device it’ll just lag 'til it gets them all, which different devices deal with in different ways. We’re still dialing our solution on this in, but glad it’s already working better.
^ This is the reason for @Novice’s issues above, if I am reading this correctly, the limit is one message every 75 milliseconds?
The new Launch firmware tries to negotiate down the BLE connection interval to the minimum of 7.5ms so old versions of ScriptPlayer (and older versions of Intiface I guess) can reach much higher speeds. Protocol wise it is practically identical to the old Launch, it does expose some new BLE handles so you could tell it apart from the original if you wanted to.
Thanks for the answer. Sounds like a pile of work. I’ll just keep my eyes glued to the updates and hope someday the powerblow won’t be a useless piece of ..
Ok, so, the good news is that I think I built in an override for this because I figured this would happen.
The bad news is, I haven’t tested it yet, and until I get UI in, it’ll take hand editing stuff.
In (assuming you’re using windows) c:\users\your_user_name\AppData\Roaming\com.nonpolynomial\intiface-central\config\buttplug-user-device-config-v4.json, look for the launch definition, there should be a block that looks like:
Whether this will work, I dunno, I need to build both tests and UI for it, which I’ll try to have in for 3.0.1 (You can also set feature position reversal in v3, and it’s also missing UI to set it in the GUI ). But it’s something you can try for the moment.
To be clear this has been a long-standing issue I’ve had and I haven’t had a chance to try 3 yet (opportunities to use such a noisy machine being very rare for me), so I doubt this change is the culprit, though if the keon is working better it seems possible the launch might benefit - although maybe it got worse too. I clearly have some things to try whenever the next chance turns up.
One passing thought though, how was 75ms chosen? It at first glance at least, seems a little high? given the Handy 1 for example is supposed to be rated for 10 strokes\second, which would be 50 ms intervals, or does it and other devices actually struggle with that rate when using bluetooth? which to be fair it sounds like at least the keon does!
~75ms is the default connection interval on windows I think? It’s been months since I wrote that code but my reasoning was either that or just saying “this is what works for ‘most things’”.
I’ve got a lot of revisiting and refactoring to do since this whole thing is shipped heh.
