http_server VS exotracker-cpp

I use pony https://ponylang.io/ as a language - it's an Actor based language with GC where every actor has its own memory and is responsible for its own GC.

The main feature is its ability to safely share or move data around between actors in a way that is data-race and deadlock free. Pony doesn't use locks anyways :-)

A high level as to how it achieves this:

And it's not just the mathematics. The non-type-theoretic paradigm-upending let-it-crash-to-keep-code-correct resilience for which Erlang/Elixir is famous was one of the biggest eye-openers for me in my programming career (which began in 1972 when I was 12). Also, the simple behaviour and very high performance results of contemporary Actorish implementations, especially Akka.io and the in-some-ways-more-impressive ponylang.io and related ORCA GC ("concurrent and parallel garbage collector for actor programs ... does not require any STW steps, or synchronization mechanisms ... zero-copy message passing and sharing of mutable data ... data race free ... [no] read/write barriers"), are eye-catching affirmations of the Actor model's approach.

Being an unabashed Ponylang fanboy, I'd say that mutability is a separate question from the "actual" type. I'm simplifying a lot here, but generally in Pony you'd express this in a couple of different ways depending on whether you want the binding itself to be immutable or whether you only care about the instance itself:

There's an http server and a small "sinatra" like web framework.

- https://github.com/ponylang/http_server

- https://github.com/theodus/jennet

Someone might have done SQLite for Pony, but I'm not aware of it. Writing network protocol stuff in Pony is usually pretty easy and the C-FFI is usually pretty easy which generally makes writing database connectivity (for at least happy path basics) fairly easy. (Add lots of caveats here).

If you'd like to talk more in-depth, swing by the Zulip and myself and other folks from the community can help out with answers.

https://ponylang.zulipchat.com/

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).

I'm not optimistic on unit types myself. I've found that unit-named variables often with transparent type aliases as documentation (type Sample = usize, type Amplitude = i16/f32) have many of the advantages of distinct units, without their downsides compared to bare numbers. In several projects where I've used naming and transparent aliases comprehensively, I don't recall ever letting a unit mistake escape from my local tree into master, since I reread my own code when committing and merging. In one case (https://gitlab.com/exotracker/exotracker-cpp/-/blob/dev/src/... used to have two EXPLICIT_TYPEDEF) I did add distinct units because I found I was mixing together two types too often during development. Though I find that unit types come with significant disadvantages (ergonomic and semantic flaws) preventing them from being a catch-all solution:

- You need an implicit conversion to eg. size_t, otherwise you can't pass (smp: Sample) into array indexing like (amplitudes[smp]) or data slicing, without an extra conversion or accessing the underlying value like (smp.v). But you can't allow (smp += midi_pitch) to convert both arguments to int, then cast the result to Sample when assigning.

- You need some conversion to allow (smp + 1) with type either integer (convertible to Sample) or Sample, unless you want to annotate all arithmetic with boilerplate like (smp + (Sample)1), or (smp.v + 1). I've experienced this problem in my own code, and had to write (smp.v) when my compiler saw (smp + 1) and told me it didn't know whether to wrap 1 or unwrap smp.

- Expressions of type Amplitude * 2 should have type Amplitude. Go's time library gets this wrong, where multiplying Duration * Duration = Duration, which makes sense if Duration is an integer like i32 or i64, but not if Duration is a unit system dimension.

- (not a regression but a limitation) Units won't stop you from adding two temperatures in Celsius. To fix this you need separate coordinate and displacement types, which is a new pile of complexity.

- You may want distinct types for "samples/sec" and "cycles/sec". Modeling this in type systems has multiple current approaches, all of which rely on language support (F#) or complex type machinery I've had issues with.

- You can't easily convert between slices of f32 (like an audio buffer provided by the OS), and slices of Amplitude. Or worse yet vectors of f32 and Amplitude. (This problem affects bulk data in collections, more than scalar types generally passed and returned in the stack.)

I'd say https://gitlab.com/exotracker/exotracker-cpp has fairly decent code quality, but it's not feature-complete or useful, and I've put it on hiatus because it's a struggle to implement high-level editing, mouse interaction, copy-paste, etc.

Tagged unions of free-floating types (polymorphic variants, C++ std::variant) and enum holding cases namespaced within themselves (Rust/Haskell) are two alternative designs. I personally prefer having both in a language. But if only one is available in a language, I prefer free-floating types, since it's more flexible and allows using the same type in multiple tagged unions, and you can somewhat emulate enums using tagged unions and namespaces (like I've done in C++ at https://gitlab.com/exotracker/exotracker-cpp/-/blob/eb8458b2...). If you take that approach, to prevent collapsing in the generic case when two type parameters are the same, you'd have to define newtypes for each type stored in a union.

As someone who got into trackers after the "golden age", I wanted to comment with my perspective (focused on DSP, workflow, and chiptune):

I noticed the video in the page is a remaster. To my ears, it sounds like it's being played with non-Amiga interpolation with less spectral imaging/replication (often mistakenly called aliasing), altered panning (the Amiga has an infamously rigid hard-panning setup), and possibly eq/reverb mastering on top of that. Compared to a video with aliasing (https://www.youtube.com/watch?v=thnXzUFJnfQ, no clue if the Amiga low-pass filtering is accurate), I like how the remaster has less high-pitched whine, but I feel it's missing out on the spectral replicas which influence the original's sound.

> I could try “hiding” the loop point by adding fades in the beginning and end of the sample, and then overlapping the fade areas.

I've heard people saying that crossfading is effective at looping, but in my experience it's difficult to pick good crossfade regions which don't result in altered timbre or audible discontinuities. Good crossfades are still slightly visible in a spectrogram, and bad crossfades are visibly and audibly discontinuous.

I'm probably 30 years too late, but I implemented a more sophisticated (but more situational) algorithm which analyzes a sample as a spectrum, then resynthesizes it using a variation of the existing padsynth algorithm. This produces a perfectly looped sound with no discontinuities at the loop point (unlike crossfading), with built-in chorusing (not suitable for solo instruments), no attack phase (not suitable for staccatos or plucked/percussive instruments), unfortunately with a bit of metallic artifacting. A year ago I implemented a prototype at https://github.com/nyanpasu64/padsynth which could shorten choirs and create chorded samples, but I never fleshed it out into a user-friendly product.

Another idea I had was to resynthesize the "loop end" of a sample, altering the amplitudes and phases of the harmonics to line up with the neighborhood of the "loop begin" (I'm undecided on exactly how to tweak the pitch and amplitude, whether to use phasors on a plane without pitch shifting, or shift pitch, or what), or crossfade while preserving the amplitudes of each harmonic, etc. This would preserve the majority of the original sample, making it useful for soloed instruments (though more difficult to use for chording samples). Sadly I haven't actually implemented this.

> A common trick to emulate a rhythmic delay effect was to use a short staccato instrument, play a melody with it, then manually go through every empty row on the same channel, copy & paste the note from a few rows above with a reduced volume, and repeat this until all rows were used.

0CC-FamiTracker and forks partly automate this process using an echo buffer command, which acts like a note with the same pitch as 1-4 notes above.

I believe trackers need more innovation, better commands (duration-target pitch/volume slides, graphical editing), better ways of managing state (eg. effects ringing on for longer than you want, or the wrong effects being active when a song loops), and better support for non-grid-aligned notes. I don't have all the answers yet, sadly. I've been working on https://gitlab.com/exotracker/exotracker-cpp but it's stuck in development hell.

> A simple and restricted composing environment like a four channel tracker with a limited amount of samples guarantees you can’t spend half a day tuning a kick drum sound.

I think that partly separates sample-based trackers and General MIDI formats (primarily based around prerecorded sounds, MIDI has practically no customization at all) from chiptune trackers (full-on synthesis, and FM chips can have nearly as many parameters as a modern VST, but less flexibility and harder to achieve a sound you want).

I came up with a "almost too clever" way to reduce the tedium of writing command objects. Most command APIs expect you to write a separate redo and undo method, and possibly even a separate "apply" method. Instead I created a `BaseEditCommand` interface where each command object subclass precomputes the new state of the altered portions of the document. When the command is applied, the undo system calls `apply_swap(self: &mut dyn BaseEditCommand, &mut Document)` which swaps the Document's old state with the BaseEditCommand's new state. To undo the change, you merely call `apply_swap` a second time, which swaps the old state from the edit command back into the document (saving the document's new state in the edit command). To redo the change, you merely call `apply_swap` a third time.

It has the same tradeoffs as the usual command/action pattern (richer information about what was changed, but you have to implement a new type for each operation, and might end up copying a lot of memory anyway). However it's a lot easier to implement each command (less boilerplate, somewhat lower risk of implementing undo/redo incorrectly and altering state). As a bonus, apply/undo/redo perform zero memory allocations, because they only swap data, not copy or destroy it.

One arguable downside is that you can't transplant the same command from one point in the history to another (but most undo commands in traditional applications, as opposed to VCS systems or nonlinear editors, aren't built to do that either). And I'm not sure my "can_merge" system (which merely drops commands rather than bundling or intelligently combining their contents) was a good idea, since all mergable commands must alter the same state.

API: https://gitlab.com/exotracker/exotracker-cpp/-/blob/dev/src/...

i have the unmet rambling dreams of the first person, and the anxiety-driven perfectionism and revulsion to poorly written code of the second person... so i'm unhappy thinking about bad programs, unhappy writing new programs, and unhappy fixing old programs.

"i can only do so much and of course it's never enough"

i want the perfect programming language, the perfect gui library api and theme, the perfect program, the perfect ide... and i can't accomplish a single one

and of course c++ is an all-devouring Cthulhic monster that does everything poorly, Rust has immature gui libraries and doesn't fully align with my values and desired features (I want linear typing, strong typedefs/subclasses of integer types, polymorphic variants/anonymous unions, prioritizing iterator generators over async), qt is basically legacy code and Qt Widgets is mostly unmaintained but difficult to fork (to build, create Windows installers, and convince Linux distributions to accept behavior-changing bug fixes), and my personal dream project (https://gitlab.com/exotracker/exotracker-cpp) is vaporware no matter how much i burn myself out making it (trying to both explore new ideas, and engineer them well, at the same time).