quik
quik copied to clipboard
octoshrimpy
✏️ [ FEAT REQ ] Quick Voice Message
Is your feature request related to a problem? If so, please describe the problem. Not a problem. Just a feature request
Describe the feature you'd like I'm really glad this fork exists and I want to thank you for your work. But I think, if it is technically possible, that having the ability to send voice messages would be a great plus.
I need to communicate with people that can't read and don't use signal / whatsapp / whatever. So I need to rely on Textra that I really want to ditch.
Additional context I'd be really happy to see this feature. Let me know if it is possible.
Thank you
one of the things i've been thinking about is STT on incoming messages (long press? swipe?) and TTS for sending written messages. having a "send audio receive audio" would be icing on the cake with the system.
Aren't there 3rd party tools already for TTS / STT ? Like Futo Voice Input ?
Anyway, if your answer means "yes it's possible" then I'm glad and hope you will be able to implement it soon :)
I'm marking this as postponed because still requires more thought. I do believe it's possible, but will require more thinking. :)
A good step would just be to make it possible to attach audio files, and to take a recording through an external recorder app's intent.
I think it's technically possible to send just any kind of file over MMS. Like I've sent PDF's over MMS before and the recipient was able to receive it. That was with fossify messages though. Currently, quik doesn't provide any way to attach either audio or pdfs.
So if Quik allowed itself to show up in any kind of file share intent rather than just photos, that would do the trick. I could then record a message and share it to quik.
The OP mentioned wanting to communicate with people that can't read... I've just submitted a new pr - https://github.com/octoshrimpy/quik/pull/202 - that enables inbox message TTS using the system TTS service on message swipe. it also includes a new widget that reads aloud all unseen messages - ie safe, 1-click method to listen to new messages whilst driving
This is a great step forward and an awesome feature. But that means the recipient has to use Quik. A "any file goes", as mentioned by @octoshrimpy would be the ideal solution :)
agreed. they are quite distinct features. i'm just scratching my own itch with the tts feature.
i'm also thinking of building some stt features next and started a new feature request for it - https://github.com/octoshrimpy/quik/issues/204
thanks gavine for this first work on the feature ! maybe it should be tracked in its own issue since it's related, but not directly solving this one ?
sure. i've opened a new feature request ticket - https://github.com/octoshrimpy/quik/issues/207
This is a great step forward and an awesome feature. But that means the recipient has to use Quik. A "any file goes", as mentioned by @octoshrimpy would be the ideal solution :)
As a random related thought, are there any good sms apps dedicated to blind inclusion? maybe @gavine99 would have his itches fully scratched if quik homepage had voice controls for sending messages, read last x messages from convo, open convo, etc. (likewise, this could be a module as mentioned in another issue!)
@octoshrimpy my 'itch to scratch' is mainly to learn android programming. heh. i think google already has read out loud (tts) and voice reply to messages (stt) if the app hooks into the right notification types and i think quik does use those hooks (??). i use grapheneos so i don't know much about the google stuff.
anyway, on this issue for short voice messages i intend to implement this after i fix a rendering bug i just found in my audio player code (doh!). i think on this issue the ui to be long-press-and-hold to start recording, and release-to-stop, on the send button similar to what another of my im apps does. slide to cancel recording. how does this sound for the ui?
how does this sound for the ui?
Sounds like exactly what we need.
Alternatively, you could replace the send button buy a "microphone" button when the text field is empty. With long press to record, slide up to lock record, slide left/right to cancel, hit the button to stop. Then it turns into the regular send button.
I'm no UI designer though, just an everyday user with few little ideas.
Alternatively, you could replace the send button buy a "microphone" button when the text field is empty. With long press to record, slide up to lock record, slide left/right to cancel, hit the button to stop. Then it turns into the regular send button.
This is how voice messages work in Signal, i use it a lot and like it very much. But i'm not blind, so i don't know if that would work for blind users 🤔
But i'm not blind, so i don't know if that would work for blind users 🤔
I'm not sure either. My experience is only with people that can't read, not visually impaired.
But I guess that if that's a solution used by mainstream apps like signal / WhatsApp it should work here too maybe ?
@tiritibambix @Cwpute @octoshrimpy i like the idea. how would i enter text first (the microphone would now be the send button) and then record audio?
maybe the send button starts as a mic then, after entering some text, changes to send button but does a fast animation (500ms ?) into a microphone and back to send button every 4-ish seconds to indicate that long pressing it would start audio recording ?? that might be too confusing for the average joe.
or we could increase the height of the message entry box and put a mic button above the send button. maybe a setting turns this on or off
I think the easiest way is to mimic what signal does: when the text field is empty, you see the mic. When you start typing it changes to send button with a fast animation like you suggested. And that's it ! Because if you start typing, that means you're not planning on using the record function, I guess ?
how would i enter text first (the microphone would now be the send button) and then record audio?
do you have a specific use case in mind ? i don.t see how that would be usefull. Fossify SMS Messenger has a button to add all kinds of files to a message, at any point, wether you have entered text or not. so in your case, even if you have already written text, you can still add a sound file from you recorder app. Alternatively, if the audio recording doesn't get sent right away after you end it, you could still be able to enter text, then press end to get both sent in one go. Or more simply: first send an audio file, then the text message, or vice-versa. is it crucial that the two of them are condensed in one message ?
Alternatively, you could replace the send button buy a "microphone" button when the text field is empty. With long press to record, slide up to lock record, slide left/right to cancel, hit the button to stop. Then it turns into the regular send button.
That is what I was about to recommend, as well. on long-press to record, if let go: send, but also offer a slide sideways/down to cancel, maybe?
changes to send button but does a fast animation (500ms ?) into a microphone and back to send button every 4-ish seconds to indicate that long pressing it would start audio recording ??
if anything, I'd prefer having the send button slide into view horizontally so both buttons (send and record) are visible, if going that route.
is it crucial that the two of them are condensed in one message ?
I believe the idea is to use the app as an asynchronous quasi-walkie-talkie.
I believe the idea is to use the app as an asynchronous quasi-walkie-talkie.
I'm asking about the text associated with the audio file: why would you need the text if you have the audio file, and vice-versa ? what makes it so important that the two are sent together ?
I'm asking about the text associated with the audio file: why would you need the text if you have the audio file, and vice-versa ? what makes it so important that the two are sent together ?
I can think of one good use for it. Part of my job is teaching music, so sometimes it's helpful to send a recording with a text description. But the text description can always be written after the audio is attached. I think that'd be for the best, actually. So while recording, there could be a way to end the recording without immediately sending it. Then, you could go back to writing if you need to.
It'd also let you listen back to your voicemail before sending, which is a huge huge plus.
Maybe you could even pause the recording, listen back, think about it, and then if something else comes to mind that you want to say, resume recording.
@Cwpute > Fossify SMS Messenger has a button to add all kinds of files to a message... pr https://github.com/octoshrimpy/quik/pull/230 just merged and is the same as what you mention - attach any file.
pr #230 just merged and is the same as what you mention - attach any file.
Wow, this is huge. Still have to record a voice note first, then compose message to recipient and select the message, but this is a HUGE step forward.
Good job !!!
agreed on all points. a more in-depth voice message would be fantastic, but may be scope creep, and a good proposal for a quik module: a separate app that adds functionality to the main app.
I agree on wanting to listen to recording before sending, but at that point having a dedicated recording app may be better ~~(for now?)~~
I personally think hold to record, let go to send, swipe down to cancel, swipe up to lock into recording and tap to send may be the best approach. and to send either a voice recording or text. I do see the need to reference audio in the text, but having those split should work okay, no? @anaskaejdar
Sounds great to me, @octoshrimpy
Using a dedicated app would be perfectly fine. I typically use email or signal for those kinds of purposes anyway. I wonder, then, whether Quik would reencode the audio to whatever quality level would bring down the filesize so it can actually be sent.
I personally think hold to record, let go to send, swipe down to cancel, swipe up to lock into recording and tap to send may be the best approach.
for me, i prefer 'let go to attach and tap to attach.' then normal send button to send. allows time to delete and re-record, or record another audio, or also attach a photo, add/edit text, or whatever the user wants to do before commit to send. i realise swipe down to cancel is possible, but still better, i feel, to have second action to send
instead of new button in the compose area we could add 'record a voice message' to the attach menu because it's kinda like, in it's nature, 'take a photo' ??
i did a test of an animated icon but it's too distracting and confusing;
https://github.com/user-attachments/assets/1e0bc5e0-798c-44c5-a310-a233d30ee41a
@anaskaejdar my thoughts is to encode integrated audio capture as mp3, mono, 8kHz, 48kb/s - ok for voice and similar wideband g722 - and allows about 2 minutes recording in 700kiB mms size. mp3 format because widely supported. no re-encoding of external audio files (maybe in future ??)
does anyone have any thoughts on the audio codec to use?
i expected to use mp3 because it was ubiquitous, but apparently android doesn't natively support encoding mp3. if you have an opinion please look here https://developer.android.com/media/platform/supported-formats and let me know which supported encoding format you think is good. for me, i now think amr wideband in .3gp (.3ga) container because it's widely supported on phones since pre-smartphones. ps. before you ask... i'd prefer to not introduce yet another setting to choose which codec to use
any other thoughts on recording codec?
my thoughts is to encode integrated audio capture as mp3 […] because widely supported.
Also consider using the .amr format (https://en.m.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec) which, althought the license isn't libre, was specifically designed for voice encoding and produces very small files
Also notesworthy about amr: although file size is great for bandwith, but the quality of the encoded file may not be to everyone's taste. For recordings of things other than voice, results may vary, but in my experience it's good enough for voice messages.
@Cwpute yeah, i was thinking amr wideband version so quality is better than narrowband version.