New Accessible TeamTalk Client for Mac – Looking for Beta Testers

By Mathieu, 18 March, 2026

Forum
macOS and Mac Apps

Hello everyone,

I've developed a native TeamTalk client for macOS that's fully accessible with VoiceOver. As you know, the official TeamTalk version on Mac is completely inaccessible, so I built an alternative from scratch.

What's included:

  • Full keyboard navigation β€” Cmd+1/2/3/4 for UI areas, F5 for nickname, F6 for status, etc.
  • VoiceOver announcements for all events (users joining/leaving, private messages, file transfers)
  • Native macOS interface (no ugly web wrapper)
  • Saved server management with quick access
  • Browse and join channels with optional password protection
  • Private messaging with full conversation history
  • File sharing with visual progress indicators
  • User administration (for server admins)
  • Advanced microphone settings:
    • Enable/disable audio processing
    • Noise suppression (Noise Gate) or Expander with fine-tuned controls over threshold, attack, hold, and release
    • Peak limiter with auto or manual mode
    • Multiple presets for different use cases
    • Professional-grade tools to eliminate feedback and control voice peaks

Current state:

The app is functional and ready to use. The interface is clean, accessible and looks good β€” because using VoiceOver doesn't mean the UI has to be ugly.

Important:

The app is unsigned (no budget for Apple Developer Program yet). You'll need to authorize it in macOS security settings.

Interested?

If anyone wants to test, I can set up a beta distribution system. Your feedback on features, keyboard shortcuts, or missing functionality is welcome!

Options

Comments

By AppleVis on Friday, April 3, 2026 - 21:50

Member of the AppleVis Editorial Team

Hi all,

Friendly reminder that while we do now allow the usage of mild profanity on AppleVis when used for emphasis or expression, strong, sexualized, or graphic profanity--including words like the F-bomb--is prohibited under all circumstances regardless of context. Any posts containing strong profanity may be subject to removal at moderators' discretion.

Thanks,

The AppleVis Editorial Team

By Jonathan Candler on Friday, April 3, 2026 - 22:23

Then you need to tell us what's aloud and what is not, because yall lifted profanity restrictions but you never told us what we can and cannot use and in the case of context, what contexts. Not my issue if I didn't know. Note I'm not the only one who expressed this neither, a few members did in said mod thread. Sighs the double standard astounds me! Great you lifted and relaxed the profanity restriction and my mind went, kay as long as I'm not harming anyone we good. You should have told us in the beginning what was aloud and is not from the very beginning and sorry if I do not look at the rules as much. Didn't know I needed to. Maybe if a list was provided I would have known but sorry if I didn't.

By AppleVis on Friday, April 3, 2026 - 22:57

Member of the AppleVis Editorial Team

Hi Jonathan,

The below is taken from the original post announcing the loosening of profanity restrictions:

  • While discouraged, limited use of mild profanityβ€”defined as non-sexual, non-graphic language generally considered acceptable for a broad audienceβ€”may be permitted when used sparingly for emphasis or expression. Such language must not be used to harass, intimidate, demean, or degrade any individual or group. Profanity that is strong, sexualized, hate-based, or graphic is strictly prohibited, regardless of intent or context. Determinations regarding what constitutes β€œmild” versus β€œstrong” profanity are made at the sole discretion of the AppleVis Editorial Team and will be evaluated on a case-by-case basis in accordance with this policy.

While we appreciate that some may disagree, we believe the F-bomb falls into the "strong profanity" category. We have addressed other instances of usage of that word as they have arisen, including in the original thread announcing the changes. It is our strong preference to avoid content removal unless it is absolutely necessary, thus the community reminder.

By Dan Eickmeier on Saturday, April 4, 2026 - 02:14

I agree about the iOS app, Jonathan, and its lack of file sharing and managing user accounts on a server. Those things should be able to be done on iOS as well, but who knows if the developers there, will do anything about that. It's awesome that Mathieu here, is working on this alternative to the QT client on the Mac side, as things that worked ok, previous to version 5.18, or maybe 5.19, of the QT client, are seriously not since then. This alternative in the TTAccessible app that is in development here, is working absolutely great so far, and is becoming my go to TT client on the mac. It is what a Mac TT client should be. Nice, accessible, and putting VO users first. Back when you could arrow through lists in the QT client, I found there was a bit of a lag, between the time when you'd arrow, and things would be spoken, and if you went to quickly, things would be missed. Unlike that, this is very very nice and responsive. Beta 5 and its added features, are working well.

By Johann on Saturday, April 4, 2026 - 02:15

Edit: yeah, this crashing is actually quite bad, it even does it when I get a private message LOL.
So, I'm experiencing more random crashing in this version, like when sending a channel message the app crashes, even when just command tabbing back to its window also crashes it.
Aside from that, good work on this, the auto recording works fine, I have yet to test some of the other stuff.

By John Lipsey on Saturday, April 4, 2026 - 17:07

I'm beyond excited to try this out when I get home from work tonight. It's probably loads better than my current solution to mac TT accessibility, which is to download and run the iOS version on my M1 Mac.
This should be night and day better experience wise.

By Mathieu on Saturday, April 4, 2026 - 17:29

Hi everyone, beta 6 is a quick follow-up to fix crashes reported in beta 5.

Download: ttaccessible-1.0.0-beta.6-1.zip

@Johann β€” Sorry about the crashes! There was a bug causing the app to crash when sending or receiving messages. This is now fixed.

@Dan β€” Thanks for the kind words, really glad the app is becoming your go-to TT client!

What's fixed in beta 6
  • Fixed a crash when sending or receiving messages (affected both channel and private messages)
  • Fixed potential crash with clickable links during window switching (Cmd+Tab)
  • Relative timestamps now show "now" instead of "in 0 sec" for recent messages
  • Relative timestamps auto-refresh every 60 seconds

By Jonathan Candler on Saturday, April 4, 2026 - 18:14

How you gettin' round the TT sdk with out paying a shit load of money.

By Casey Reeves on Saturday, April 4, 2026 - 18:27

The tt sdk is basically in a permanent trial mode. You are not even forced to stop using it after 30 days have passed. You can just continue on using it. The so-called license on the website says that you are required to buy a license after 30 days have passed, and yet the software remains perfectly usable afterwards. Of course since he sells this so-called sdk at a totally insane price, noone will ever buy it.

Bit of a braindead move imho to make your sdk cost a ton because that just prevent ecosystem growt. Very stupid move indeed.

And even things like the tt media bot take this exact approach and don't pay for the sdk.

By Matthew Whitaker on Saturday, April 4, 2026 - 18:46

Using the latest version of the beta. After sending a channel message, I did shift tab to get out of the text field, then the app crashed. Just letting you know.

By Mathieu on Sunday, April 5, 2026 - 15:21

Hi Matthew, thanks for reporting this! I can't reproduce the crash on my end with Shift+Tab after sending a message. Could you provide more details? When the crash happens, macOS should show a crash report dialog with a text field containing detailed information. If you could copy that content and send it to contact@mathieumartin.ovh, that would really help me track down the issue. Thanks!

By John Lipsey on Sunday, April 5, 2026 - 21:28

I connected to a teamtalk where my account is set to autojoin a channel. My regular mac teamtalk client and iPhone teamtalk client respect this autojoining, but TTAccessible doesn't.
The autojoining is set at the account level on the server, not in my TT configurations.
I'm not sure why this is happening, but if you can look into it I would be most appreciative.

By Mathieu on Sunday, April 5, 2026 - 23:21

Hi John, thanks for reporting this!

You're right β€” the app wasn't actually joining the server-side autojoin channel. It was just detecting that one was set and returning early without doing anything.

This is now fixed in beta 7, which I'll post shortly. The app will now properly resolve the channel path and join it automatically on login.

By Mathieu on Monday, April 6, 2026 - 00:55

Hi everyone, beta 7 is here with a nice mix of bug fixes and a new feature.

Download: ttaccessible-1.0.0-beta.7-1.zip

@John Lipsey β€” Your autojoin issue is now fixed! The app will properly join the server-side autojoin channel on login.

@Matthew Whitaker β€” I also added proper Tab/Shift+Tab navigation between all UI areas, which should fix the crash you reported. Let me know if you still experience it.

What's new in beta 7

  • Copy Server Link (Cmd+Shift+L): Generate a tt:// link for the current server and channel. An editor lets you review the info before copying, so you can remove your credentials if you want to share the link publicly.
  • Open tt:// links: Clicking a tt:// link now opens TTAccessible and connects to the server automatically.

What's fixed in beta 7

  • Fixed server-side autojoin channel not being respected (the app detected the setting but never actually joined)
  • Fixed potential crash when pressing Shift+Tab after sending a channel message (missing keyboard navigation chain)
  • Fixed several force unwraps that could cause crashes in edge cases
  • Improved French localization: removed anglicisms, fixed awkward phrasing in several labels

By Johann on Monday, April 6, 2026 - 05:01

Can you perhaps make the keyboard shortcuts to subscribe/unscribe to events just control+numbers instead of command+control+numbers? Would be easier to press if that's the case.
Also, VO doesn't indicate that the subscription events are checked when they are, like voice for example.
And another thing, can you make the server/channel tree behave like in the qt client, where if you're not in a channel it's collapsed and auto expand when you join that channel, would also be helpful if VO says it if the channel is collapsed/expanded.
Thanks for all the work you're putting into this.

By Mathieu on Monday, April 6, 2026 - 09:39

Hi Johann, thanks for the suggestions!

Keyboard shortcuts

Good call β€” the subscription shortcuts are now just Control+number (and Control+Shift+number for intercepts) instead of Command+Control. Much easier to press. This will be in the next beta.

Subscription toggle state with VoiceOver

On my end, VoiceOver does announce "checked" or "unchecked" when toggling subscriptions. Could you give me more details about how you're accessing them? Are you using the menu (User > Subscriptions) or the keyboard shortcut directly? That would help me figure out what's going on.

Channel tree collapse/expand

Also done for the next beta β€” channels you haven't joined are now collapsed, and when you join a channel it auto-expands. VoiceOver announces "collapsed" or "expanded" when you navigate with VO+arrows, and you can expand or collapse channels with the right and left arrow keys. This is standard macOS outline view behavior, same as in Mail or Finder.

Thanks again for the feedback!

By Mathieu on Monday, April 6, 2026 - 15:26

Hi Johann, that's odd β€” on my end VoiceOver does announce the checked/unchecked state in the User > Subscriptions menu (for example I get "βœ“ Private Messages" when it's enabled). I'm on macOS Tahoe 26.4.

Could anyone else on the thread confirm whether they experience this issue? That would help me figure out if it's specific to Johann's setup or a broader problem.

Thanks!

By Dan Eickmeier on Monday, April 6, 2026 - 19:31

Hi, whether subscriptions are checked or not, is spoken just fine with VoiceOVer here. I'm also on the latest version of Mac OS Tahoe.

By Jonathan Candler on Monday, April 6, 2026 - 19:39

Will this be ported to IOS as well? If this thing has account creation and file sharing you'll blow the lazy ass TT devs out of the water and there's no excuse for not having account creation nor file sharing after all this time. I keep giving devs feedback after feedback about all of this as well as what I said above in my other posts here in this thread but they do not listen! Clearly they do not care at all about our suggestions.

By Matthew Whitaker on Tuesday, April 7, 2026 - 00:56

Just reporting a small issue I ran into. The text field for typing the default nickname was behaving oddly. When I tried to use Command + A to select all and delete the existing text, it didn’t work. Instead, anything I typed just started writing over the existing text in an inconsistent way.

I was eventually able to enter my name, but it was a bit tricky and confusing to navigate. Thought I’d pass this along in case it helps identify a bug.

By Johann on Tuesday, April 7, 2026 - 10:14

Uh, sorry for all the confusion LOL, turns out I wasn't focused on a user when trying to test that.
Maybe is it possible to make those menu items dimmed/disabled whenever you're not focused on a user, to avoid confusion?

By Mathieu on Tuesday, April 7, 2026 - 19:41

@Matthew Whitaker β€” Thanks for reporting the nickname field issue! I was able to reproduce it. What was happening: when you select all and delete the text, the field snaps back to the old nickname after a short delay (300ms), so it looks like your new text is writing over the old one. This is now fixed β€” the field will stay empty until you type a new name. The fix will be in the next beta.

@Johann β€” Good idea! I'll make the subscription menu items dimmed/disabled when no user is focused, so it's clearer that you need to select a user first. Coming in the next beta as well.

@Jonathan Candler β€” iOS is something I'd love to do eventually, but right now the focus is on getting the Mac version solid first. One step at a time!

By Nut on Wednesday, April 8, 2026 - 07:36

With Discord and possibly many other mainstream platforms going to require age varification down the road, TT might be the only viable platform where anonymity is still a thing.
Regarding the official iOS TT app it seems that a new update, v5.22, have just been pushed out but from the changelog it's nothing more than adding a new translation, easy login and a bug fix.

By Casey Reeves on Wednesday, April 8, 2026 - 08:13

Hi,
just used beta 7 this morning and it neither detected my loopback audio device nor my external headphones or airpods when connecting those. I had to quit the app and restart it again for them to actually show up. Still also has issue where if you plug in headphones and go into the audio settings it will will cut your audio so that others cannot hear you anymore until you restart the app.

Also hitting a very strange issue at random where the app starts behaving oddly without me dismissing the window and claiming that there are usable controls and yet no visible window all at the same time. Not sure why or what happens.

By Casey Reeves on Thursday, April 9, 2026 - 19:00

Hi, a friend of mine just hit a crash when trying to perform cmd+n to add a new server. He runs a mac mini with a m4 pro chip with an external display connected over hdmi -- not the apple one, to be fair.

Sounds to me as if there might be a race condition and a well hidden bug in TTAccessible code that might trigger this. Here is a link to the full crash report. Hope that helps to debug this problem.

By Mathieu on Thursday, April 9, 2026 - 19:37

Hi everyone, beta 8 addresses feedback from the thread and fixes a crash.

Download: ttaccessible-1.0.0-beta.8-1.zip

@Casey Reeves β€” The Cmd+N crash your friend hit on the Mac Mini is now fixed. It was a race condition during the server editor window layout. Also, there's now a Refresh Devices button in Preferences > Audio that forces the TeamTalk SDK to re-detect connected devices. This should help with AirPods and headphones not showing up.

@Johann β€” Subscription shortcuts are now just Control+number (and Control+Shift+number for intercepts) instead of Command+Control. Channels you haven't joined are now collapsed in the tree, and auto-expand when you join. The subscription menu items are also disabled when no user is focused.

@Matthew Whitaker β€” The nickname field issue is fixed. Clearing the field no longer snaps back to the old value.

If any of the bugs mentioned above are still present or if you run into new issues, please let me know β€” your reports are incredibly helpful. I can't test everything on my own, so thanks to all of you for taking the time to try the app and share your feedback. It really makes a difference!

By Johann on Friday, April 10, 2026 - 05:59

One annoying part of this is it keeps asking for my keychain passworld whenever I update to connect to servers, but I think it's because of the app being unsigned, right?
Also, can you add shortcuts for moving people, like the mulyt-select moving that is in the qt client, and shortcuts for kick/bann operations as well?
Also would love to have an option to disable the confirmation dialogs when trying to kick off a server.

By Quinton Williams on Friday, April 10, 2026 - 08:05

Hi.
First of all, I absolutely love having a macos teamtalk client which is fully accessible, so thank you very much for your work.
Regarding the bug, I noticed when I chose "both" for the "Single file (all voices mixed" option, the app doesn't seem to reflect the change. Additionally, the toggle for automatically starting recording doesn't seem to work either.
WHen I revisit this settings area, the changes do do appear to save, but I do suggest correcting this in the next update.

By Quinton Williams on Friday, April 10, 2026 - 08:11

One last thing, I can't figure out how to add custom sound packs. Is this supported, or am I missing something?

By Johann on Friday, April 10, 2026 - 09:07

Edit: OK, it seams the problem is with user voluumes I just checked and it's so weird, like my volumes are like, 20 for one user, 40 for another etc. I didn't even change it, this was on a fresh restart of the app, it seams to set random volumes for each user.
Isn't 50% supposed to be default, it mmight also be that when I adjust volume for one user it adjusts the volume for everyone or something.
Hey, over the passed few versions I've noticed the default 0DB master volume has gotten quieter.
And me on my friends always use the same mic gane on the server, so that's not the issue.
It's just that if I turn it up to like 5db, the recordings made the program would start distorting.
Also one more thing, can you add the command I shortcut to view user info?

By Casey Reeves on Saturday, April 11, 2026 - 07:36

I'm so very sorry to have to report that once again, audio is causing trouble.

I can't actually get external headphones, be it wired or wireless ones to work unless I restart the app, still.

I am nott sure how to fix this, but... I'd like to have a crack at it. Would there be any way you'd be amenable to sharing a link to the code?

I'm also still having trouble with echo cancellation. It's really, really not good. People still hear my screen reader, and themselves... And they also have trouble hearing me because their own sound is cutting my voice. I'm not sure if I'm making sense.

By Casey Reeves on Saturday, April 11, 2026 - 07:58

Also, auto away isn't, well... Exactly working.

It will enable itself at some point, it'll say, automatic away enabled. And then, about 5 seconds or so later, automatic away disabled. I didn't touch my mac or do anything. So that seems to enable itself then disable itself for no reason at all, so not working correctly.

By Mathieu on Sunday, April 12, 2026 - 19:36

What's new in beta 9

This is a big one. I went through the entire codebase, the TeamTalk SDK documentation, the Qt reference client, and all your feedback from this thread. A lot has changed under the hood.

Echo cancellation β€” completely reworked

The AEC now captures the actual speaker output from your Mac (using Core Audio taps on macOS 14.2+), instead of only using the decoded TeamTalk audio as a reference. This means VoiceOver, system sounds, and any other audio playing through your speakers is now part of the echo reference signal. The result is dramatically better echo cancellation β€” it actually works now.

I also enabled WebRTC's built-in noise suppression alongside the AEC, which helps clean up background noise and improves echo detection accuracy.

If your Mac runs macOS 14.2 or later, this happens automatically. On older systems, it falls back to the previous method (TeamTalk audio only).

Audio engine fixes

  • Fixed a memory issue in the audio capture buffer that could cause crackling on some devices
  • Fixed an audio format mismatch when echo cancellation was enabled that caused distortion
  • Sound packs now load in the background instead of blocking app launch β€” the app starts much faster
  • Sample rate changes on your audio interface are now detected automatically (no need to restart)
  • When your mic fails during a device change or channel switch, the app now plays a sound and updates the UI instead of silently stopping transmission

Device handling

  • Plugging/unplugging audio devices now properly updates the device list in real time
  • The internal aggregate device created by the audio engine is hidden from the device list
  • Master mute is no longer lost when you plug in headphones
  • Output device failures are detected and the device is automatically reopened

Per-user audio

  • Volume settings are now properly restored after reconnecting to a server
  • Stereo balance (left/right speaker) is now saved per user, just like volume
  • Adaptive jitter buffer option in Preferences > Connection β€” improves audio quality on unstable connections
  • User info (Cmd+I) now shows voice packet loss percentage for diagnosing audio issues

Server administration

  • Server property changes from other admins are now reflected in real time
  • New "Save Server Configuration" menu item for admins
  • Last login time is now shown in the user accounts list
  • Recording is blocked with a clear message in channels where recording is not allowed
  • Nickname and status change are disabled when the server locks them

SDK improvements

  • Subscription commands are now batched (2 commands instead of 11 per user β€” prevents server anti-spam from rejecting them)
  • Muxed recording now uses the newer SDK API and includes media file audio, not just voice
  • Per-user recording uses an extra delay to avoid truncated files on unstable connections
  • Better error messages from the SDK are now shown to the user
  • Internal SDK errors during a session are logged and displayed in the history
  • UDP and TCP ping times are shown in server statistics

A note about development

TTAccessible is becoming a pretty complete TeamTalk client at this point, and I'm really happy with how it's shaping up. I should be transparent about my process β€” I rely heavily on Claude (Anthropic's AI coding assistant) throughout development. It's been an incredible tool for understanding the SDK internals, catching tricky audio bugs, and working through complex CoreAudio and WebRTC integration. I handle the design, testing, and direction, and Claude helps me implement it all much faster and more reliably than I could on my own. It's a great example of what's possible when you pair human intent with AI capability β€” especially on a niche project like this where accessibility matters but resources are limited.

Thank you all for the incredible feedback. Every bug report, feature request, and suggestion from this thread has directly shaped this release. Keep them coming!

Download

ttaccessible-1.0.0-beta.9-1.zip

By Casey Reeves on Sunday, April 12, 2026 - 19:51

Holy damn, talk about some massive rework!

I've just tested the new AEC and it sure works a ton better than it did before. I like it a lot. I will try out the audio devices too, but hopefully this is now also fixed.

P.S: absolutely no shame in working using AI, I do the very same thing, both because I seriously couldn't code even if I wanted to, and because, I might as well do the things I need/have use for instead of just giving it up and being like, too bad, cause nobody will build it, like before. Some will no doubt criticize you for using AI, but honestly? Don't listen to them. I'd rather be able to make what I need using AI than being stuck unable to have the tools I want.

By Mathieu on Sunday, April 12, 2026 - 20:24

The source code for TTAccessible is now available on GitHub:

https://github.com/math65/ttaccessible

The project is licensed under GPL v3. You can browse the code, open issues to report bugs or request features, and contribute if you'd like. Build instructions are in the README β€” you just need Xcode and an Apple Silicon Mac.

@Casey β€” you asked about accessing the code, so here it is!

Releases with pre-built zips are also available on the GitHub releases page, so you can always grab the latest version from there.

By Johann on Monday, April 13, 2026 - 02:45

I'n not sure if you really should be including the SDK compiled in your repo. Mayybe a better idea would be to provide instructions on where to find/or compile it for those who really wanna build the client fro scratch.

By Casey Reeves on Monday, April 13, 2026 - 06:33

Well,, the only problem is that you cannot include anything but a compiled sdk in the repository. The teamtalk sdk has never, ever been open source. Nobody can build it but bearware.dk themselves.

I'll definitely be checking out this code, lovely! I'm all over this now, I really want to try a meaningfull thing to contribute.

The only thing we could do about the sdk I supose is include a download script that would go and download the prebuilt binary from bearware directly... That way you don't include the sdk itself, but you still make it easy to fetch.

By Mathieu on Monday, April 13, 2026 - 09:39

Thanks for raising this, Johann and Casey. You're both right β€” the compiled SDK shouldn't live in the git repository.

I've just pushed a change: libTeamTalk5.dylib and TeamTalk.h are no longer tracked in git. Instead, there's now a download script that fetches them from the official BearWare SDK:

./scripts/download-sdk.sh

It downloads the macOS universal SDK from bearware.dk, extracts just the dylib and the header, and places them in Vendor/TeamTalk/. You need p7zip installed (brew install p7zip). The README has been updated with the new setup instructions.

I'll be using the official SDK from now on. I was previously building a custom stripped-down version to keep the app lighter, but switching to the official binary is simpler and it also means TTAccessible can now run on Intel Macs too β€” the official SDK is a universal binary (arm64 + x86_64).

@Casey β€” glad you want to dig into the code! With this change the repo is much lighter to clone. Looking forward to your contributions.

By Johann on Monday, April 13, 2026 - 10:05

Is there a reason why your .dlib file is only like 40 MB, and the one it downloads is like 70MB? If possible I would like to use that smaller .dlib LOL, smaller app sizes are always better in my opinion.

By Mathieu on Monday, April 13, 2026 - 10:13

Good question! The previous dylib (~30 MB) was a custom build I made myself β€” arm64 only, with video, FFmpeg, Speex, and several other features stripped out since TTAccessible only needs audio.

The official SDK from BearWare (~68 MB) is a universal binary (arm64 + x86_64) and includes everything β€” video codecs, media streaming, etc. It's bigger, but it means TTAccessible can now run on Intel Macs too, and we don't have to maintain a custom SDK build.

The app itself will also be larger β€” the binary is now universal (arm64 + x86_64), so essentially double the code. The zip download goes from ~17 MB to ~36 MB. Not ideal, but that's the trade-off for Intel Mac support.

By Mathieu on Monday, April 13, 2026 - 10:15

Hi everyone, beta 10 is out!

Universal binary

TTAccessible is now a universal app β€” it runs natively on both Apple Silicon (M1, M2, M3, M4) and Intel Macs. If you know anyone still on an Intel Mac who wants to try it, they can now.

Official TeamTalk SDK

I've switched from my custom stripped-down SDK build to the official TeamTalk SDK from BearWare (v5.22a). This improves compatibility and simplifies the build process for anyone who wants to contribute.

Download

ttaccessible-1.0.0-beta.10-1.zip (36 MB)

Same as before β€” the app is still unsigned. If macOS blocks it, use System Settings > Privacy & Security > Open Anyway.

Let me know if anything breaks with the new SDK!

By Johann on Monday, April 13, 2026 - 11:03

Will it be fine if I just open issues for bugs/feature requests from now on? As to not clutter up this thread.

By Mathieu on Monday, April 13, 2026 - 11:14

Yes, it's fine :)

By Joseph King on Monday, April 13, 2026 - 18:38

Thanks for your work on This. I'm about to give this a go. So far it seems like it'll be a good app.

By Joseph King on Monday, April 13, 2026 - 19:32

There's a lot of good stuff here! A few requests that I have for the present are as follows:

1. Have an option in preferences to allow the program to connect to the last connected server upon startup.
2. Allow for custom audio quality settings to be chosen when choosing recording formats other than wav, and indeed ,to have other formats such as mp3 available for selection.
3. Not sure if this is already a thing, but if not, allow for the streaming of media files to channels that allow such, possibly with the keystroke CMD+S.