When I have a ProgressBar with the estimated time in the output and enable_steady_tick called, I expect the ETA to increase if nothing is happening to the progress bar, but currently it requires me to manually call ProgressBar::tick.

I noticed that most methods on ProgressBar use ProgressBar::update_and_draw, which calls Estimate::record_step, updating the remaining time estimate. The thread spawned for enable_steady_tick does not seem to do this, and I wonder if it should? I'm not sure if there's some other implications when adding this call to the enable_steady_tick thread.

Anyways, thanks for a wonderful library, it makes all my CLI tools so much nicer to use!

I personally haven't touched it in a while, but I think if we can resolve the outstanding issues on #242, we can get Gekkio to review.

I think my case was some (non-bindgen) part of the compile chain wasn't respecting the fact that LLVM uses \u{1} (I believe it appears as \01 in clang source) to indicate something about name mangling (that names are already mangled?)

Maybe this has been fixed in a newer version of clang? I'm glad nightly works for you, I hope it's a sufficient solution for you!

Apologies because my memory is a bit hazy, I believe I just added a part to my build.rs to remove the \u{1} (I can't remember if it actually turns into a _?)

Hi, I've made an attempt at documenting the shader build process in a PR. Hopefully it's clear and helpful!

This changelist expands the documentation around what it takes to regenerate/build the shaders.

Closes #346.

Performance issues on Windows when doing file IO are frequently down to virus scanners.

In case anyone is still running into this: I was recently observing the same slowdown as @PurplePowder while also working in a chromium fork on Windows. I added sublime_merge.exe to the Windows Defender exclusion list and (after restarting Sublime Merge just to be extra sure) things seem to be running significantly faster.

The fpp was 512 and the srate was 48000. I use portaudio with the ASIO driver for my Focusrite interface.

The aaron branch seems to work great! I had to fix a typo here https://github.com/jacktrip/jacktrip/blob/aaron/src/UdpDataProtocol.cpp#L833, but it otherwise works (maybe with lower latency than the QUdpSocket version? It may just be misremembering things). I'll update the title to reflect that its related to QUdpSocket.

Hi, I'm trying to run JackTrip v1.2.1 in hub mode on Windows 10 version 2004 (jacktrip -S) and have ports 4464 and 61000 open. When a client connects with jacktrip -C <ip address>, the server crashes almost immediately.

I've debugged the program in Qt Creator (qt 5.15.0, mingw 64-bit 8.1.0) and get a segfault somewhere on this line:: https://github.com/jacktrip/jacktrip/blob/v1.2.1/src/UdpDataProtocol.cpp#L323

The stack is as follows:

1 QNativeSocketEnginePrivate::nativeReceiveDatagram(char *, long long, QIpPacketHeader *, QFlags<QAbstractSocketEngine::PacketHeaderOption>)                         0x697aeb19     
2 QNativeSocketEngine::readDatagram(char *, long long, QIpPacketHeader *, QFlags<QAbstractSocketEngine::PacketHeaderOption>)                                         0x697ac5f1     
3 QUdpSocket::readDatagram(char *, long long, QHostAddress *, unsigned short *)                                                                                      0x697a0880     
4 UdpDataProtocol::receivePacket                                                                                                             UdpDataProtocol.cpp 323 0x40bfb1       
5 UdpDataProtocol::run                                                                                                                       UdpDataProtocol.cpp 521 0x40c599       
6 QThreadPrivate::start(void *)                                                                                                                                      0x68898eaa     
7 KERNEL32!BaseThreadInitThunk                                                                                                                                       0x7ff82cf76fd4 
8 ntdll!RtlUserThreadStart                                                                                                                                           0x7ff82d6dcec1 
9 ??                                                                                                                                                                                

The packet size n is 2064 and buf seems valid, so I'm unsure how to dig deeper since I am unable to step into Qt sources on Windows with MinGW (I think since it uses GDB instead of CDB). I'm not familiar with Qt Creator so please let me know if there's something I can do to step into the sources!