Posts
5299
Following
345
Followers
528
Linux kernel hacker and maintainer, virtual instrument creator etc.

OpenPGP: 3AB05486C7752FE1

Jarkko Sakkinen

I wrote a little compositor to manage layout in my tracker with glScissors and textured rectangles :-)
0
0
0
@penguin42 This is true and better debugging skills would probably enable me to locate the failing crate :-)
0
0
0
@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 :-)
0
0
0
Maybe I suck :-) I don't know.
2
0
0

Jarkko Sakkinen

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

Jarkko Sakkinen

Edited 7 hours ago
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...
0
0
1

Jarkko Sakkinen

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

Jarkko Sakkinen

Edited 10 hours ago
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
0
0
0

vitaut 🀍❀️🀍 πŸ‡ΊπŸ‡¦

We are fully embracing vibe coding and I love it

0
2
0
For x86 I actually (after investigating) solely base on AVX2. There's no legacy history in this software so I don't care about legacy SIMDs (or want to implement them at least myself).
0
0
0
To get more texel throughput from Pentium, the next trick is to preprocess texture bitmap in 8x8 pixel tiles. That will significantly reduce cache misses :-)
1
0
0

Jarkko Sakkinen

Edited 14 hours ago
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.
1
0
0

Jarkko Sakkinen

Edited 15 hours ago
OK, so when they say "64-bit professional internal audio processing", in English it means almost just s/float/double/g 🀷
0
0
0

Jarkko Sakkinen

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

Jarkko Sakkinen

Edited yesterday
Project reset/migration to C code base started over weekend when my friend asked could we do (G3/G4) PowerPC port of the engine. I don't know but I don't want to create bottleneck preventing such work :-)

Being aware of such potential bottleneck I had no other options really.
0
0
0

Jarkko Sakkinen

Edited yesterday
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.
1
0
0

Jarkko Sakkinen

Edited 2 days ago
@neal, If you know anyone who might be interested on this, please forward.
0
0
0
@pinkforest that's it. i will call my daw as turbotape. Thanks, now I have name for the app :-)
0
0
1
@pinkforest I lived also through the era of turbotapes :-)
1
0
1
Show older