DG-LAB has already announced the Bluetooth protocol for the new device,Do you intend to support new devices?

[Vpn33]

DG-LAB has already announced the Bluetooth protocol for the new device. I plan to implement some features in my fork based on these protocols. Do you intend to support new devices? I'd like to hear your thoughts. If you have plans to implement these protocols later, then I won't need to reinvent the wheel.

https://github.com/dungeonlab-open/dglab-bluetooth-protocol/blob/main/opossum-vibrate-controller/README.md

https://github.com/dungeonlab-open/dglab-bluetooth-protocol/blob/main/civet-edging-sensor/README.md

Long ago, I wanted to implement a sensor protocol for the auto-denail feature, but edge-o-matic3000 was quite expensive. Now DG-LAB's civet-edging-sensor is out, and it is much cheaper in price.

Additionally, I tried the multi-axis scripts in version 1.1; indeed, they feel different from single-axis scripts. This algorithm upgrade is great!

I thought the new DG-LAB opossum-vibrate has four vibrators that can form four channels. Being able to convert them into HWL or Funscript effects will surely be amazing. If these vibrators can be placed in specific positions, they should bring a 1+1>2 effect compared to single coyopte.

[Amethyst-Sysadmin]

Glad to hear you liked the multi-axis scripts, I've been enjoying those myself.

I'm unlikely to support the sensor, since Howl doesn't support any sensors directly (and we don't really do conditional actions during playback). I am having another look at a "pulse stream" type feature for the next release, and think I can probably get that working decently well. So you could potentially have an external script that reads the sensor and then sends the pattern you want to play to Howl in real-time.

Supporting the vibrator as an output device is more feasible, since we already support various different devices. But there are several technical issues in the way of that:

• All the patterns only use two channels (and it's fairly difficult to extend beyond that since the app code and the HWL file format weren't designed with that in mind).
• We don't support multiple output devices at the same time if you wanted to use it alongside a Coyote (the core output loop can easily handle that, but there are lots of difficulties on the UI side).
• Also the Bluetooth code isn't written to handle being connected to multiple devices at once.

So while it's possible that we could add the vibrator, it's not really a priority for me, since we'd have to solve all these issues first to give the optimal experience that users would want.

I'm also not working on any of those things currently. For the 1.2 release I'm looking at simplifying some things with how the app handles timing so that we're not constantly looking into the future, which makes real-time behaviour easier. And then I'm taking advantage of that to add something similar to streaming to the API. I also might update the charts and meters to make them a bit cooler.

[Vpn33]

I have received the public beta versions of the civet and opossum devices and actually tested them with the official 4.0 APP. From DG-LAB's official UI, it appears they are also striving to make multi-device operation as simple as possible, but the UI and operational experience for simultaneous multi-device output are still unsatisfactory. Some details regarding control methods and visual representation feel strange and not very user-friendly.

To clarify my previous statement: the opossum is also dual-channel (AB), consisting of two sets of four vibrators—2 in Channel A and 2 in Channel B. Therefore, to match current output modes, we need to instantiate multiple Bluetooth devices; modifying the waveform data section should be sufficient.

Additionally, the opossum's waveform editor looks very similar to coyote, but the algorithm is different, likely to better adapt to vibrators. If you plan to update with vibrator support later, I only need to consider script calls to the websocket interface to control both coyote and opossum, which would be fine. The current howl is very concise and easy to use; looking forward to your new UI and features.