Hello and thanks Squirrel,

dotoolc is really just a simple shell script that writes the actions
to the pipe which dotoold reads, so I'm afraid checking if its still
running probably isn't helpful, as it may terminate well before dotoold
has actually performed the actions.

I can't think of an easy solution to detecting when dotoold has finished
performing an action I'm afraid. It's the first time it's come up.

Sorry that's not much help. Hope you get something that suits working!
John

I get similar with:

    $ arecord -q -fS16_LE -c1 -r16000 -D CARD=Microphone
    ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM CARD=Microphone
    arecord: main:850: audio open error: No such file or directory

But this works:

    $ arecord -q -fS16_LE -c1 -r16000 -D sysdefault:CARD=Microphone

So try with the device name bit before the : also.

Hi (fellow!) John,

Numen currently uses the arecord command to get audio from the microphone,
so I'd start by investigating with arecord itself. I find `arecord -L`
more useful than `arecord -l`, it gives you the device names you can
specify with `arecord -D <device>` (and `numen --mic=<device>').

This is what numen uses under the hood:

    arecord -q -fS16_LE -c1 -r16000 -D <device>

where device is "sysdefault:CARD=Microphone" or "default", depending on
whether "sysdefault:CARD=Microphone" is present in output of `arecord -L`.

Yeah I'm afraid the DOTOOL_XKB_LAYOUT environment variable and friends
won't affect dotoolc (dotoolc merely passes actions to dotoold) but you
can set them when running dotoold in the first place:

    DOTOOL_XKB_LAYOUT=se dotoold &
    echo type <swedish-character> | dotoolc

Hope that's a help!

I made a mistake! The latest two commits require Vosk version v0.3.50 and
./get-vosk script only installs v0.3.45 (the Vosk team haven't provided
binaries for v0.3.50 yet).

I'd `git switch 0.1` and try again (or install Vosk v0.3.50 if it's in
your package manager)

"current user's" was confusing. I just meant how lingering /etc/numen from
older installs would override /usr/share/numen, blocking any updates to
the default phrases made by future releases.

~/.config/numen is safe :)

Hi fenugrec, after thinking about /usr/share/numen again recently, I'm
thinking future versions should use /usr/share/numen and just ignore
/etc/numen. I feel system-wide configuration of numen would rarely be
used, and /etc/numen would just add confusion, especially since a current
user's existing /etc/numen would override the new /usr/share/numen.

Don't feel you need to reply, just thought I'd say in case of any
thoughts!

Great! Thanks for sending the solution. I'll copy paste it here because I
don't think it made it to the mailing list:

> thank you for your answer. I managed to fix it. the issue was because
> of systemd-resolved. It was as simple as:
> 
> # ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
> 
> as explained in the archlinux wiki. It didn't occur to me to check
> because DNS was working fine everywhere else. Hopefully if someone
> else runs into the problem they can find this. Cheers

Hi Ivan, I'm afraid I don't know why you are getting this issue.

I don't think anything's changed and seeing as github.com/bendahl/uinput
is also failing the same way, I don't think it's related to my packages
but a general issue with the go toolchain.

In my dotool directory, if I run:

	go clean -cache -modcache
	go build

It's successful and only outputs:

	go: downloading git.sr.ht/~geb/opt v0.0.0-20230911153257-e72225a1933c

I like the /usr/share suggestion! Recently someone on the chat said they
lost changes due to /etc/numen being overwritten, which I hadn't thought
enough about before.

The transition would be slightly bumpy, with old installed
/etc/numen taking precedence over it, and I know at least
https://github.com/anpandey/numen-nix/blob/master/flake.nix would need
paths updated, but it would probably be worth it.