Cross-project introduction: TeamTalk VO Client + iOS app ideas

[fla-rion]

Hi @math65,

I'm Florian Lichteblau, the developer of TeamTalk VO Client — a Python-based TeamTalk client focused on accessibility (VoiceOver, Braille display, screen reader support) for macOS and Windows. I came across ttaccessible and was genuinely impressed by the architecture, especially the dual audio engine approach and the native VoiceOver integration without runtime patching.

Our project: https://github.com/fla-rion/TeamTalk-VO-Client

---

What our client currently offers

The Python client has grown quite large over time. Here's a rough feature overview:

Core

• Full server/channel/user management, multi-server profiles, .tt file / tt:// URL support
• Channel and private chat with history, search, export (txt/html)
• File transfer, admin tools (ban list, user accounts, server broadcast, server stats)
• Auto-reconnect, auto-join per server

Audio

• PTT + Voice Activation, AGC, noise suppression, echo cancellation (SDK-level)
• Per-user volume + stereo position, media file mute/volume separate from voice
• Equalizer presets, per-server audio profiles
• Global hotkeys (PTT + mute-all) — macOS via NSEvent monitor, Windows via Win32 polling

Accessibility

• VoiceOver support on macOS (via ObjC runtime patching — your native approach is clearly better)
• Braille display support (compact label mode)
• NVDA support on Windows
• Configurable TTS via espeak-ng with per-context rate/voice overrides (chat vs. system vs. channel events), pronunciation dictionary, interrupt mode

Automation / AI

• Macro manager (text macros + actions, scheduled macros)
• Trigger rules (event → action)
• Auto-reply manager
• Chat translation (DeepL/LibreTranslate)
• AI channel summary on join (Gemini API — summarizes last 30 min of chat)
• Mute scheduler (time-based mute windows)

Misc

• Media streaming: YouTube/yt-dlp, SoundCloud, Twitch, Bandcamp, Vimeo, Mixcloud, Webradio, Podcast, local file, playlist
• Recording (WAV/MP3, scheduled recordings)
• Plugin system (Python plugins loaded at runtime)
• Webhook manager, HTTP API server
• Bookmark manager, channel notes, user notes
• Saved messages, offline message queue
• Settings backup/restore, server list import/export
• Chat search, user watcher, online users dialog
• Startup profiler, health check, usage analytics

---

Our interest in your project

We're exploring the idea of building a native iOS client (SwiftUI) that covers the most meaningful subset of the above features for mobile. Your architecture — particularly the clean Service layer separation, the TeamTalk SDK bridging approach, and the WebRTC AEC3 integration — is exactly the kind of foundation we'd want to build on.

A few things we'd love to discuss:

1. iOS feasibility of your service layer — how much of Services/ do you think would survive an AppKit → SwiftUI/UIKit transition? The connection management and audio service abstractions look portable.

2. WebRTC AEC3 on iOS — the Speaker Tap approach (Core Audio, macOS 14.2+) won't work on iOS in the same way. Have you thought about the iOS equivalent? AVAudioEngine with voice processing I/O node comes to mind.

3. License / collaboration — if we were to build an iOS client inspired by (or partly based on) your architecture, we'd keep it GPL-3.0 and open source. The App Store GPL incompatibility is a known issue — likely we'd distribute outside the App Store (TestFlight or direct IPA) for now, same as our current macOS DMG distribution model.

4. Feature cross-pollination — are there features in our list above that you'd want to bring into ttaccessible? Happy to share implementation notes on anything that's useful — the per-context TTS rate/voice system, the pronunciation dictionary, or the macro engine for example.

---

No pressure on any of this — mainly wanted to say hello, share what we've built, and explore whether there's room for collaboration or at least mutual inspiration. The TeamTalk accessibility space is small enough that it makes sense for the two serious open-source clients to be aware of each other.

Best,
Florian

[math65]

Hi Florian,

Thanks so much for reaching out — this genuinely made my day. The TeamTalk accessibility space is small, and discovering your project through your message has been a bit of a revelation. Honestly, I should have searched GitHub before starting ttaccessible — your feature list contains a bunch of things I'd love to have.

I'll definitely check out your project and give it a real try over the next few days. Funny enough, I had also started a Python alternative for Windows a while back — much less advanced than yours, since I don't use a PC very often. The main thing I'd started prototyping was per-app audio streaming on Windows (being able to broadcast the sound from any specific app), but it never went far.

A bit of context about me first: I'm not a developer. I use Claude Code (Anthropic's CLI) for essentially all the implementation work on ttaccessible. What I bring is product direction, accessibility decisions (I'm a VoiceOver user myself), user testing with the community, and overall vision. But when you ask me pointed questions about CoreAudio or iOS architecture, I'll need to dig into them with Claude to answer you seriously rather than improvise. I'd rather say it upfront so we start on clear footing.

On your four points then, my answers are more "intuitive" than technically definitive:

1. iOS feasibility of the Service layer — instinctively, yes, a good portion should be portable because I've separated the business logic from the AppKit components fairly cleanly. But the devil is in the details, especially on the audio side. We'd need to look at it together to see what survives and what breaks.

2. WebRTC AEC3 on iOS — same thing, your idea of the AVAudioEngine voice processing I/O node sounds coherent, but I've never touched iOS. You'll probably get up to speed faster than me on that one.

3. License / collaboration — ttaccessible doesn't have a LICENSE yet (oversight on my part, I'll fix that). Open question from my side: would we be locked into GPL-3.0 for the iOS client, or could we consider a more permissive license (MIT, Apache 2.0…)? I'd find it really unfortunate to have to distribute outside the App Store — for mainstream accessibility, going through TestFlight or direct IPA is a huge barrier for the majority of users. Curious to hear your thoughts and whether you have constraints on the VO Client side that mandate GPL.

4. Feature cross-pollination — this is where I'm most interested, by far. Anything in the list below would make me jump for joy if we could draw inspiration from it in ttaccessible:

• Per-context TTS (different rate/voice for chat vs system vs channel events) — I currently rely 100% on VoiceOver with no per-context control, this would be a big upgrade
• Pronunciation dictionary — recurring request from my testers
• Macro engine / trigger rules — I have zero automation right now
• PTT and VOX — already on my missing-features list
• AI channel summary — brilliant idea, curious to see how you handle the prompting

On my side, anything you find useful in ttaccessible is yours of course — the architecture is open, and if you want to talk through it in detail I'm happy to.

For next steps: continue on this issue, move to Discord, or email?

Best,
Mathieu

[fla-rion]

Hi Mathieu,

Thank you for the detailed and honest reply — I really appreciate the transparency about your workflow. We're in exactly the same boat: product and accessibility vision driving the direction, with Claude Code handling the implementation. It's honestly reassuring to know the approach works at your level of quality too.

On the license question: No GPL constraint on our end for the iOS project. MIT or Apache 2.0 is perfectly fine — and frankly the right call if you want to reach mainstream users through the App Store. I'd mentioned GPL-3.0 in my original post because that's the model I assumed, but I have no attachment to it for a new, separate iOS project. Let's keep it open and App Store-compatible.

On the other points:

• iOS Service layer portability: agreed, let's look at it together. I'd suggest starting with the connection management side — that's the most protocol-heavy part and probably the best indicator of what survives the transition.
• WebRTC AEC3 / AVAudioEngine: I'll prepare a short technical brief on the voice processing I/O node approach and share it here. If it holds up, it removes one of the bigger unknowns.

Feature cross-pollination — concrete offer:
For the features on your list, here's what I can share immediately:

• Per-context TTS — I can write up exactly how the rate/voice override system works (it's simpler than it sounds, and entirely decoupled from the TTS backend). Happy to put that in a separate issue or a doc in your repo, whichever you prefer.
• Pronunciation dictionary — small, self-contained feature. I can share the data model and lookup logic as a reference.
• AI channel summary — I'll share the prompting approach and the 30-min sliding window implementation. The Gemini API integration is thin; the interesting part is the context framing.

Next steps: Let's keep going here on this issue for now — it's a good record of where things started. When we get to actual code or architecture discussions, a shared Discord or a dedicated repo might make more sense.

Looking forward to building something together.

Best,
Florian

[fla-rion]

Quick heads-up: we just shipped v6.9.4, partly inspired by ttaccessible's connection flow and keyboard philosophy.

What made it in:

• Connection window opens automatically at app start
• On successful connect: window closes, main frame comes to front, focus jumps to the channel list
• On disconnect: connection window reopens automatically
• ⌘J — join selected channel
• ⌘L — leave channel
• ⌘⇧A — toggle microphone transmission
• F2 — smart toggle (disconnect if connected, connect if not)
• Qt/Windows: tab switches automatically to "Channels & Chat" on connect

Release: https://github.com/fla-rion/TeamTalk-VO-Client/releases/tag/v6.9.4

— Florian

[fla-rion]

Hi Mathieu,

just wanted to let you know that version 6.9.5 is now out! This release is directly inspired by your work on ttaccessible:

• Batch TTS announcements: join/leave events are buffered for 300 ms and read as a single announcement
• Cleaner chat timestamps: HH:MM instead of HH:MM:SS
• Channel user count: shown as direct/total (e.g. "3/5 users") so you can see sub-channel occupancy at a glance
• Dynamic mute labels in the user context menu: "Mute voice" / "Unmute voice" depending on current state

Release: https://github.com/fla-rion/TeamTalk-VO-Client/releases/tag/v6.9.5

Your project really gave us great inspiration for tightening up the UI. Thanks again for the warm response — still very much looking forward to a deeper collaboration!

[fla-rion]

Danke für dein Feedback! Ich habe in der Zwischenzeit Version 6.9.6 des TeamTalk VO Clients veröffentlicht, die direkt von ttaccessible inspiriert ist:

• Abwesenheitsnachricht: Eigener Statustext beim Abwesenheitsmodus
• Granulare TTS-Steuerung: Rundnachrichten und Kick-Ereignisse separat steuerbar
• Hintergrundbenachrichtigungen: Getrennte Einstellungen für Private-, Kanal- und Rundnachrichten
• Serverliste sortieren: Manuell / nach Name / nach Host
• Kick ohne Bestätigung: Optionaler Schutzdialog deaktivierbar
• Relativer Zeitstempel: Chat-Timestamps als „gerade eben"

Download: https://github.com/fla-rion/TeamTalk-VO-Client/releases/tag/v6.9.6

Viele Grüße, Florian

[fla-rion]

Ich habe gerade Version 6.9.7 veröffentlicht, die weitere Verbesserungen für VoiceOver-Nutzer enthält:

• TTS per Nutzer stummschalten: Beitritt/Verlassen einzelner Nutzer können per Rechtsklick → „TTS-Beitritt stummschalten" aus der Sprachausgabe ausgeblendet werden
• Verbindungsabbruch via TTS: „Verbindung verloren" wird bei Verbindungsverlust gesprochen
• Nutzernotiz im Kontextmenü: Direkt per Rechtsklick auf einen Nutzer Notizen anlegen/bearbeiten
• Kanal-Favoriten: Kanäle per Rechtsklick als Favorit markieren, erscheinen mit „★" in der Kanalliste
• Cmd+F: Springt direkt in das Chat-Suchfeld

Download: https://github.com/fla-rion/TeamTalk-VO-Client/releases/tag/v6.9.7

Viele Grüße, Florian

[math65]

Hi Florian,

Wow — four releases inspired by ttaccessible AND a collaborator invite on VO Client? I genuinely wasn't expecting any of this. Congrats on shipping that fast — the batch TTS announcements in 6.9.5, the channel favorites and per-user TTS mute in 6.9.7, the away message and granular TTS controls in 6.9.6 are all great additions, and I'm glad to have been useful as a reference. And thank you for the collab invite — I accepted, and I'm honored by the trust. I'll tread carefully with it, mostly reading and learning for now rather than pushing.

Honest reaction: this gives the accessibility community two clients that are now meaningfully ahead of where either of us was a month ago, which is exactly the dynamic that makes this collaboration worthwhile.

On the license: perfect, I'll add a LICENSE file to ttaccessible this week — going with MIT for simplicity.

On your code-sharing offer: yes please, all three. Priority order from my side:

1. Per-context TTS — biggest immediate impact for my testers
2. Pronunciation dictionary — close second
3. AI channel summary — particularly curious about the prompt framing

Small heads-up: I cloned VO Client locally so I could read the code as a reference (same way I keep ../ttoriginal/ around for the Qt client). pronunciation.py, ai_summary.py, and tts.py are all neatly self-contained — appreciated. So feel free to skip the obvious parts in your writeups and focus on rationale and gotchas; those are the things I'd never recover from code alone.

On the iOS brief: no rush, take the time you need. When it's ready I'll absorb it with Claude and we can iterate.

On VO Client (testing): planning to install and run it properly over the next few days. I'll come back here with notes — bug-style feedback if I hit anything, plus feature-level reactions.

Best,
Mathieu

[fla-rion]

Hi Mathieu,

What a thorough and generous reply — thank you. The transparency about your workflow is genuinely useful, and it makes collaboration much easier when both sides are honest about how they work.

I've just shipped v6.9.9 which adds you to the About dialog (under a dedicated "Inspirationsquellen" / Credits section) and adds a cross-reference to ttaccessible in the user manual with a full list of the features your work inspired. Small thing, but it felt right to make that visible in the app itself.

---

Codebase orientation — the things code alone won't tell you

Since you've already cloned and read tts.py, pronunciation.py, and ai_summary.py, I'll skip the obvious and focus on rationale and gotchas.

Why two UIs (wxPython + PySide6/Qt)?

Short version: VoiceOver forced my hand.

On macOS, wxPython wraps native Cocoa/AppKit widgets, which means VoiceOver reads them through NSAccessibility — the same path it uses for native apps. PySide6/Qt on macOS renders its own widgets and bridges to accessibility through a much thinner compatibility layer. In practice: wx ListBox gets read correctly as a list with navigable rows; Qt's equivalent gets announced as a table or ignored entirely. For Braille display users (which I am), the difference is between usable and unusable.

On Windows, the situation inverts. wxPython's Windows accessibility support has historically been inconsistent with NVDA and Narrator; Qt's accessibility layer on Windows is mature and well-tested. So wx on macOS, Qt on Windows/Linux — it's not an architectural preference, it's driven entirely by which toolkit talks to which screen reader well on each platform.

The shared layer is src/ui/models.py — the AppSettings dataclass and SettingsStore (load/save JSON). Both UIs import from there. Business logic (TTS, chat history, TeamTalk SDK events) lives in src/ and is platform-agnostic. The UI files in src/ui_wx/ and src/ui_qt/ are intentionally thin: they translate SDK events into widget updates, nothing more.

Gotcha: src/ui_wx/models.py just re-exports from src/ui/models.py. It exists only so wx tabs can do from models import AppSettings without caring about the path. Don't edit it — edit the canonical one.

Entry points for reading

• src/app.py — platform router, 30 lines, good starting point
• src/app_wx.py (~10k lines) — macOS main class. Intimidating size, but it's mostly event handlers. The real structure is in src/ui_wx/tabs/ — each tab is a self-contained panel
• src/ui/models.py — if you want to understand what the app remembers between sessions, this is it
• src/teamtalk_client/client.py — SDK event pump; all the on_* callbacks originate here

---

Per-context TTS — rationale and gotchas

The design: TTSSettings (in src/tts.py) has global rate and voice fields, plus per-context overrides: chat_rate, system_rate, channel_rate, chat_voice, system_voice. The speak(text, kind=...) method reads the kind argument, applies the right override, and falls back to global if the override is 0/empty.

Why kind instead of a more structured type: Every call site in the app already had a logical category — chat messages, system events, channel join/leave, connection events. Tagging them with a string kind was zero-overhead and meant the filtering and rate logic could all live in one place (speak()) rather than scattered across call sites.

The 0/"" sentinel: Per-context overrides use 0 for rate (not None) and "" for voice. This is a deliberate choice — JSON doesn't distinguish between null and missing, and 0 is unambiguous: "use global". If you store None in the dataclass and serialize to JSON, you get null, which deserializes as None again — fine. But if you then check if settings.chat_rate: you catch both 0 and None, which is actually what you want. Either way works; I went with 0 because it's what espeak-ng accepts directly as a speed argument.

Adding a new context: Tag your speak() call with a new kind string, add a speak_<kind>: bool = True field to TTSSettings, and add one if kind == "..." and not self.settings.speak_...: return line in speak(). That's genuinely the whole change.

---

Pronunciation dictionary — rationale and gotchas

The design: PronunciationManager (src/pronunciation.py) takes a Dict[str, str], sorts keys by length descending, and compiles them into a single regex with |. The apply(text) method runs one pass.

Why sort by length: Without this, "TT" would match inside "TTServer" before "TTServer" gets a chance. Longest-first guarantees that more specific rules win. This is the only non-obvious part of the implementation.

Where it plugs in: apply() is called in TTSManager.speak() before the text reaches espeak-ng. The rules are stored in AppSettings.pronunciation_dict: Dict[str, str] and loaded into PronunciationManager at startup (and reloaded when settings change). The UI for editing rules is in src/ui_wx/tabs/settings.py — a simple key/value list.

Gotcha: The regex uses re.escape() on each key, so users can safely type punctuation. But it won't match across word boundaries — "TT" will match "TT5" because there's no \b anchor. I made that choice deliberately: TeamTalk abbreviations often appear inside longer tokens ("TT5", "TTServer"), and word-boundary matching would silently skip them. If you implement this in ttaccessible, worth deciding upfront whether you want substring or whole-word matching.

---

AI channel summary — rationale and gotchas

The design: ChatSummaryManager.summarize_missed(server_key, since_ts) pulls messages from ChatHistoryManager (SQLite, src/chat_history.py) for the given server after since_ts, formats them as a flat transcript, and sends to whichever backend is available.

Backend fallback chain: Claude API → Gemini API → Ollama (local) → extraction fallback. The extraction fallback doesn't use any AI — it picks the last N messages and returns them as-is. This matters for offline users or situations where all API keys are missing; the feature degrades gracefully rather than breaking.

The prompt framing: The system prompt is deliberately minimal — "summarize in max 3 sentences, name the important topics and who said what, answer only with the summary." No chain-of-thought, no elaborate instructions. I found that longer prompts caused the model to include meta-commentary ("Here is a summary: ...") that then got read aloud by TTS. Short prompt → cleaner output.

Gotcha — Gemini OAuth: Gemini supports both API keys and OAuth. The OAuth path (src/gemini_auth.py) exists because some users have Gemini access through a Google Workspace account but not a paid API key. It's a separate module; if you don't need OAuth, you can ignore it entirely and just use API key mode.

Gotcha — the since_ts window: The app tracks the last time the user was "active" (connected and in a channel). When they reconnect or trigger the summary manually, since_ts is set to that last-active timestamp. There's no hardcoded 30-minute window — the window is "everything you missed." This makes the summary context-aware rather than time-bounded.

---

On your testing plans

Looking forward to your notes. A few things that are worth exercising specifically on macOS with VoiceOver + Braille:

• The channel list (Tab 2) — navigate with arrow keys, check that channel names with ★ (favorites) read correctly
• The user context menu — right-click or VO+Shift+M on a user, check the TTS mute toggle
• Cmd+F in the chat tab — should jump focus to the search field
• The About dialog (Help → About) — you should now see yourself there

If anything reads badly on a Braille display, that's the highest-priority category of feedback for me.

---

On the iOS brief

I'll put together a short doc on the AVAudioEngine voice processing I/O node approach and post it here. Probably next week — want to make sure it's specific enough to be useful rather than just gesturing at the API.

Best,
Florian

P.S. — The collab invite stands. Tread carefully as you planned, but if you ever want to push a small fix or open an issue directly, the repo is yours.

[fla-rion]

Hi Mathieu,

just shipped v6.10.0 — three new features, two of which are directly inspired by ttaccessible's architecture:

VoiceOver-native TTS backend (macOS)
In the "System & TTS" tab there's now a "TTS engine" dropdown: espeak-ng (existing) or "VoiceOver (macOS)". The VoiceOver mode uses the same AppleScript approach as your VoiceOverAppleScriptAnnouncementService — tell application "VoiceOver" to output "...". This means TTS goes through the user's already-configured VoiceOver voice instead of espeak-ng. For VoiceOver users this is a significant upgrade in voice quality and consistency.

Away/Back TTS announcements
New TTS event "Away/Back" (off by default). When another user switches to away mode or comes back, it's announced: "Name ist jetzt abwesend" / "Name ist wieder verfügbar". Implemented by tracking nStatusMode per user in a local cache and detecting bit 1 (STATUSMODE_AWAY) on USER_UPDATE events — the same pattern as your VoiceOverAnnouncementPreferences.disabledSessionHistoryKinds.

⌘K Quick channel switcher
A floating search dialog that opens on ⌘K. Type to filter all available channels in real time, Enter to join the selected one. Closes automatically after joining.

Release: https://github.com/fla-rion/TeamTalk-VO-Client/releases/tag/v6.10.0

— Florian

[fla-rion]

Hallo Mathieu,

ich wollte dich kurz über v6.10.1 informieren, das soeben veröffentlicht wurde:

Neue Features in v6.10.1:

• Mediendatei-Stummschaltung (⌘Ctrl⇧M): Ausgewählten Nutzer in der Nutzerliste per Tastenkürzel bezüglich seines Mediendatei-Streams stummschalten/entstummen.
• Per-Kanal TTS-Stummschaltung: Im Kanalkontext-Menü kann man für jeden Kanal TTS-Ankündigungen (Beitritt/Verlassen) stummschalten — nützlich für sehr aktive Kanäle.

Release: https://github.com/fla-rion/TeamTalk-VO-Client/releases/tag/v6.10.1

Grüße,
Florian

[math65]

Hi Florian,

Massive thanks — the three writeups are exactly the kind of context I needed. The "why" behind each design (length-sorted regex, kind string tagging, short prompts to avoid meta-commentary getting read by TTS) is way more valuable than just reading the code. The fallback chain on the AI summary and the no-fixed-window approach are both nice touches I wouldn't have landed on by myself.

Also seriously impressive turnaround on v6.10.0 and v6.10.1 — the VoiceOver-native TTS backend and the away/back tracking via nStatusMode bit 1 are clean ports. Glad the patterns translated well.

I'll work through your testing priority list (channel list with ★, user context menu, Cmd+F, About dialog, Braille) over the next few days and report back with anything that reads badly.

Looking forward to the iOS brief whenever it's ready — no rush.

Thanks again,
Mathieu

[fla-rion]

Hi Mathieu,

v6.10.2 ist gerade erschienen, direkt von ttaccessible inspiriert:

• TTS Anmeldung/Abmeldung — Server-Login/Logout-Ereignisse haben jetzt einen eigenen Toggle, unabhängig von "System vorlesen" (entspricht eurer userLoggedIn/userLoggedOut-Granularität)
• TTS Kanal-Datei-Ereignis — wenn eine Datei im Kanal erscheint oder entfernt wird, wird der Dateiname via TTS angesagt (fileAdded/fileRemoved)
• macOS say-Backend — drittes TTS-Backend "macOS say (Stimme wählen)": nutzt den macOS-say-Befehl mit einem Dropdown aller Systemstimmen (Alternative zu VoiceOver-AppleScript und espeak-ng)
• Jitter-Buffer SDK-Anwendung — die bestehende Einstellung "Adaptiver Jitter-Buffer" ruft nun tatsächlich TT_SetUserJitterControl mit bUseAdativeDejitter=true auf wenn ein Nutzer beitritt
• Aufnahmemodus — beim Start einer Aufnahme Auswahl: zusammengemischt / pro Nutzer / beides

Release: https://github.com/fla-rion/TeamTalk-VO-Client/releases/tag/v6.10.2

Grüße,
Florian

[fla-rion]

Hi Mathieu,

v6.10.2 just shipped — all four features directly inspired by ttaccessible:

• TTS: Login/Logout toggle — server login and logout events now have their own toggle, independent of the "System" TTS switch (mirrors your userLoggedIn/userLoggedOut granularity)
• TTS: Channel file events — when a file is added or removed from a channel, the filename is announced via TTS (fileAdded/fileRemoved)
• macOS say backend — third TTS backend "macOS say (choose voice)": uses the say command with a dropdown of all system-installed voices, as an alternative to the VoiceOver AppleScript approach and espeak-ng
• Adaptive jitter buffer (SDK) — the existing "Adaptive Jitter Buffer" setting now actually calls TT_SetUserJitterControl with bUseAdativeDejitter=true when a user joins a channel
• Recording mode — when starting a recording, choose between muxed / per-user (separate) / both

Release: https://github.com/fla-rion/TeamTalk-VO-Client/releases/tag/v6.10.2

Best,
Florian

[fla-rion]

Hi Mathieu,

v6.10.3 just shipped — four more features directly inspired by ttaccessible:

• AVSpeechSynthesizer (PyObjC) backend — new TTS engine that calls AVFoundation directly via PyObjC, bypassing the say subprocess entirely. Supports per-utterance rate and volume, and voice selection by name via AVSpeechSynthesisVoice.speechVoices().
• TTS rate & volume for macOS backends — two new sliders (0–100) in the TTS settings panel. For the say backend the slider maps to WPM (50–400); for AVSpeechSynthesizer it is passed directly as the utterance rate.
• Per-type background notification mode — the three on/off checkboxes for background notifications (private / channel / broadcast) have been replaced with four-way Choice menus: Off, Notification, TTS, VoiceOver. Inspired by your BackgroundMessageAnnouncementMode enum.
• Auto join root channel — new checkbox in General settings: after login the client automatically calls on_join_root(). Analogous to your auto-join root behavior.

Downloads (macOS DMG): https://git.garogaming.xyz/flarion/TeamTalk-VO-Client/releases/tag/v6.10.3

Thanks for the feedback on the writeups — glad the why was more useful than the code alone. Looking forward to your accessibility notes when you've had a chance to test.

Best,
Florian

[fla-rion]

Hi Mathieu,

Just released v6.10.4 with three more features inspired by your ttaccessible codebase:

• Per-user stereo balance — right-click any user in the channels list to set their audio to Normal, Left-only, or Right-only. The preference is saved per username and reapplied automatically when they rejoin.
• Persistent session history — connections, channel joins/leaves, and user logins/logouts are logged to a JSONL file in the app data directory. You can export it as plain text via File → "Export session log…".
• Smart audio device resolver — on auto-init after login, the app now prefers built-in microphones over virtual loopback devices so you don't accidentally end up with a silent input.

Download: https://git.garogaming.xyz/flarion/TeamTalk-VO-Client/releases/tag/v6.10.4

Thanks again for the inspiration!