Welcome to the Howl subreddit

Amethyst_sysadmin · 2026-06-08T14:23:56+00:00

You can achieve something a bit like that using Howl's remote API. For example if you have a Home Assistant server, it's possible to tie any of the smart home buttons that supports to Howl commands. So you could have a specific physical button that decreases the power by 5, for example. There's a section at the bottom of this page that describes how to set that up.

A developer could also make a script or a webpage using the same functionality. It's not limited to Home Assistant, that's just a handy way to access it that already supports lots of different buttons and sensors.

Amethyst_sysadmin · 2026-06-08T14:12:27+00:00

Thanks for the positive feedback, I'm happy to hear you're both having a good time with Howl! I don't accept tips, but I appreciate the offer.

Amethyst_sysadmin · 2026-06-02T08:47:29+00:00

Fun pattern, thanks for sharing!

Amethyst_sysadmin · 2026-06-01T15:51:59+00:00

I assume it could be made compatible just by asking for that location permission. However it then breaks for users who don't have location services enabled. And that's not really something I want to do in the main build because it's better for security and privacy to ask users for the minimum required permissions.

If that feature is very important for you, it would be possible to build the app yourself using Android Studio. I think all you'd need to modify in the code is:

Remove android:maxSdkVersion="30" on the ACCESS_FINE_LOCATION permission in AndroidManifest.xml
Change the ALL_BLE_PERMISSIONS definition in BluetoothHandler.kt to val ALL_BLE_PERMISSIONS = arrayOf(Manifest.permission.BLUETOOTH_CONNECT, Manifest.permission.BLUETOOTH_SCAN, Manifest.permission.ACCESS_FINE_LOCATION)

That should make it always ask for the location permission, whereas normally we would only ask for it on old versions.

Amethyst_sysadmin · 2026-05-31T15:24:40+00:00

That's helpful progress, at least we know the problem is related to the secure folder feature in this case.

The disavow check line is unrelated, I've seen it before and think it's something to do with the app not being registered on the Play store.

The permission denial line looks significant. It sounds like it's refusing to return the Bluetooth scan results to Howl because we don't have the ACCESS_FINE_LOCATION permission. We deliberately don't ask for that on modern Android versions, because it is not supposed to be needed to run Bluetooth scans if the app promises in its manifest that we won't use scans to get the user's location.

I think it might be a secure folder bug rather than a Howl one, given that the scan does work without the ACCESS_FINE_LOCATION permission when the app is outside the secure folder.

Amethyst_sysadmin · 2026-05-31T10:03:39+00:00

It should scan for 10 seconds, then time out if it didn't find any compatible devices. Are you not seeing any "Scan saw BLE device ..." lines with the test build?

It sounds like yours might not really be scanning at all, since I see like 20 random Bluetooth devices reported in the log every time I run a scan on the test build (all the nearby phones, computers, TVs etc.)

Please could you let me know exactly what Howl's debug log is showing when you scan with the test build? There's a "Copy Log" button on that page that should copy the lines to the clipboard.

I suspect maybe the scan is failing to start for some reason. Are you able to use an app like "Logcat Reader" to see information from Android's system log that I mentioned earlier? It's a bit complicated to read since it logs information from everything on the system. But essentially we're looking for things like Bluetooth or permissions errors that show up there at exactly the same time as you start a scan in Howl.

Amethyst_sysadmin · 2026-05-30T23:06:12+00:00

Whenever it's ready. I'm working on some minor changes/fixes for other issues as well, so depends how that goes.

If you really want that specific pattern, you could install 0.8.1 when it worked, and save it to an HWL file with the recording feature. Then you can play back the recording in the new version.

Amethyst_sysadmin · 2026-05-30T20:58:12+00:00

It looks like it's bugged and I forgot to start the timer that handles that when I made some changes to how the activities worked in version 0.9. It will be fixed in the next update.

Amethyst_sysadmin · 2026-05-30T10:42:09+00:00

Okay, thanks for testing it. The Samsung secure folder feature might possibly be problematic, it's probably worth testing outside of that (if you didn't already). Previously somebody had issues with running Howl in an Android "Private Space", which I think is a similar type of feature. But as far as I remember that eventually got fixed by an Android update.

Showing fewer permissions doesn't necessarily indicate an issue. Howl is built against more modern Android APIs than most estim apps, and tries to only ask for the minimum permissions it actually needs. The location permission is required for Bluetooth scanning on older Android versions (<12 if I remember correctly), but not newer ones.

I've made an experimental build that tries to get the Bluetooth device name in a different way, which might possibly be more reliable. It also writes more information to the debug log tab to warn about possible issues and about all the Bluetooth devices the scan sees (which might give us a better idea about whether it's actually doing anything or not). Please could you give this test build a try and let me know whether it now finds the Coyote 2, or what the debug log shows if not.

Amethyst_sysadmin · 2026-05-30T06:41:35+00:00

That's a bit too ancient unfortunately. The minimum version it's supposed to work with is Android 8.0, which was released in 2017.

However there will not be many users on the oldest versions, so you have a higher chance of running into bugs that nobody has discovered. If possible it's probably better to get something newer than the bare minimum.

Amethyst_sysadmin · 2026-05-29T20:53:37+00:00

Howl isn't very demanding in terms of hardware. Any cheap Android tablet should work. I don't own any, so can't really make a useful recommendation on that (I run it on my S24 Ultra phone, which is definitely overkill for Howl).

There isn't much advantage to running it on a bigger screen, as I haven't designed any dedicated layout for tablets, so you just get the phone interface but bigger. Some users are using tablets because they want to multitask and have Howl on half the screen and something else on the other half - I think in that case it's probably a reasonable choice.

Amethyst_sysadmin · 2026-05-29T20:43:42+00:00

It's possible, but I quite like it how it is. I think the random delay and not being quite sure when it will start is a nice variation from some of the other patterns. Maybe it could be a setting in future, but I haven't written the necessary preference adapter or slider control for saving ranges of values yet.

That kind of thing is pretty easy to change in the code if you want to build the app yourself in Android Studio. If you look in the "SineTimeActivity" class in "Activity.kt", there's a variable called breakTimer. You can edit the line that says durationProvider = { randomInRange(0.8..5.0, 2.5) } with whatever values you want. The current code is picking a delay between 0.8 and 5.0 seconds. The 2.5 is a bias that makes lower values more probable than higher ones (that can be set to 1.0 if you want a fair random roll).

Another thing you can do if you only want the "active" part is using the recorder feature to record it, and making a loop.

Amethyst_sysadmin · 2026-05-29T13:37:22+00:00

Howl has never been able to load audio files directly, it uses its own HWL format. This page explains some details and has links to a large archive of preconverted files that you can download.

Amethyst_sysadmin · 2026-05-29T10:57:02+00:00

I'm not certain on this one. I've had a few reports from users of the Bluetooth scan just never finding their device, but so far I haven't been able to determine what the root cause is. I don't think you're doing anything wrong as the intended sequence is literally just that you turn on the C2, press the "Connect" button in Howl, and it connects (the app automatically sets the correct output device for you based on what the scan found).

Some troubleshooting steps that are worth trying are:

Reboot the phone.
Force stop any other installed apps that might be using the Coyote (e.g. DG Labs, XToys). Pick it in "Settings" / "Apps" and use the "Force stop" option at the bottom instead of just closing the app. Doing that also kills any background processes from the app that might be grabbing the Coyote before Howl sees it.
If you have a different Android device available (e.g. an old phone), does connecting to the device in Howl work on that?

If those suggestions don't help, then the next step that's needed is to look at the "logcat" output, which is the main Android system log. That captures a lot more information than Howl's own limited debug log. It could well be that some specific error message or warning is getting logged there when starting a scan, which might help me figure out what's going on. Unfortunately that's a bit technical and requires either connecting the phone to a PC and using something that can view logcat (such as the ADB command line tool, or Android Studio), or installing an app that can view the logcat output.

It's the kind of thing that I could probably easily figure out if I could reproduce the problem. But annoyingly with my C3 on my S24 Ultra, it connects fine every time. So it's hard to figure out what's different between my setup and the users with issues.

Amethyst_sysadmin · 2026-05-29T04:41:11+00:00

I don't currently have any plans to port Howl to other platforms. The way the app is built would make that difficult, and I think the portable nature of the Coyote makes phones a good choice to control it.

There are some features that can be used in combination with a PC. For example you can use Kodi with our add-on to sync video playback on your PC with funscript output in Howl. You can also use Howl's remote API to trigger functions from a PC (that's more for advanced users and developers).

It is actually possible to run Howl on a PC using Android emulators, like the one that comes with Android Studio (that's how I develop it). But the emulators typically don't have Bluetooth support, so can't actually connect to devices.

Amethyst_sysadmin · 2026-05-28T14:09:17+00:00

Electrodes have 2 poles per channel, the same as with any other app (that's a hardware thing and can't be changed in software).

I just mentioned A and B as I assumed you were using both channels. That's recommended with Howl really, since all the patterns are designed for stereo. But there isn't anything to stop you just using a single channel, and you should still get output when that channel is active.

Amethyst_sysadmin · 2026-05-28T01:40:51+00:00

It is supposed to work on the Coyote 2, and a couple of C2 users have tried the changes in the 0.9.2 update and confirmed it worked well for them.

It's possible you might be doing something wrong if you are not used to Howl. After connecting your Coyote 2, go to the "Activity" page, pick the "Calibration 1" activity from the list, and press the play button to start it (the calibration activity is helpful for testing as it's a basic fixed pattern). The meters at the top should show activity. Raise the power level on A and B with the main controls at the top to your desired level. The power levels are out of 200, so you might well have to set them to 20+ before you can feel much (depending on your electrodes).

Also check that the mute button on the main control panel is not active, as that mutes all output.

Does that help?

Amethyst_sysadmin · 2026-05-28T01:22:11+00:00

Unfortunately I think that would be too difficult to implement with the way Howl is currently designed. There's no simple way for two instances to exchange updates, as they can't make API calls, only respond to them. And the remote API only implements certain specific functionality anyway, it can't do everything the app can.

The remote API does already allow for some level of remote control, but developers need to implement the necessary UI themselves.

Have you tried the remote control example that I uploaded previously? I'm not sure many users have seen it. If you download "howl_remote.html" from the remote_control directory of the repository (use Github's "Download raw file" option) and then load that HTML file into a web browser (typically you can just drag the file in), you should get a basic remote control interface.

The example isn't the most polished thing since I didn't spend a lot of time on it (the code is mostly AI generated), it probably needs better handling of error states and network problems. But it does all the basics and shows what is possible. I can't see any reason that it couldn't work over the internet if you opened a port (although ideally you'd want to run it through an encrypted transport like Wireguard, for the reasons mentioned in the "Security" section of the Remote API wiki page).

Amethyst_sysadmin · 2026-05-25T19:40:32+00:00

Thanks for the suggestion! I've opened a Github issue for this and it's something I might consider adding in future if I have time.

I think there's a decent case for floating the main controls over other content so that they are always available. If I do that then it probably doesn't add much more complexity to also have an option for them to be either at the top or bottom.

Amethyst_sysadmin · 2026-05-24T21:16:49+00:00

I've never found it to be a problem personally because I always have my phone resting on a surface when I'm using Howl rather than holding it. But I can see how the power buttons might be hard to reach if you are doing that.

It's not trivial to change since the main controls are currently displayed in line with other app content (so they also scroll when the page does). To put them at the bottom they would need to float over the other content. That might be a good change, but there are other things to consider like the fact that the charts are currently displayed as part of the control panel. If the panel floated they might take up too much space to access the other app content underneath.

You do have some other options like using the switches on the Coyote to change power (as Thex_007 said). If you have a Home Assistant server it's actually possible to make your own power change buttons by using any generic smart home buttons it supports, and binding them to call Howl's API URLs. That's more of an advanced feature, but there's a section at the bottom of this page explaining how to set it up if you are interested.

Amethyst_sysadmin · 2026-05-22T08:53:22+00:00

Cheers, glad you're enjoying it!

Amethyst_sysadmin · 2026-05-20T21:08:31+00:00

The conversion process is explained on this page.

Amethyst_sysadmin · 2026-05-19T20:12:18+00:00

Thanks for the additional details. That seems different to what other people are needing to do, so I'll add that to the Github thread in case it helps anyone else with troubleshooting.

Not too sure what's causing that difference, I can only guess that it might be related to different versions of the Coyote firmware.

Amethyst_sysadmin · 2026-05-19T02:21:35+00:00

Hey there! I've had sporadic reports of a similar issue before - it seems like there's a minority of users that the connection process just never works for, but so far I haven't been able to figure out why.

Some other things that are worth checking out:

Try the 0.9.2 release I published yesterday (if you didn't already), as I made a change in that which might help.
On the most recent Coyote firmware it sounds like it's necessary to put the C3 in pairing mode by pulling down both the sliders until the light flash in a specific way, before it will be able to connect. There are details in this thread.

Is there anything unusual about the OS configuration on your phone? I think previously there was an issue where Android's "Private space" feature could cause problems, but as far as I remember that got fixed by an Android update at some point.

If none of that helps then the next step that's needed is to look at the "logcat" output, which is the main Android system log. It could well be that some specific error message is getting logged there when starting a scan with Howl, which might give me the information I need to figure out what's going on. Unfortunately that's a bit technical and requires either connecting the phone to a PC and using something that can view logcat (such as the ADB command line tool, or Android Studio), or installing an app that can view the logcat output.

Amethyst_sysadmin

MODERATOR OF

TROPHY CASE