Dn-FamiTra VS redux-templates

blip_buffer and blip_buf are fairly decent tools for generating an output-rate signal from a high-rate signal (though I use my fork of blip_buffer at https://gitlab.com/exotracker/blip-buffer-exo and/or https://github.com/Dn-Programming-Core-Management/Dn-FamiTra...). When emulating sound chips, the blip buffer adds and subtracts bandlimited sinc impulses from an output-rate delta array, and when exporting resampled audio, it performs a running sum (transforming the impulses into steps) of the delta array and high-passes the running value when writing to the output audio array. The advantage is that you can pick very high sampling rates (like 1.79 MHz) but only burn CPU cycles each time the output level changes (unlike conventional resamplers which are O(input rate + output rate)). Unfortunately blip_buffer has a relatively low SNR of ~50 dB of aliasing rejection even at its widest impulse kernel (as measured by https://gitlab.com/exotracker/exotracker-cpp/-/tree/rewrite-..., though possibly blip_buf is better), and only performs an approximate highpass using integer bitshifts. A usage example is at https://github.com/Dn-Programming-Core-Management/Dn-FamiTra....

Alternatively you can generate a high-rate signal and feed it into a conventional resampler to produce a 44.1/48/96 KHz output. I found that libsamplerate (https://libsndfile.github.io/libsamplerate/)'s medium preset produces audibly transparent output at 44.1 KHz and above, and should have acceptable latency on the order of 1ms (I didn't verify but you could first flush out the startup edge effect with silence, pop all output, then push an impulse followed with silence until the central peak emerges from the output). This has minimal CPU usage for a single stereo 128 KHz input stream (like in exotracker and chipsynth SFC), but I don't know if it burns excessive CPU with 1.79 MHz input.

----

My baseline expectation for production-quality emulators is to generate sound without aliasing, but the gold standard is to properly emulate the audio path as found on hardware, by feeding schematics through SPICE and/or pole-zero math to create an analytical representation of the filters, then verifying them against MDFourier tests (hardware recordings of broad-spectrum sound played by the console). Few emulators attempt to do this; according to https://bel.fi/alankila/modguide/interpolate.txt, UADE (an Amiga emulator) gets this right using a variation of the Blip_Buffer approach with longer precomputed(?) impulse responses specialized for Amiga filtering. Several chiptune tools properly model hardware filters, including the chipsynth family of audio VSTs (commercial); Dn-FamiTracker (an open-source NES composer) emulates FDS lowpass properly without aliasing, but only loosely approximates 2A03 lowpass and global highpass using blip_buffer's configurable filtering (impulse/step visualizer at https://gitlab.com/exotracker/exotracker-cpp/-/blob/rewrite-...).

If you choose to model a hardware filter using IIR filters (mathematical arithmetic based off a hardware model) instead of a large precomputed impulse response (like interpolate.txt and UADE), you'll get more accurate results if you generate audio at a high internal sampling rate, IIR-filter the audio at this high rate (ensuring the filter cutoff is well below Nyquist or half the sampling rate), then feed it into a resampler. If you use Blip_Buffer to generate 44.1 or 48 KHz directly like blip_buffer, and apply a filter with cutoff above 10 KHz or so, high frequencies will not be filtered accurately.

One interesting idea (combining blip_buffer's efficiency at handling sparse signals, and the accurate treble filtering enabled by a high intermediate filtering frequency) is running a blip_buffer-like system (with no highpass but a ~20 KHz lowpass) to downsample from a high internal rate to a fixed 128 KHz (for fixed filtering) or twice the audio rate (for efficient rational-factor downsampling), then performing hardware filtering there before downsampling using a resampler. The downside is that this stacks the latency and artifacts of both Blip_Buffer and the resampler, but if you make Blip_Buffer generate mostly-lowpassed audio and avoid generating nonlinear harmonics in filtering, you can use a faster second resampler that assumes its input is mostly lowpassed (using a narrower sinc kernel).

Frankly I feel state management is a difficult task on desktop apps as well, to the point that tracking spaghetti-shaped causation and control flow is beyond my mental abilities. Qt itself as well as many apps are rife with redundantly calculating state or redrawing GUIs when changing the same value multiple times, or changing two values which both affect an outcome (my StateTransaction pattern mostly alleviates this issue with a set of dirty bitflags and recomputing all state dependent on those bits, though the reactivity system is currently hard-coded and statically dispatched, and generalizes poorly to open-ended state or managing the local state of many dialogs of the same type). And one of the craziest errors caused by witnessing malformed intermediate values is https://github.com/Dn-Programming-Core-Management/Dn-FamiTra..., where a sloppily-written "load document" function redrew the UI in the middle of mutating document state, causing the GUI to crash after observing a broken invariant.

It saddens me that so much of research in developing better state management techniques is in such a bloated and dependency-laden environment as JavaScript on the web. I like QML's reactivity system, but its evaluation engine is JS-based, dynamically-typed, and dynamically-scoped, and the UI engine itself is a buggy mess. And GTK4's list APIs promise to be better than the clusterfuck of Qt Widgets/Quick's QAbstractItem{Model/View} system (which abstracts poorly over list/column/tree collections, and widget-internal, cross-widget, and cross-application drag-and-drop), but I haven't tried that either.

In audio code, I'd rather use a properly written wait-free SPSC queue, than a least-common-denominator messaging mechanism provided by the standard library like postMessage() (where both the Win32 and JavaScript version suffer from contention and cause audio stuttering, see https://github.com/Dn-Programming-Core-Management/Dn-FamiTra... and https://blog.paul.cx/post/a-wait-free-spsc-ringbuffer-for-th...), though I'm not sure if generic channel/queue objects are as bad in practice. And message-passing (with anything other than primitive types) is a pattern for sharing memory that, if properly implemented and utilized (you don't send a pointer through a channel and access from both threads/goroutines), ensures no more than 1 thread accesses the object in a message at a time.

I think most but not all code can be constructed using primitives like (regular or wait-free) message queues and (RwLock or triple buffer) value cells, but I think all concurrent code which communicates with other threads of execution needs concurrent reasoning to design and write correctly. In my experience, Rust marking data as exclusive or shared is quite helpful for concurrent design and reasoning, whereas prohibiting shared memory altogether reduces performance drastically but is no better at correctness. I think message-passing merely shifts data race conditions into messaging race conditions (but perhaps Go is easier to reason about in practice than I expect). In fact, message passing between separate OS processes per service (like PipeWire) turns multithreading into multiprocessing and distributed systems, making it harder to establish consistent execution states or data snapshots at any point in time, or reason about invariants.

And even code not intended to communicate between threads needs to take care that no state is shared and mutated by another thread on accident (I concede this is easier with JS Web Workers or Rust which restrict shared mutability, than C++, Java, or Go which don't).

Yeah, _please_ don't use `typesafe-actions` :)

It may have had some value before RTK came out, but a lot of the opinions and approaches shown in its docs lead you to write _wayyyy_ too much code. For example, we specifically recommend _against_ writing TS unions for action object types [0].

RTK completely obsoletes `typesafe-actions`, and the TS usage patterns that we teach today should result in a pretty minimal set of types that you need to write in your own code.

For a small example see the RTK+TS template for Create-React-App [1]. If you want to see what a real app codebase can look like, the client app for my day job at Replay.io is OSS [2]. It's admittedly a somewhat messy codebase due to its long evolution and legacy (started as the FF DevTools codebase, copy-pasted, and we've been slowly migrating to RTK+TS and modernizing it), but files like [3] show how I would write a real slice reducer with RTK+TS.

[0] https://redux.js.org/usage/usage-with-typescript#avoid-actio...

[1] https://github.com/reduxjs/cra-template-redux-typescript

[2] https://github.com/replayio/devtools

[3] https://github.com/replayio/devtools/blob/454804188d33900a26...

The recommended way to initialize a new app with React and Redux is by using the official Redux+JS template or Redux+TS template.

I learned the basics of react initially, and then when I started using typescript + react, I did so using the create-react-app typescript redux template. I found that having a template to build from was extremely helpful. I'm sure there are other good templates out there if you didn't want to worry about redux (I think it's good, but it's got it's own mental overhead), but being able to refer to the template implementation was extremely helpful, since the typings of some react things can be highly weird.

Please see the official Redux+TS template for CRA, which shows the correct "modern Redux" patterns in action, as well as the "Modern Redux with RTK" tutorial page and our recommended TS usage patterns.

btw, note that we have an official Redux+TS template for CRA that comes with RTK and React-Redux already configured.

Now the first two questions have been answered. Moving on to the next one, state management. I decided to use redux. Came across this amazing toolkit and this beautiful and friendly template template from the official reduxjs repository.