Scripting/dbus interface

[sirherrbatka]

That is a really neat project, however I would like to do something outside of it's scope: emacs org roam daily capture with voice. Basically press a key, emacs window appears with capture, speak, release the button, note is saved and windows is destroyed. Any idea how to achieve such thing?

[sirherrbatka]

After thinking about it a bit: this would be really easy if there would be if Dictee would just pipe transcribed text to a script. Maybe this could be a future feature?

PS
The more minimal option would be to have named pipe feed constantly being feed by dictee and a secondary deamon reading it and doing whatever is required. That way secondary daemon could recognise keyword and dispatch some action based on that.

[rcspam]

Hi @sirherrbatka, glad you like it , it's a nice use case. 🙂

Good news: you don't actually need a new feature to do this today. Dictée ships a CLI client, transcribe-client, that records one mic utterance and prints the transcript to stdout (all status goes to stderr, so stdout stays clean). So a ~10-line wrapper + a global shortcut already gives you what you want. This is an example:

#!/usr/bin/env bash
# voice-to-cmd — record one mic utterance via dictee's daemon and pipe the
# transcript to a command (on its stdin). Requires dictee.service running.
# Usage: voice-to-cmd <command> [args...]
#   Stop with Enter, or set TRANSCRIBE_DURATION=N for an N-second clip.
set -euo pipefail
text=$(transcribe-client)
[ -n "$text" ] || exit 0
if [ "$#" -gt 0 ]; then printf '%s' "$text" | "$@"; else printf '%s\n' "$text"; fi

Install it, make it executable and bind a key to it.

I'm not an Emacs user but I hope the next one is right. Anyway, you can fix it at your ease.
For your org-roam daily capture, point the shortcut at something like:

voice-to-cmd bash -c 'emacsclient -e "(org-roam-dailies-capture-today)" && emacsclient -e "(insert \"$(cat)\")"'

i.e. voice-to-cmd hands you the transcript on stdin and you drive emacs however you like.

One caveat: transcribe-client records until you press Enter (or a fixed TRANSCRIBE_DURATION), not press-and-hold — true hold-to-talk lives in dictee-ptt. For "press → speak → Enter" it already covers the workflow. It's up to you to find the 'Stop' mechanism to replace the 'Enter' key.

That said, your request is spot-on, so I've put a first-class on-transcription → run command hook on the v1.4+ list (with the FIFO + keyword-dispatch daemon and a D-Bus signal as longer-term ideas). Would that simple hook cover your case, or do you specifically need the always-on FIFO/keyword approach?

[sirherrbatka]

Oh wow, thanks! I've wrote the following script: ``` #!/bin/bash set -euo pipefail TEXT=$(transcribe-client) ESCAPED_TEXT="${TEXT//\\/\\\\}" emacsclient -e "(my/org-roam-pipe-capture \"$ESCAPED_TEXT\")" ``` and added the following function to emacs ``` (defun my/org-roam-pipe-capture (text) (when (and text (not (string-empty-p text))) (let ((org-capture-initial text) (org-roam-dailies-capture-templates '(("p" "pipe" entry "* %U %i" t) :if-new (file+head "%<%Y-%m- %d>.org" "#+title: %<%Y-%m-%d>\n") :prepend nil :immediate-finish t)))) (org-roam-dailies-capture-today nil "p")))) ``` And that works like a charm. As for keyword trigger, I've experimented with some hackery around the clipboard content and that honestly just does not work all that great. Transcription not perfectly reliable and keyword sometimes does not match and there is no feedback if it doesn't. Also, typed text screws some apps. Would be better to have a dedicated button for certain task, I mean app uses F9 but that's a really nice use case for a battle-cruiser keyboard with 24 F keys ;-) or a macropad I guess.

[rcspam]

Super, glad it works!

A tip that came to me while replying: you can give a fixed duration to your commande with:

TRANSCRIBE_DURATION=5 voice-to-cmd <your-command>

transcribe 5 seconds, then runs your command. That neatly sidesteps the whole "how do I stop the recording" problem, no Enter, no stop key to wire up. Just pick a duration that fits the task.
On the keyword / voice-command side, you're touching on something bigger. Voice commands (recognise an intent and dispatch an action) are something I have in mind, but for a version after 1.4 (v1.4 is focused on making the meeting feature solid). As for voice commands, it's not brainstormed at all yet. Driving Linux and its apps by voice is really a project of its own... But that's something I'm considering.

Thanks again for the great use case and feedback!

[rcspam]

Another tip, if you want filter the dictation output transcribe:

TRANSCRIBE_DURATION=6 transcribe-client  | dictee-postprocess --lang en 

Take a look here.
You can set some things with the post-processing into the dictee setup windows. So play with it.
The wiki can help you

[sirherrbatka]

I would like to avoid using timers. They are finicky in my experience and put unreasonable stress on the user.