stick to rand for portable This backs out commit 40c37b5c (use arc4random) except for the header include. Crappy old rand(3) is fine for this program. It's just bad form on OpenBSD and its linker spews an annoying warning about it. FWIW, Linux finally got arc4random(3) with glibc >= 2.36 (2022) so it could actually be considered fairly portable now. However, for the time being, I'd like to still support older systems. NB, the closest "native" alternative, getentropy(3), appears in glibc >= 2.25 (2017), so even it is not exactly ancient, yet. Thus, instead of mucking around with wrappers, feature flags and conditional compilation, rand() is still it for portable.

add a note about sndiod

note FreeBSD support

add /usr/local to search paths

update README (portable version, supporting Linux)

define a replacement for getprogname on Linux

replace pledge with a no-op outside of OpenBSD

define timespec helpers if missing

add platform.h (Empty for now.)

support gmake GNU make does not have $> (.ALLSRC) but $^ instead. The trick is to just use both since each implementation defines one but not the other. XD

use arc4random While crappy old rand(3) is fine for this program and uses arc4random(3) on OpenBSD anyway, the linker spews a warning about it and the noise during compilation is annoying me. FWIW, Linux finally got arc4random(3) with glibc >= 2.36 (2022) so it could actually be considered fairly portable now. However, for the time being, I'd like to still support older systems. NB, the closest "native" alternative, getentropy(3), appears in glibc >= 2.25 (2017), so even it is not exactly ancient, yet. Thur, instead of mucking around with wrappers, feature flags and conditional compilation, rand() is still it for portable.

add coefficient (basemul) for base weight

use overall rate as baseline weight

slightly reorder the code in cwinit

clean up return latency code in cwstop

remove debug output

reset the clock in cwstart This is a workaround to guard against the possibility that the onmove callback is not called at all. This happens if playback has not started before cwstop(), and hence sio_stop(), is called.

fix timing calculation Measure and take into account the "return latency" of cwstop(), i.e. the time it took between playback stopping ang cwstop() returning, usually negative.

try to figure out proper timing This is an intermediate commit of some experimental changes: - playback in synchronous mode (par.xrun = SIO_SYNC) - tracking of play position via sio_onmove() and total frames written - (broken/ignored) reporting of "time remaining" from sound() and friends - debug instrumentation (#ifdef DEBUGTIME)

UI styling

fix two typos Turns out my times were measured in centiseconds rather than milliseconds as advertised. Oops. Only discovered when looking to make them exact for the first time. Had mostly ignored the values as "probably way off anyway". That appears to have been an accurate assessment. X) It does show nicely how the algorithm doesn't care about absolute values. It operated just fine on centiseconds.

mention MORSE_LEVEL again in README

fix default values in NOTES

add CW_AMPLITUDE variable

add toc section to README