My new UI architecture post-Polyend milestone:

1. ttt --backend software: MiniFB + software
2 ttt --backend vulkan: Vulkan (Vk*) + GLSL
3. Input arrives always through MiniFB shenanigans.

MiniFB enables e.g., MS-DOS :-)

https://github.com/emoon/minifb

And hopefullly I get list for this for linux.dev, as I prefer my Git and comms like that... I could e.g. host this at infradead if David has retained my account (haven't logged in for some time) :-)

Powered by C ;-) And some SIMD for AVX2 and NEON (which is due to increase still quite modest use). Display context management is due to change from OpenGL to Vulkan. Uses kernel style both in code and the way we design objects in kernel. What works for tens of milions of lines of code will likely for this too.

If (or when) some assembly snippets, Intel syntax without question. I learned x86 assembly with Turbo Assembler, and have hated AT&T syntax since I first learned about GCC :-)

Import parity reached with Polyend files :-) And playback. Next time to create own format, and set of effect commands, which are 16-bit and chord and arp are not weirdly bounded but instead separate. chords tail bits can be used for custom scales. And make UI work best on laptop. And yeah looking good I have now a C based layout manager, UI framework, audio/DSP framework and the tracker itself :-)

Each tracks are already internally equal but each of the 16 tracks will receive in addition 3-band mixer and couple of inserts i.e. copying my favorite mobile DAW Caustic: https://archive.org/details/caustic3an

Yeah and as per synthesis curvature to envelopes, which like major headache in Polyend...

There's four synths in total:

1. Sampler with granular, slicing and rea-time timestrech (https://bungee.parabolaresearch.com/).
2. Wavetable with two oscillators, FM and overall all the shitty edm vomit :-)
3. Analog with 303 and Moog emulation, and less pecial SV12 and SV24 sub bass not so interesting analog emulations (but more useful as tools).
4. Drum hit synthetizer with 808, 909, 707 emulations and kick synthetizer.

This project started by accident during Fall when I was thinking that it would be nice to do a tracker but I will never get pattern editor done because it is suprsingly complex thing. I ended up doing that in 1-2 months without thinking much about it and without sound. Once I had that other stuff has formed "organically" :-)

I.e. this is a baseline. I will likely release this with GPLv3 license "within a year" but I have no rush because this is just sidekick activity...

@pinkforest and my opinions about languages are by definition silly and more like bad hair day type of thing than any serious opinions :-) I have to use Rust ATM a lot at work so I guess it is way to distance from that.

@pinkforest, cannot disagree with you ... unfortunately. It is also way to distance myself from trend, if nothing else I see psychological benefits.

I mean over-use of energy for AI will end. Again, unfortunately, it will more likely end into global natural disaster than anything else :-) Just when we were getting rid of fossil fuels, humankind invented new oil...

Also, all these crates make you do really lousy code.

E.g., in my Tracker I just used ab_glyph dynamically to load TTF font and convert it to texture atlas. While doing C rewrite made me realize that I should probably instead use Python and Pillow to create atlas during the build time. Quite obvious but abstractions can blindfold you.

I would take any day death and destruction by Skynet vs friendly and ignorant dictatorship by Gemini :-)

Doing audio in C is partly related to the IP protection, as with Rust it is hard to use LGPL in practice for libraries given static linking model.

There is cdynlib but is also ecosystem/culture question. I.e. stuff that I don't want to sacrifice for AI, I don't do with Rust :-)

Synth Engine #1, aka ACD, has SV12 and SV24 filters and then this mysterious RD3 filter.

I'm going to interpret the filter setting by having two synth engines internally:

1. SV12/SV24: use SH-ACD engine.
2. RD3: use TB-ACD engine.

SH-ACD is something like SH-101'esque and along the lines of hardware's timbre.

TB-ACD is my 303 emulator :-)

That way I get most (in the sense timbre palette) of that setting and can glue in my 303...

Doom scrolling "303" from KVR audio aka I think I do also synth engines and max the import capability. And for basic Polyend playback there's three already :-)

It's the moment in my life when you have to make my own 303 🤷

I wrote a little compositor to manage layout in my tracker with glScissors and textured rectangles :-)

@penguin42 This is true and better debugging skills would probably enable me to locate the failing crate :-)

@penguin42 And could be also my limited Rust debugging skills compared to C but yeah it is my leisure time project, so I use C, which I enjoy the most :-)

Maybe I suck :-) I don't know.

Memory safety is somewhat relative. My very early C version of the tracker has segfaulted maybe 1-2 times. Rust had much more memory instability.

Why C version is more stable:

1. If there is a segafault in a C program, for user space program, the full disclosure of the bug takes me like less than 20 minutes, with or without symbols. The binary is simple and as per code generated C is the most WYSIWYG language ever.
2. I can go absolutely sick in QA torture of the executable. There's so many ways you can bomb a C binary and trace everything in eBPF detail if you want, you can symbolic execute it with clang-tidy, Valgrind it etc.

I.e. while there are no federated laws the net result is still favorable for C at least in this project. I'm glad I started this rewrite :-)

Updated my bio with a new skill or role :-) Now that I've grabbed how to hack real-time audio, after this tracker project is somewhere, I might want to help with "saving caustic" project because Caustic is my favorite mobile DAW...

It will take long time to publish first videos of the C rewrite of the tracker and the reason is quite weird: text rendering.

It looks still quite crappy although it is gradually improving. In Rust I use ab_glyph crate :-)

It's good because that keeps me doing stuff instead of publishing stupid videos so neither really consuming much energy on it yet :-)

Right now my C-version of the tracker is using SDL3 but now I'm sure MiniFB is the right call for this software:

1. Game engine alike in-app UI framework.
2. MiniFB supports even MS-DOS thus serving best for my downscaling needs and makes most value of the C rewrite :-)
3. For a DAW you cannot use e.g. SDL_Audio anyhow. I have my own audio stack using RT scheduling and memlock and directly using Pipewire.
4. It's import ready library in its simplicity i.e. one dependency less for me.

In Rust PoC I moved to SDL3 from minifb-rust but in the current situation the switch is quite obvious. I'll do it when I migrate on using Vulkan for setting up GLSL contexts :-)

MiniFB is amazing little piece of code: https://github.com/emoon/minifb

We are fully embracing vibe coding and I love it