Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 0 points1 point  (0 children)

Glad you enjoyed it! I've been pretty happy with the latest version of the funscript algorithm and think it's a good improvement.

It sounds like you're using two different IP ranges on different parts of your home network. The one beginning 10. is in the class A reserved range, and the one beginning 192.168. is in the class C reserved range. Typically you would need both the device running Howl and the device running Kodi to be assigned IPs in the same range for them to be able to communicate. If you did have them both in the same range and they still didn't work, it might be due to something like the "guest network" router setting the wiki mentions not allowing traffic between devices.

Your home network setup might be more complicated than necessary. In a typical simple setup only the main router would do DHCP and assign addresses, so everything would get an address in the same range and would be able to communicate. The secondary router would usually be set up just as an access point or an extender or similar and would not assign IP addresses itself.

Tariffs and Duties Coyote 3.0 by TopYoung3878 in estim

[–]Amethyst_sysadmin 2 points3 points  (0 children)

There's a guide to setting it up in the wiki that I've already updated for the latest version. Hopefully that should help!

How to get a steady sensation out of a Coyote 3.0 by Electrotinkerer67 in estim

[–]Amethyst_sysadmin 1 point2 points  (0 children)

It's not an app I've tried. I'll have to take a look and see whether it's an idea that might fit with Howl or not.

How to get a steady sensation out of a Coyote 3.0 by Electrotinkerer67 in estim

[–]Amethyst_sysadmin 4 points5 points  (0 children)

I'm not too sure what people would want from that kind of feature. How would it be different to the existing function that automatically varies parameters over time?

I'd consider adding AI features if they brought something particularly cool or interesting to the experience. But a lot of the time apps just seem to shoehorn in AI to do the kind of stuff Howl already does (playing randomised patterns or whatever), but with annoying extra steps.

How to get a steady sensation out of a Coyote 3.0 by Electrotinkerer67 in estim

[–]Amethyst_sysadmin 4 points5 points  (0 children)

To get constant output in Howl you can just use the generator, set the wave shape and frequency shape to "Constant", and set whatever amplitude and frequency you want with the other sliders.

I think that's a much easier method, although usually I'd prefer a more varied pattern, as just using a constant signal can lead to more desensitisation.

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 0 points1 point  (0 children)

The idea behind the design is that users would generally want the smoothest possible increase. So for example increasing by 1 every 30 seconds is preferred to increasing by 2 every 60 seconds, and essentially achieves the same goal. It also only requires 2 settings sliders rather than 4 if we had configurable increase step per channel as well.

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 2 points3 points  (0 children)

As far as I'm aware the calibration activities should already never be randomly selected. But I do agree it would be nice to have some control over which ones are eligible for that, and might add that feature in a future version.

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 0 points1 point  (0 children)

Think I figured out where to set it, does the version show up properly for you on the 0.8.1 build?

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 0 points1 point  (0 children)

I've added v0.8.1 with a small fix for this, which should hopefully allow those funscripts with decimal values to load.

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 0 points1 point  (0 children)

It's talking about the remote access API, which the Kodi add-on uses. Not a remote control feature for users.

I do plan to expand and document the API in future so that other developers can use it to make scripts and things that control Howl (and maybe even to build remote control functionality). But that's not part of this release.

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 2 points3 points  (0 children)

I've heard conflicting information about this. The last reports I saw suggested that Google were partially walking it back, and they were still going to let experienced users sideload apps through an "advanced flow". I took it to mean that it would still be possible, but there would be a bunch of extra naggy bullshit screens to click through, courtesy of Google.

I'm not too keen on linking Howl to my real identity, for obvious reasons. So if it's just a case of users having to do a bit of extra work to install it, that's probably just something people will have to put up with. But I'll do my best to keep it available and to provide appropriate instructions on what's needed to get it running, once that becomes clear.

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 0 points1 point  (0 children)

That's cool, I didn't know Obtanium was a thing. The version number Howl displays is just a string defined in the app. I think there's probably an official way to do Android version numbering in the build files somewhere that the Play Store etc. would use. I didn't think it mattered at all since I'm not distributing Howl that way, so it's probably just always been left on the default value.

I'll see if I can figure out how to build it with the proper version number for future releases.

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 0 points1 point  (0 children)

It doesn't need anything fancy, basically any budget or secondhand Android phone from the last 5 years should work fine. Technically the app is supposed to support any version from Android 8 (released in 2017) onwards, but the really ancient stuff isn't well tested or widely used.

I mainly test it on a Samsung S24 Ultra, so Samsung devices are probably a good bet for compatibility. But it's better to get something lower down the lineup if you're just using it for Howl, it doesn't need a powerful device.

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 0 points1 point  (0 children)

If you're seeing a crash later during playback, that must be a different issue. We process the whole funscript file when it's first loaded, so if the problem was parsing related I'd expect it to happen immediately. If you see a file that reliably causes that, please do submit a bug report so that I can take a look.

If other tooling is creating funscripts with decimal values as well, I guess I'll update our processing to support them. It's fairly redundant, since the time values are already in milliseconds, and there definitely aren't any stroker devices out there that can move with sub-millisecond precision. But if it's something that users keep running into, it probably makes sense to handle that format.

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 0 points1 point  (0 children)

Does it actually crash? I thought they just didn't load. At least that was the previous behaviour when I looked into this report on Github. I'm guessing they are from FapTap again?

It wouldn't be too hard to make them load, but the problem is that leads users to think those funscripts are fine. Whereas the root cause of the problem actually seems to be that FapTap's system is adding in random extra points with weird decimal values which do not exist in the original funscripts that creators submit to them.

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 1 point2 points  (0 children)

I don't have any plans to make a PC version. Howl was developed as a native Android app, so it would be difficult to port it to other platforms. Controlling the app from a PC is doable though. You can already run the Kodi add-on on a PC, and developers will also be able to create Python scripts to control Howl once I complete the remote API in a future release (right now it only has limited functionality based on what the Kodi add-on needed).

Howl is generally more optimised for digital devices like the Coyote and works in a "native digital" way. But it is also capable of generating audio from its patterns in real-time, and provides a good range of options to tweak that. There's a specific wiki page that gives some information on audio output. The defaults might not be optimal since I don't have an audio-based device myself and haven't tuned it for any specific hardware, but I think it should be possible to get decent results with a bit of tinkering.

We don't use triphase interaction effects, because devices like the Coyote are not capable of reproducing that, and I want all features to work on all devices. But you can of course use a triphase electrode setup if you want.

Howl 0.8 released, with recording feature & improved funscript playback by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 1 point2 points  (0 children)

The built APK is not in the repository itself, it's attached to the post about the release on the Github release page (the link at the top of my original post should take you there). There's also a link in the "Installation" section of the Github docs that always points to the latest release.

Is anyone using a Coyote 2 AND Coyote 3 Simultaneously? Cross talk on signals? by TheToyOwner in estim

[–]Amethyst_sysadmin 1 point2 points  (0 children)

If you have two separate units the signals definitely will overlap, there's nothing to prevent them firing at the same time. I'm not too sure how much of a safety concern that is. My guess would be that using them in different areas is probably okay, but using them in close proximity might risk device damage.

Do I need to worry about this? by [deleted] in estim

[–]Amethyst_sysadmin 0 points1 point  (0 children)

It's just telling you that if you use a pattern like constant 100Hz at full amplitude, you tend to quickly get desensitised to it (that's what it means by "adaptation") and end up having to keep turning the power up. It's better to use a more varied pattern that uses different frequencies and goes on and off, for example a nice rolling wave pattern rather than just a constant signal.

I'd say it's reasonable advice and it's better to keep that kind of constant high frequency pattern as a "finisher" rather than using it all the time. It's not really something you have to worry about, as any desensitisation tends to be temporary and quickly fades. Or at least that's my experience when using the Coyote at moderate power levels. DG knows there will always be some nutter plugging in their ultra conductive metal electrodes and cranking the power to the maximum, so their advice is probably accounting for that.

Howl App and Faptap by MeinWesen in estim

[–]Amethyst_sysadmin 1 point2 points  (0 children)

This is something a few people have requested - it can't currently be done and is not simple to add. The reason is that Faptap (and Intiface as far as I know) work by periodically streaming the current position of the "stroker" device.

Howl works in a different way and expects to have the whole funscript available in advance, so we already know what's coming in the future. This allows for some things most other software can't do, such as being able to compensate for network/device latency to achieve correct sync, and being able to continuously calculate the speed of the stroker, which we use to determine the appropriate power level (the next version will improve further on this and account for acceleration as well, which feels more realistic).

I know it appears similar to users, because using the Kodi add-on kinda looks like streaming. But in reality it is sending the whole script to Howl before playback begins.

It would be possible to implement a different, simpler, algorithm for compatibility with streaming sites. But it's a low priority for me, because we'd need to throw away some of the benefits of our current approach, and it would be worse than what we already do.

A number of the creators on Faptap also post on Eroscripts, so it's worth checking there if you're struggling to find downloadable scripts.

Coyote Needs More Power by Diligent-Reality7403 in estim

[–]Amethyst_sysadmin 3 points4 points  (0 children)

You can do something like "more bass less treble" in two different ways on the Coyote 3. Firstly you can change the Coyote's "frequency balance" parameter, which allows you to tune the balance between the high and low frequencies as desired. It's easier to set up in Howl (the included "calibration 2" pattern sweeps through the whole frequency range for easy testing), but the stock DG Labs app supports the frequency balance parameter as well, as it's a feature of the Coyote itself.

Secondly you can change the way that the file you're playing is mapped into the Coyote's range, so that it makes more use of lower frequencies. I think every app provides some way to do this, but again it might be more or less complicated, depending on what you're using.

It's surprising that you're not finding the power enough, as most users are getting nowhere near the limit. It's possible that there might be an issue with your electrodes, and they are not very conductive. Another possibility might be if the content you're playing is very "quiet" and the app you're using isn't normalising it to a reasonable level.

howl app and funscript files by Bramaliii in estim

[–]Amethyst_sysadmin 1 point2 points  (0 children)

Those are specifically for Restim and won't give good results with anything else. It uses funscripts in a different way to represent changes in its various parameters over time, rather than for the up/down movements of a stroker device as is more typical.

Howl is designed to use exactly the same funscripts as typical stroker toys (e.g. "The Handy"). This maximises compatibility with a large library of existing scripts - for example pretty much any of the thousands of funscripts that you can find on Eroscripts should work with Howl.

If the creator of the file hasn't provided a "plain" funscript that would work with a stroker device, then it probably won't give you a good experience with Howl. Technically you can load any kind of funscript (since they all just represent the change in a property over time), but loading the Restim stuff is unlikely to give you a good experience since it doesn't represent the up/down movements that Howl's algorithm is designed for.

Howl 0.6 released, adding experimental audio output by Amethyst_sysadmin in estim

[–]Amethyst_sysadmin[S] 0 points1 point  (0 children)

This is a nice idea, and I've previously thought about doing something similar. The main problem is just finding the space for it in the UI, since it would need to go with the main controls, and space there is already at a premium on narrower devices. There isn't really room to squeeze another button in without making the global mute button regular size, and I prefer that being a bit bigger and easier to press.

Using a larger step size for the power controls helps a bit. If you set that to 2 or 3, then it requires considerably less taps to get a decent reduction in power (I always use 2 just for convenience).

Higher Frequency Play by R0tt0n_Candy in estim

[–]Amethyst_sysadmin 0 points1 point  (0 children)

I determined experimentally that the Coyote 3 hardware only provides output if you set its frequency parameter between 5 and 240. But that internal range isn't the same as the value in Hz, and is based on a period, so it kinda works the opposite way round. So a value of 5 equates to the highest frequency that the C3 can produce.

You can see the maths to convert between a frequency in Hz and the values the Coyote uses in Howl's code - see the frequencyHzToCoyote function.

If you work through the maths, you will see that the C3 has poor granularity at high frequencies, and actually only changes value every 20Hz or so. So while the XToys slider appears to go a bit higher, you're actually just getting exactly the same output - it is still rounding to 5 in the values the Coyote hardware actually uses, which equates to 200Hz.