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

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

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

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

Doing my first peaces of SIMD to the audio pipeline :-) Both SSE and NEON.

Last time I did anything resembling this was when using FPU to divide 1/w while ALU is linearly interpolating the texture (on Pentium which has also nice and fast ALU pipeline, a leap over 486). This used to be common approach for software rendered perspective corrected texture mapping.

OK, so when they say "64-bit professional internal audio processing", in English it means almost just s/float/double/g 🤷

new episode, love this series :-) https://www.youtube.com/watch?v=k6ROHHcF2rU

Tracker will take some time and especially since I'm doing C rewrite, which is right now completely broken (literally a start from scratch).

However, the elegant C implementation will motivate me more as a developer as I enjoy it more, and thus will eventually get the project there.

With Rust implementation I know I would give up at some point. E.g., in this type of project you want to leave space for downscaling to very low-end computers, and more towards 80s/90s hardware we go, more opcodes cost relative to memory access costs. Thus I don't want compiler to do any memory safety stuff for instance. Software must have full control of generated opcodes.

The code base looks in style a lot like kernel code and utilizes its popular patterns such as ops structs and container_of macros. And coding style is of course kernel coding style.

Initial draft for rootns documentation:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/tree/Documentation/userspace-api/rootns.rst?h=rootns

WiP

#linux #kernel #documentation

Mastodon gives those old school BBS dial-up vibrations when the images load in your feed from time to time ;-)

One thing where would be a slot to try JIT in a tracker: a DJ software playing the songs. It will gain from faster reaction time from the engine and data does not need to be editable.

Not having plugins is here essential because then you don't even theoretically have an opcode mapping. Also, not having pre-defined limit for channels is bad. But I have 16-channel sequencer.

With this world having constraints I think you make compiled versions of songs. Not sure if I'm going to do it but technical constraints enable it to be done.

One big realization in tracker project has been at I like raw GLSL or at least it has now helped me a lot.

Before I spent lot of time with widgets and thinking about one screen. Once I wrote rendering scheme where one screen is a GLSL program driven parametrized from the state I just think the global state and nasty widget code is not all around.

GLSL is also nice because of multitude of viewers and decoupled from implementation language. I don't get why I would want to wrap shader generation to e.g. programming language macros.

This helps me now a lot that I'm rewriting the tracker in C too. It is easier to map things to global state to global state than various screen specific substates.