joren-

I'll make sure that the script is idempotent.

As mentioned below I have been building the 'read' side of this: a data publication platform. I wanted to avoid any server side components. The communication / write part and updating the server-side sqlite database would need running components on the server which I wanted to avoid.

The 'write' part would technically be very doable and not that different from other back-ends.

https://github.com/GhentCDH/Pihka

Looks like a good addition to the datasette ecosystem. I have been working on a similar idea with cusom html around sqlite databases. By default a faceted search interface is generated but by reusing the client side data layer, custom apps are made easy.

The design keeps data and presentation together and even maps do not rely on external services.

I have called it Pihka: https://ghentcdh.github.io/Pihka/ https://github.com/GhentCDH/Pihka

I think you just answered your own question: I do like a a boring os that gets out of your way, also on a desktop.

A bit of fun I had last night with running a HTTP request through a stupid amount of proxies. The main take-away is that a http proxy will not add too much latency, assuming fast interconnects. I would, however, not advise to chain 500 proxies.

Perhaps also of interest: A more curated example of a local initiative can be found here: https://kaart.gentgemapt.be/. This combines historical maps of a city in Belgium with information on local heritage.

Hi, thanks for posting this. I am the blog author and prepared the following as a Show HN blurb: Have you ever wondered how to improve human-flute-computer interaction, wonder no more: this project allows you to control a mouse cursor via sound.

The project is based on the Raspberry Pi Pico RP2040 chip and features an ANSI C fixed-point pitch estimation algorithm. Another implementation uses the Web Audio API. Join the flute-based mouse revolution today and experience H(F)CI like never before.

I am not entirely sure with were you are going with this comment but FYI here is an ffmpeg fork with the build system replaced with a "build.zig" file and the Zig build environment: https://github.com/andrewrk/ffmpeg I would assume that a C implementation of WebRTC would not differ much from other libraries and should be compatible.

This is a bit low on actual information but it seems a dead reckoning device based on a new type of - drift free? - accelerometer?

I do recognize that 'one of the first off-the-shelf devices for high-quality, real-time music applications' it is somewhat murky and a lot was happening in the late 80s, beginning 90s. This thread already contains pointers to other - more accessible alternatives. Giving more proper definitions helps: With real-time I mean that audio (or a MIDI event) can enter the system and, with a low latency in the order of 20ms, a sound can be produced. With high-quality I mean that it is capable to generate 16bit samples at 44.1kHz (CD-quality, at the level of human hearing). This combination made it one of the first (the first?) truly general systems for electronic music applications.

I have tried to compile the browser/editor, the worldwideweb.app, as well and failed, indeed due to having incomplete sources/dependencies. I did not look into it too much though with my main goal being to get music software running.

I have just finished restoring a NeXTcube and was surprised how modern the environment feels: neworking, interface, unix tooling, .. To get to know the environment I compiled the original httpd server and managed to get it compiling after only tweaking the makefile a bit, very similar to what still is sometimes needed on Linux.

The usability of the NeXT computers also had a lasting impact on interactive music applications with the introduction of MAX at IRCAM:

https://0110.be/posts/Electronic_Music_and_the_NeXTcube_-_Ru...

The NeXTcube is an influential machine in computing history. The NeXTcube, with an additional soundcard, was also one of the first off-the-shelf devices for high-quality, real-time music applications. Here a restored NeXTcube runs an early version of MAX, an environment for interactive music applications.

Perhaps the official release info is of more interest. This blog post is quite 'inspired' by it. It does mention the source but I do not see the added value of the blog post over the official release info:

https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-rele...

I do see some improvements for FFT workloads. The SIMD webassembly version is quite a bit faster. Try it yourself: https://0110.be/posts/pffft.wasm%3A_an_FFT_library_for_the_w...

For a Javascript YIN implementation, see https://github.com/peterkhayes/pitchfinder I have used it in a live spectrogram visualisation: https://0110.be/phd/presentation/spectrogram/live.html

To share my mistakes as well:

After launching a web app we noticed severe performance issues and had to roll back to a previous version. To identify the performance problems introduced in the new version, I wrote a script mimicking a thousands of typical user interactions. This also included sending email. In the moment, we forgot to properly configure the dev environment and the emails went out.. but it did not stop there.

This is a good decade ago and some clients still preferred to get faxes instead of emails. We used a service which automatically converted emails to fax messages. We tried to intervene but were not able to stop thousands of fax messages and basically DDOS'd many fax machines and then had to call the affected clients..

As an FYI, if you are interested in the fundamental frequency of birdsong the GitHup repo below might be of interest. It is an STFT + interpolation to get an accurate (potentially quickly changing) frequency estimate: https://github.com/JorenSix/stft_freq

To see the relation between spectrograms and fundamental frequency, based on this: https://0110.be/phd/presentation/spectrogram/live.html

These type of algorithms are only able to match audio when the audio was added to an index beforehand. So it only capable to match pre-recorded audio. A live rendition of a text or song would not work since it would not match the index.

Ah, I did not see that. Good to know that it is findable.

Another implementation of this algorithm can be found at [1]. It also includes several other algorithms for acoustic fingerprinting that can serve as a baseline. See [2] for a paper on one of the other implemented algorithms and a comparison.

[1] https://github.com/JorenSix/Panako

[2] http://www.terasoft.com.tw/conf/ismir2014/proceedings/T048_1...

In the publication below [1] a comparison with respect to latency is made between Teensy, Arduino Uno, xOSC, Bela, Raspberry PI and xOSC. One of the findings is that serial over USB is slower than Midi over USB while technically very similar. The Axoloti [2] is not included in the publication but is of interest as well when building low latency audio devices.

[1] http://www.eecs.qmul.ac.uk/~andrewm/mcpherson_nime2016.pdf

[2] http://www.axoloti.com/