I added an automatic ramp-up feature for power intensity，i hope it can merge in master branch

[Vpn33]

As the title，I add automatic power ramp for keep edgeing with ruined。

Settings Tab's Power Ramp configuration options

Loop mode:

Repeat mode:

I have been trying to implement an automatic edge function through the DG-Lab PawPrints settings, but I haven’t been able to make it work—it only functions properly within the DG-Lab app. Therefore, I added a feature in Howl where the power intensity can automatically ramp up based on a set duration, but the duration at the peak intensity is randomized, simulating the stopping effect that triggers the edge. Currently, there are two algorithms: one resets to the initial intensity after reaching the peak, and the other gradually decreases back to the initial intensity after the peak.

Since this is built upon your existing automatic intensity increase feature, I was concerned it might conflict with your future feature updates, so I set up separate configuration options to handle the automatic ramp-up function. It is now mutually exclusive with the original auto-increase feature. So, if "Auto Ramp-Up" is enabled in the settings tab, clicking the power intensity increase button will follow the ramp-up configuration.

After you released version 0.8.1, I merged my internationalization work. Previously, you mentioned that you were not planning to add internationalization for the time being, so I couldn’t directly create a pull request. However, I still hope that this part of the code can be merged into the master branch by you. I have used Chinese labels for the configuration items in this section, so you should be able to find them quite easily. @Amethyst-Sysadmin

[Amethyst-Sysadmin]

Thanks for the suggestion. Unfortunately I'm not really a fan of this implementation. I think it adds too many options to control what is probably a fairly niche feature that most users wouldn't use. Or at least it's not something I'd use personally - if others are looking for this kind of functionality then of course I'm always open to feedback.

Changing the power levels in various ways is something that will definitely be supported by the remote API in future (once I've finished implementing that and have documented it). So if users want to manipulate the power in some specific custom way, that could potentially be done with an external script or automation rather than within the app itself.

[Vpn33]

Okay, thank you for your reply. I have also added the functionality to play waveform files(*.pulse) generated by the waveform editor in the Coyote3 APP to my fork. If you need, you can also take a look at these algorithms.

[Amethyst-Sysadmin]

Okay, thank you for your reply. I have also added the functionality to play waveform files(*.pulse) generated by the waveform editor in the Coyote3 APP to my fork. If you need, you can also take a look at these algorithms.

Thanks - it's an interesting idea, but your changes for that are adding about 2,000 lines of code, which would be a significant maintenance burden. I'm not sure how much of that is necessary since I'm not familiar with how DG's format works.

I think Howl's own HWL pattern format is both more flexible (as it isn't limited by "sections" and can represent any pattern the Coyote 3 can play) and simpler for developers to understand. If you want to play the patterns from some existing .pulse files, a nicer way to go about that might be to write a converter script that changes them into Howl's native HWL files. Then there's no need to support two different pattern formats within the app. And there would be compatibility with the tooling I've already made for HWL files, such as being syncable by the Kodi addon, and being readable by "hwltools.py" Python command line tool that users can use to join patterns together, extract a section of a pattern etc.

[Vpn33]

Yes, starting from Coyote2, I reverse-engineered DG-Lab's waveforms and performed Bluetooth packet capture analysis. Later, when it upgraded to Coyote3, I refactored my algorithm. Now, with the official app's stable version 3.5.1, they've switched to exporting pulse files. To be able to play these pulses, I've spent a tremendous amount of effort and written a lot of code. However, most of that code is for UI control – the actual file parsing code is only about 200–300 lines. Adding a wave playback feature similar to Howl's "Activity" should be quite easy to implement.

The reason I added a replica of the DG-Lab app's wave player functionality in my fork is that Coyote's waveform files do not contain channel information. You must manually assign a channel to play a given waveform. Moreover, its pulse segments are very short – usually just a few seconds or a dozen seconds – and their duration relies on looping based on the minimum playback time set in the player. This makes them difficult to convert directly into fixed files. If you insist on converting them, you can only assign them to a single channel, which doesn't really match Howl's dual‑channel playback style.

This type of waveform player has two advantages:

It can combine different waveforms by adjusting the playback mode and duration based on settings. When you have enough waveforms, it can generate long, non‑repeating, varied experiences. This kind of player is very suitable as an interface for games, text, and images – calling the player can directly output the corresponding waveforms.

The waveform files are very small, typically only tens to hundreds of bytes, making them extremely easy to store and transmit.

In contrast, fixed waveform files are standard streaming data, well‑suited for VR and audio‑video synchronized content.

Howl's algorithm is excellent. The Funscript algorithm can simulate the motion of stroking toys very well via electrical signals. As a result, after using Howl, I use it almost all the time when playing videos. However, when viewing comics or novels, I still switch back to my own plugin, because those don't have fixed time points like videos. Instead, they trigger content through rule‑based triggers, for example:

When the comic starts loading → loop play A‑xxx, B‑yyy

When the comic page turns to page 9 → gradually increase power intensity from 0% to 5%

When the comic page turns to page 10 → switch waveform to A‑www

This approach is currently not possible in either the DG‑Lab app or Howl.

That said, converting to HWL format, as you suggested, is indeed a good idea. It would allow operations similar to Audio Studio – freely combining waveform files and mixing dual‑channel output into a single fixed file. This should satisfy some usage scenarios as well. I will try to use this algorithm to create either a script (Python) or a feature (add a Tab) that can convert pulse files into HWL format.

[Amethyst-Sysadmin]

Thanks, that makes more sense with the additional context on what you're looking to do.

I think it might be possible to automate much of that with the additional API stuff that I'm adding in the next release (that's pretty close to being ready now). This wiki page has the documentation I'm currently writing, and describes how it will work.

If you're using your own viewer software (or can hook the events like page turns into a Python script somehow), then you can potentially call Howl's API to do stuff like increase the power when the event you want happens.

It's not really a use case I've thought much about, but it should be possible to dynamically create HWL files. If you have a list of Pulse objects and pack the data in the right way (similar to how the write_hwl_file in libhwl.py works), you could skip actually writing the file and just pass the data in to the API's /load_hwl function as a Base64 encoded string. If you have all the patterns you want available on the Python side (either by translating your .pulse files or some generation code), then it shouldn't be too hard to choose those at random and assign them to a random channel.

There's also a new activity coming in the next release that generates a basically infinite variety of interesting patterns (it's my new favourite). Hopefully that might provide some inspiration for making long and varied patterns in a generative way, rather than building them out of fixed patterns.

[Vpn33]

Thank you for your thoughtful response. That's great – I'm really looking forward to the new Activity!

I have used the load_funscript interface to dynamically load Funscripts, so I know that similar functionality can be achieved by dynamically creating HWL files. However, that approach still requires a unified protocol to implement the actual triggering logic. This would mean that external scripts not only need to handle waveform conversion but also take care of the trigger logic, making the scripts bloated and difficult to implement quickly across multiple platforms.

In my vision, it would be best to encapsulate the protocol part within a controller like the official app or Howl. That way, an external script could load something like an HWL file dynamically through an interface to parse trigger conditions and pulse content. After loading, the script would only need to pass trigger values when calling the interface again, thereby taking over control of the Coyote device.

I previously suggested something similar to the DG-Lab team. Their reply was that they are working on a set of modular components and interfaces – like building with blocks – that will support both PC and mobile operations. However, they didn't give me a specific timeline. I think they are polishing it from a product perspective, so the cycle will be quite long. That's why I considered implementing some features myself, just for my own enjoyment.

Later, I noticed that many people publish various video scripts on EroScripts, but there are very few good free game scripts, and almost zero for novels or comics. So I started wondering whether I could create a new protocol to support this kind of non‑timeline‑based, state‑driven content.

[Amethyst-Sysadmin]

I was actually thinking about use cases like game actions a couple of days ago as something that isn't handled very well by the current proposed API. It can be done, but the flow of loading and playing different patterns all the time is quite clunky and introduces extra latency.

One idea I had to help with that was providing a function like /preload_hwl where a user might be able to preload a bunch of patterns (which we would keep in memory) and associate a string key with each of them. Then they would just call an endpoint like /play("shoot") or /play("jump") when an action happens, and we would play the appropriate preloaded file.

It's probably not something that will make the next release, but I think it could be a good future improvement. Not sure if that would be helpful for your use case?

I think trigger conditions are not really possible, as it makes the flow quite messy and we would need too much knowledge about how specific applications are using Howl. That goes against the current design which is just that applications instruct Howl to do things and it does them. Probably the trigger logic needs to be handled in the script or application that is using Howl. Some kind of code or scripting is always going to be needed on the client side anyway just to interface with the API at all.

[Vpn33]

One idea I had to help with that was providing a function like /preload_hwl where a user might be able to preload a bunch of patterns (which we would keep in memory) and associate a string key with each of them. Then they would just call an endpoint like /play("shoot") or /play("jump") when an action happens, and we would play the appropriate preloaded file.

Yes, that would also be a very good idea. I also hope you'll consider adding a gradually changing power intensity interface, to avoid the shock and stinging sensation caused by sudden intensity changes. For example: if the incremental power intensity > (power intensity upper limit * 10%), and the current A‑channel power intensity is 10 with an upper limit of 100, then calling the interface to increase A‑channel power intensity by 10% would result in a gradual increase from 10 at a rate of +1 per second, ultimately setting the A‑channel power intensity to 20.

It's probably not something that will make the next release, but I think it could be a good future improvement. Not sure if that would be helpful for your use case?

That would also be fine. If you consider adding this, then I won't have to reinvent the wheel. It will also help keep my fork as consistent as possible with your master code, making it easier to maintain.

After all, we're both hobbyists developing in our spare time, so some compromises are inevitable. Plus, we have to consider the relationships and complexity between various interfaces. These changes aren't something that can be done overnight — I completely understand where you're coming from.

[MeinWesen]

I would also be a fan of power ramping up, then going back down. In my case I would love it if it would go up to your maximum and then reset to your "minimum". If you haven't tried it manually I would suggest it. Some of the middle power levels feel better after you've reached the max power a few times. Currently I set it to auto increase the power (at about 1 minute per increase), I then set it back to my starting point and allow it to continue. Having it do it automatically would be great.

[Amethyst-Sysadmin]

I thought a bit more about this ramping up/down feature. Can we achieve the same thing by varying the pattern power instead of the main power level? In that case we could put it in the "Special effects" menu alongside lots of other advanced and niche features.

We could call the effect something like "Power Cycle" and have sliders such as "Cycle time (seconds)" and "Minimum power". For example if the user set the minimum power to 0.6 (60%) and the cycle time to 30, then we would scale the pattern power to 60% of what it would otherwise be, and then have it gradually ramp up to the normal level over 15 seconds, and then gradually ramp back down to 60% by the end of the cycle (which would endlessly repeat).

The power scaling would work in a similar way to the existing "scale amplitude" control, but for this feature to avoid clipping (and minimise the number of controls) we will only scale it down towards whatever minimum level the user set, and treat the maximum as an implicit 1.0.

Implementing the cycling as a special effect instead would keep the normal power auto increase unchanged, and easy for users to understand. It also naturally allows for both to be combined, so that the power can ramp up and down periodically, while the overall power also gradually increases over time.

@MeinWesen @Vpn33 Do you think that approach could work, and does it allow for the usage you want?

[Vpn33]

I designed this climb feature primarily to simulate professional orgasm detection devices (such as the Edge-O-Matic 3000) when they aren't available. While it may not match the precision of actual sensor readings, the randomness at the peak still delivers a varied experience in real-world use, and can even trigger effects like ruined orgasms, orgasm denial, or post-orgasm torture.

However, unlike traditional vibration toys that can rapidly accumulate intensity and drive users to orgasm within 5–10 minutes, electrical stimulation is too smooth. The perceived sensation gradually declines over time due to neural adaptation. To maintain the feeling, you must continuously increase the intensity, but this easily exceeds the sensory receptors’ threshold as nerves become desensitized, potentially causing skin damage with prolonged use. Therefore, to achieve an effect similar to toys like the Edge-O-Matic 3000, you need to constantly adjust the intensity before your body adapts to it. This way, even if the level drops, your body quickly readapts. As long as the ramp-up parameters are precisely tuned to your personal sensation, you can consistently experience dynamic stimulation changes without ever needing to raise the maximum power limit.

I previously experimented with adjusting the waveform amplitude to achieve a similar effect. However, I later found that the sensation produced by amplitude changes on the Coyote device wasn't as intense as simply adjusting the output intensity. The main reason is that the amplitude upper limit is insufficient, as the device only supports values from 0 to 100. Therefore, I redesigned the auto-ramp function to modulate the output intensity instead, ensuring consistent stimulation—this is exactly what I've committed in my forked version of the code.I'm currently using Coyote's latest CR-MR-pro-2 6mm penile ring electrode, which delivers very strong stimulation due to its excellent conductivity. Compared to the previous 4mm ring where I used an upper limit of 120, I've lowered it to 60 for this setup (a value that feels very comfortable, though not the absolute sensory threshold). I set the base intensity to 40, and configured the auto-ramp parameter to increase the output by +1 every 0.7 seconds, within a range of 0 to +20. This allows me to maintain a consistent stimulation sensation for nearly ten-plus hours. Of course, these are all my personal subjective experiences, so they may not be universally applicable.

I've seen DG-LAB's official teaser for a similar device, which also uses an inflatable anal plug to monitor air pressure. Its working principle is likely identical to the Edge-O-Matic 3000, but it still requires an external peripheral for pressure detection. This means you'll end up juggling more and more accessories—you'd need to carry both the main unit and the Claw sensor. Add in the plug and a separate pressure gauge, and the whole setup gets quite bulky. For outings or when you prefer lighter stimulation, I'd rather have everything integrated into one device. A cleaner, minimalist design just looks much more elegant.
@Amethyst-Sysadmin

[Amethyst-Sysadmin]

@Vpn33 The upper limit of the pattern amplitude shouldn't really be a factor with this approach, as we would only be scaling down, not up.

To get comparable results to your approach, instead of varying the main power level from 40 to 60, you would set it to a fixed 60. Then the pattern power would be reduced by some amount by the new effect (depending on the configured settings and where it is in its cycle).

At the peak of the cycle we would not be reducing the amplitude at all, and would just be playing the normal pattern at 60 power. So the upper limit should be exactly the same as with your approach.

[Vpn33]

@Amethyst-Sysadmin If the tactile feedback doesn’t differ significantly between scaling the waveform and adjusting the power supply intensity, that should be fine.

[MeinWesen]

I'm not as advanced as either of you, but it sounds like a very workable solution and could deliver something similar to what doing it manually does.