Linux GUI generates no ASCII bitstream.

[Lalarian]

I am using the latest release static build.
Whenever I try saving an ASCII bitstream, just nothing happens. It does not crash. Console shows no error.
I am running arch Linux.

[tornupnegatives]

Hi! Thanks for taking interest in my (very neglected) project. I just downloaded the last release and tried on my machine (Ubuntu 25). I was unable to reproduce the issue. Could you provide me with some more information:

1. What kind of audio input are you using (format, sampling rate, number of channels)
2. Do other export formats work?
3. How are you launching the application?

[Lalarian]

Hello! Thank you for still answering :)

1. I am using WAV, 8kHz, mono, 16bit (generated by espeak-ng, converted and filtered using sox, and with these parameters supposedly best format for generating LPC supposed to play from an Arduino using Talkie Library)

2. The literal "export" (using the specific menu item for exporting the encoded sound as WAV) is working normally. But saving using the literal 'Save' function in the menu did not work, yet (So neither ASCII-Bitstream LPC nor binary LPC). BUT:
   I found the reason - kind of:
   Saving ASCII-Bitstream and binary will work, if I enter the filetype extension suffix manually. (.bin / .lpc ). It does not work if I do not enter the suffix manually. (I browsed the tmsexpress binary using an hex editor for finding the correct extension for ASCII files :) )
   So, more detailed: In the box at the lower right of the save dialogue I either chose binary or ascci. Then I enter a filename (like: alarm) and click save - nothing will be saved. But if I enter alarm.lpc, then an lpc file will be created. It will always be an lpc file after entering a filename with extension .lpc . And it will always be a binary when entering the file extension .bin . The 'ASCII / Binary' button does not have any effect. If slecting either ascii or binary would automatically add a filetype extension to the filename, then it would be working normally.

3. I cd into the directory of your static build and execute 'tmsexpress.sh'-

[tornupnegatives]

Thanks for providing more details. I believe that I have fixed the issue in MR #61. If you are able, please check out and compile the associated branch and let me know if it's working on your end. I can also provide you with a binary if need be. When I hear back, I'll merge the changes and create a new release :)

[Lalarian]

Hello! Thank you very much!
I think I could actually use a binary, because everytime I try building it myself, it won't work ( I get an deprecation error, about CMAKE < 3.5 being no longer supported.
I am able to circumvent this using "cmake -B build -DCMAKE_POLICY_VERSION_MINIMUM=3.5"

But the resulting binary always crashes when opening a WAV from the GUI:

DISABLE_LSFG=1 ./build/tmsexpress
qt.multimedia.ffmpeg: Using Qt multimedia with FFmpeg version n8.0.1 GPL version 3 or later
PEF
false
/usr/include/c++/15.2.1/bits/stl_vector.h:1263: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator [with _Tp = float; _Alloc = std::allocator; reference = float&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
Abgebrochen (Speicherabzug geschrieben) DISABLE_LSFG=1 ./build/tmsexpress

Of course it would be even better if you could help me getting the own build to run, so I learnt something about debugging build issues, instead of being dependent on premade static binaries.
All I can guess is that there's a function 'reference std::vector' being part of 'libstd'(?) which has an issue with some value being too big ..
I believe it wouldn't be optimal to try fixing this by modifying the code(?), as it builds fine for you.
My assumption is:
Either I'd have to install a specific older/newer version of this library, but of course in a way that it's only being used for this build, because otherwise it would break my system's depending packages.
Or would the only feasible way for solving this be creating an completely independent build environment using a setup identical to your's and build a static binary?

[tornupnegatives]

I am unable to attach the binary file in this thread, but I have created a branch for you to try. Please perform the following and let me know if you encounter any errors. The end result should be an AppImage that you can run on your system. The script is a WIP but will work on Linux. It assumes you're running Ubuntu, but it will work in Docker (ubuntu:jammy) if you're not. Sorry for the inconvenience.

$ git fetch --all
$ git switch 59-with-build-script
$ ./bin/build.sh

[Lalarian]

Thank you so much!
While Docker is kind of my Arch Nemesis, it seems I made it work:

I created and ran a persistent docker container: docker run -td ubuntu:jammy
and checked it's ID:
docker stats

CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
482f75867ae2 wonderful_engelbart 0.00% 39.43MiB / 38.4GiB 0.10% 707MB / 18.2MB 1.04GB / 1.96GB 3

And opened a shell inside:
docker exec -482f75867ae2 sh

then cloned the repository: git clone https://github.com/tornupnegatives/TMS-Express.git

and changed into it's directory:
cd TMS-Express/

First it would not work, because I had to install additional tools:
apt-get update && apt-get install build-essential && apt-get install zip && apt-get install sudo

It was then, that I noticed you had included a Dockerfile at docker/test.dockerfile which would have installed build-essential
(but misses zip and sudo installation).

then it built, using your instructions for changing the branch and executing he build script:
git fetch --all
git switch 59-with-build-script
./bin/build.sh

I then got a successful build:
.....
[appimage/stderr] Marking the AppImage as executable...
[appimage/stderr] Embedding MD5 digest
[appimage/stderr] Success
[appimage/stderr]
[appimage/stderr] Please consider submitting your AppImage to AppImageHub, the crowd-sourced
[appimage/stderr] central directory of available AppImages, by opening a pull request
[appimage/stderr] at https://github.com/AppImage/appimage.github.io
adding: TMS_Express-x86_64.AppImage (deflated 1%)

I then copied the AppImage to my host-system:
scp ./build/TMS_Express-x86_64.AppImage ladmin@work:/home//

Then I started the AppImage through my hosts's filemanager.
I saw you workarounded the issue by openening a window telling the user that either the lpc or the bin extension is required - which should solve the crash problem for those reading the message.

So thank you for helping me make this build work (And I even learned my first steps about Dockerfiles!) :)

The remaining question is: Isn't it possible to make the tool add the extension to the filename automatically, depending on what format has been chosen?