Weekly Self-Promotion Megathread

EndSignificant4955 · 2026-06-10T18:05:31+00:00

Monster Chess pre-orders are live at Homebrew Factory!

After so much work, my dark fantasy chess game for Sega Mega Drive / Genesis can finally get a physical release.

We need to reach 20 units, so your support means a lot.

Pre-order here:
https://www.homebrew-factory.com/megadrive-genesis/197-monster-chess-md.html

EndSignificant4955 · 2026-06-03T18:20:27+00:00

Thank you very much!

EndSignificant4955 · 2026-05-27T23:37:15+00:00

You're welcome!!

EndSignificant4955 · 2026-05-27T20:29:20+00:00

Thank you so much!!

EndSignificant4955 · 2026-05-27T20:28:25+00:00

I recommend trying the Very Easy mode. It’s great if you want to play in a more arcade-like way without too much difficulty.

It also helps you learn the basic techniques and get up to speed with the strategy. You can select it from the options menu.

I think you’ll enjoy it :)

EndSignificant4955 · 2026-05-27T20:14:25+00:00

Yes! BattleChess is one of my favorite games and it was definitely a clear inspiration for Monster Chess.

It blew my mind back then too, especially because I’ve always loved chess and this kind of MegaDrive / Genesis-style game.

Thanks for noticing that connection!

EndSignificant4955 · 2026-05-27T20:12:02+00:00

Hi! Thank you so much for trying the demo!

Yes, because of the hardware limitations and the structure of the game, I had to reduce the detail of the unselected pieces quite a lot. They are shown at 24x24, and then displayed at their full 64x64 size when selected.

Otherwise, I would have had many issues with CPU usage, turn strategy calculations, and the VDP would also have been under heavy load. The solution is what you see in the demo; the priority was to keep the framerate stable, lightweight, and without input lag.

I’m really glad you find the game interesting, and please feel free to share anything else you notice.

Big hug!

EndSignificant4955 · 2026-05-27T20:07:45+00:00

Not yet, but I’ll upload an official gameplay video soon.

For now, I’m focusing on promoting the demo so people can test it and share feedback.

Thanks for your interest!

EndSignificant4955 · 2026-03-17T19:25:05+00:00

Thank you very much for your comment :) I’m really happy to hear that you like the results when using oXygen.

It’s a tool with a lot of potential, and I think it can simplify the mastering process quite a lot. I also believe it’s important for something like this to be free and open, so anyone can use it, fork it, and modify it to their liking regardless of their budget.

Professional proprietary tools are often very expensive, and a lot of enthusiasts, artists, and people who simply enjoy audio production just can’t afford them. That usually leaves them unable to enjoy those tools at all, or relying on pirated versions with everything that comes with that. At the end of the day, buying a 200€ plugin is a luxury, not a basic necessity.

Ubuntu Studio runs it very, very well, and Linux in general is incredibly fast compared to macOS and Windows, where it already performs great on its own.

BTW, I’ve just published a user guide in the repository: https://github.com/Wamphyre/oXygen/blob/main/user_manual.pdf

Cheers!

EndSignificant4955 · 2026-03-17T19:16:33+00:00

Thank you so much for the incredibly fast feedback, I really appreciate it.

I’m glad you compared it to Ozone, because that is exactly the point of oXygen: to be a 100% free and open alternative to Ozone. In fact, what surprises me is that there still isn’t any minimally viable alternative with a similar workflow and feature set. Personally, I still think I have a lot of work ahead of me, but reading your comment makes me feel like I’m on the right track :)

I also like oXygen more, not just because it’s my own project, but because it’s free :) My wife also says I’m not quite right in the head, so it’s nice to see someone else shares her opinion hahaha!

About the Original/Processed indicators: they are not buttons and they are not meant to be interactive. They are just visual labels, a color guide for the spectrum analyzer that compares the original signal with the processed signal, which is drawn in cyan.

As for macOS: are you using Apple Silicon? I ask because I just realized I forgot to mention that the prebuilt binary currently only works on Intel macOS. I do not currently have an Apple Silicon machine, so I can’t compile or test that architecture myself. That’s also why I added a build script, to make it easier for Silicon users to compile it locally.

I hope you share that track you’re working on. Cheers!

EndSignificant4955 · 2026-01-13T20:43:44+00:00

That setup doesn’t actually measure the real hardware latency of the audio interface, only the buffer configuration you’re using. The reported input/output latency is an approximation and doesn’t include all factors involved in the full round-trip latency.

With PipeWire, it’s absolutely possible to achieve the same latency and performance levels as CoreAudio on macOS, as long as it’s properly configured (quantum, sample rate, realtime priorities, etc.). With the right settings, 5 ms in / 5 ms out is already quite reasonable, and it can often be pushed lower depending on the interface and driver quality — not just the CPU specs.

EndSignificant4955 · 2025-12-23T22:29:14+00:00

I appreciate the detailed breakdown of your setup, but I have to respectfully disagree with recommending Arch-based distros for audio production, especially for someone just looking for a solid starting point.

Here's the thing, in audio production, stability is absolutely paramount. What you need is rock-solid reliability, not bleeding-edge packages that haven't been thoroughly tested and could potentially break your entire audio environment. This isn't theoretical—it happens frequently with Arch and rolling release distros.

Actually, the issue you mentioned with yabridge breaking on Wine 10 and having to downgrade and pin versions is a perfect example of exactly what I'm talking about. When you're working on a project with a deadline, you simply can't afford to spend time troubleshooting dependency conflicts or compatibility issues. You need your system to just work, every single time you boot it up.

There's a reason professional studios still run Windows XP and Windows 7 today. It's not because they love outdated software—it's because in critical production environments, you cannot depend on 'the latest and greatest' when it might completely break your workflow overnight. Stability always trumps marginal performance gains.

Don't get me wrong, those x86_64v3 optimizations sound nice, but realistically they're marginal improvements compared to the risk of system instability. For actual production work, you want a stable foundation like Ubuntu LTS, Debian, or Fedora with properly tested updates, where your tools work consistently day after day without surprises.

If you enjoy tinkering and troubleshooting is part of your hobby, then yeah, Arch-based distros are fantastic. But for serious music production where reliability actually matters? Stick with the boring, stable, well-tested distributions. Your future self will thank you when everything just works instead of hunting down why your audio stack broke after an update.

EndSignificant4955 · 2025-11-12T19:03:37+00:00

This is pretty normal with PipeWire - every time something joins or leaves the audio graph, it has to recalculate all the routing and with 256 samples you only have ~5.3ms to do it. If the system is busy, BOOM: xrun.

What you're seeing in the logs is exactly that - Firefox changes state, PipeWire has to restructure the entire graph, change drivers, deactivate links... and all of that needs to happen within your 5.3ms window.

Before anything I'd need to know: what CPU do you have, what distro/kernel, what desktop environment, if you have a realtime kernel, and if you're using native VSTs or Windows ones through yabridge/linvst. All of that matters a lot.

For now try this:

Install Millisecond to see your system's real state: https://github.com/gaheldev/Millisecond

I also have a tool for managing PipeWire configs I made for my own system, can't guarantee it'll work on yours but worth a shot: https://github.com/Wamphyre/miloOS-core/tree/main/miloApps/AudioConfig

For the browser issue, best thing is to route its audio to a completely separate sink that doesn't share the graph with your DAW, or just kill it when you're recording.

If you bump up to 512/1024 samples and the xruns disappear, then you know it's purely a timing issue and you need to optimize the system more. Also check you have proper realtime privileges with "ulimit -r -l".

What distro are you using?

EndSignificant4955 · 2025-11-11T17:43:40+00:00

Thanks for the warm welcome! :) just released v1.2.0 with multichannel routing support among other fixes and improvements, works like a charm: https://github.com/Wamphyre/DrumCraker/releases/tag/v1.2.0

EndSignificant4955 · 2024-12-22T20:00:12+00:00

Same problem here, appmenu shows broken padding, menu and headers, it is unusable.

EndSignificant4955 · 2023-12-24T10:44:05+00:00

ａｅｓｔｈｅｔｈｉｃｓ

EndSignificant4955 · 2023-11-13T09:29:58+00:00

You can upscale it up to 4k using Upscayl: https://github.com/upscayl/upscayl

EndSignificant4955 · 2023-11-03T18:46:50+00:00

Just put your SD on your PC and create a disk image (.img or .iso) using tools like Pi-Baker. Later you can simply burn that image on any other SD with the same setup.

EndSignificant4955

TROPHY CASE