-- Leo's gemini proxy
-- Connecting to nanako.mooo.com:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
A new version of Benben, my VGM player, will be out soon! Probably before the end of November (if not before Thanksgiving in the US). This time around I focused more on the player than my underlying VGM library (YunoSynth), with the most visible change being an entirely new UI based on S-Lang. This new UI is laid out the same way as the old interface, but is faster, more amenable to changes in the future, and just simply looks nicer.
Under the hood, Benben now uses more multiprocessing. The UI, input, and emulators all run on their own "threads" (technically a Fiber; more on this below), and an overall manager spawns and communicates with them on the main "thread". It's actually the change in the UI that prompted this. Before the code that that handles rendering the VGM to a PCM buffer and sending it to the audio driver was somewhat interwoven with the UI itself. While this worked, it wasn't ideal, as it severely violated the principle of Separation of Concerns. So, I completely isolated the playback code from the UI, then decided to just make them run on their own "threads" to take advantage of modern CPUs. After all, Benben targets everyday desktop/laptop users, and users of AArch64-based machines like the PineBook Pro or the Raspberry Pis. All of these are mostly 4+ cores these days, going by the Steam Hardware Survey (this only covers x86, so I'm extrapolating based on experience for AArch64).
The downside is that, in order to properly implement this, I had to add an ugly kludge where Crystal's `main()` was overridden, and the `CRYSTAL_WORKERS` environment variable is forcibly ignored. See, Crystal doesn't have first-class support for true handling of threads. Instead, you spawn Fibers, which are then scheduled to run on "worker threads" (which are true threads, if -Dpreview_mt is used) by the runtime's own event loop. So to emulate the control I have in other languages over true threads, I've added this kludge so that the effect is always "one Fiber per worker thread".
On the chip side of things, I'm planning to implement port the emulator for the Y8950 for release. This is an OPL-based chip that was used with the MSX computer line. So more MSX music will be supported soon. There are also some small fixes and improvements to the other chips.
I'll make this as plain as possible: v0.4.0 will take a lot longer, so expect a much longer development period between v0.3.0 and v0.4.0. The reason is pretty simple: Benben and YunoSynth are both getting ported to Common Lisp. The threading issues are the main reason. Another reason is that I have direct high-level access to SIMD stuff with Common Lisp via a very, very nice API (SB-SIMD). The only two downsides to moving (back to) Lisp are that the resulting binary will be larger, and memory usage will increase by about 25 megabytes, neither of which are game changers given the target systems for Benben.
I'll also likely finish implementing the missing chips for v0.4.0
Technically the port is already started. My initial prototype for YunoSynth was in Common Lisp and has been updated to use the same internal architecture. And on Benben's side, I already have a mostly working player that I've written for fun. So porting is mostly just a matter of getting the chips and the new UI moved over. Of course, the chips make up the majority if the code :-P
The logistics of porting will be:
Finish v0.3.0 of Benben and YunoSynth. Release them.
Benben's current Crystal-based will live on its own branch once v0.3.0 is released. The trunk branch will then have all its code replaced with Common Lisp. Development will continue in the Benben repository.
The YunoSynth repository will remain in Crystal. Future work on it will be much slower, but I do expect to finish adding the remaining chips.
The Common Lisp version of YunoSynth is a fork named SatouSynth* and has its own separate repository. It already exists. It already implements these chips: YM2151, uPD7759, C353, C140, HuC6280, SegaPCM, Sega MultiPCM.
I want to be clear: I still love Crystal. I still plan to use it for my other projects. But it's apparent to me now that, in its current state, it's not the right tool for the job when it comes to multiprocessing/parallelism. Concurrency sure, but not parallelism.
Anyway, that's the plan. Expect v0.3.0 out soon, then a long pause for v0.4.0 (though I'll be sure to post updates on my Mastodon ^_^)
--------- Page served by Aya https://nanako.mooo.com/fossil/aya/ Aya is under the GNU Affero GPLv3 license
-- Response ended
-- Page fetched on Sun May 19 22:36:56 2024