| Age | Commit message (Collapse) | Author |
|---|
|
It's a better, less verbose driver, and also this fixes an occasional
crash on boot.
|
|
|
|
|
|
This change introduces the ability to enable or disable the spoken interface/TTS from the on-device settings, either via the UI or the Lua console. This closes out the implementation of issue #245.
The TTS setting is only visible in Display settings if voice samples are present in `/.tangara-tts/` on the SD card.
Playback of new TTS voice samples is inhibited when TTS is disabled. By default, the setting is enabled, as the device will only play back TTS voices if samples are present on disk.
If you need samples to test TTS on your device, feel free to grab the voice samples I have at https://codeberg.org/tursiae/tangara-tts-samples. There's about 80-85% coverage of the UI, with the remainder to be added soonish.
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/251
Co-authored-by: Tursiae <git@tursiae.org>
Co-committed-by: Tursiae <git@tursiae.org>
|
|
This should help significantly with https://codeberg.org/cool-tech-zone/tangara-fw/issues/121, which seems to be caused by some SD cards being very picky about being the only SPI device on their bus.
Co-authored-by: ailurux <ailuruxx@gmail.com>
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/176
Co-authored-by: jacqueline <me@jacqueline.id.au>
Co-committed-by: jacqueline <me@jacqueline.id.au>
|
|
|
|
This replaces the previous system of a separate track and queue repeat, with a RepeatMode type with the following options and behaviours:
- OFF: No repeat, queue or track. When the current queue finishes, shuffled or otherwise, playback will stop.
- REPEAT_TRACK: The current track will loop indefinitely, unless next is explicitly called through some user action (ie using the next button in the now playing screen)
- REPEAT_QUEUE: The entire queue will repeat indefinitely. When shuffled is enabled this will repeat the queue with new combinations each cycle.
The repeat mode is persisted in non-volatile storage, so the behaviour will be consistent throughout restarts and queue replacements, and so the "queue repeat by default" use case can be met in this way.
In addition, I've made it work a little nicer when the queue runs out in the now playing screen, keeping the previously played track shown and playback can be continued by using the play button or by going to a previous song in the queue.
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/126
Co-authored-by: ailurux <ailuruxx@gmail.com>
Co-committed-by: ailurux <ailuruxx@gmail.com>
|
|
|
|
|
|
Previously we were doing it synchronously, which led to some odd looking
livelock stacktraces... we still don't have a consistent repro, but this
at least makes the stack when we mount a lot more predictable
|
|
This helps with boot time by preventing a ton of
disk I/O before the UI has had a chance to load.
|
|
|
|
Also power it down whilst we're locked. This saves about half a
milliamp.
|
|
Mostly for debugging, but also u can toggle fast charging off and on now
|
|
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/83
Reviewed-by: cooljqln <cooljqln@noreply.codeberg.org>
Co-authored-by: ailurux <ailuruxx@gmail.com>
Co-committed-by: ailurux <ailuruxx@gmail.com>
|
|
|
|
|
|
- fix a use-after-free involving the alerts container that was
happening when showing the first screen
- fix some issues where the splash screen wouldn't come up as early as
it needs to when another bootup task was making heavy use of the spi
bus
|
|
|
|
this improves our ability to detect terminals that support line editing
|
|
|
|
Includes some misc cleanup of haptic double-triggering (or
non-triggering), since those cases all end up being TTS event
double-reporting, which to me crosses the threshold from "annoying" to
"usability issue"
|
|
|
|
|
|
Includes no longer blocking the main menu on an sd card being inserted!!
|
|
|
|
|
|
|
