My strategy to AI theft is to move the release of the source code as far away in time as possible. E.g, this is the approach for my DAW. I'll do the whole thing privately until it is just great enough to get the grip. This builds the community at fast rates, which also mitigates ther risk, and provides governance. It will be GPLv3 but as a in-dev project I'm more vulnerable.

some time ago i (half) joked that the only job #llm can replace outright is the CEO.

today i attended an earnings call where a synthetised voice of our CEO read multi-page long table of numbers from an official financial document, according to a script prepared by claude, over a single slide titled "company earnings 2025" - to a room full of employees who commuted to the office to watch it in person. there was no management present or even shown on the screen.

it was the most disturbed dystopian fucking thing i've experienced in my career of working for soul-crushing corporations.

The cat is out of the box: @matrix is looking for a new Thib!

If you think you can be a good fit for the role, please send me an email explaining why and attach your CV.

If you tick most of the boxes but not all, please reach out nonetheless. It’s a tall order, but we have fantastic volunteers and a great handbook to help you settle into the role.

https://matrix.org/jobs/devrel/

#FediHire #DevRel

4️⃣ Here's the 4th post highlighting key new features of the upcoming v260 release of systemd. #systemd260 #systemd

When running code from OS trees, for example in containers, or when booting a full OS in a VM or on bare-metal it's often very useful to put together the basic OS from multiple overlayfs-style layers (directory-backed or backed by DDIs), plus some additional bind mounts, and possibly a tmpfs or two mounted to the right places to get ephemeral or partially ephemeral behaviour.

This my main UI reference or something I will taken now a lot of inspiration from at least because Octamed is superb and nice to use. And stands time just like Vim :-)

1. Octamed was made by a Finn Teijo Kinnunen.
2. Had major share on invention of such electronic music genres at their epoch such as breakbeat, jungle and drum'n'bass.
3. Still widely used as it does the job and has predictability unreachable on a signal chain with adaptive latency prevention algorithms, and especially with hardware samplers and such this makes ones life better.
4. I like it too a lot, it's great for what it does :-)

That is next 6 months at least because I want my tracker to level that I can do a full track with no other tools, and it is surprising how bottomless pit different usage patterns are (and not necessarily bugs, something just works or doesn't). And now that I actually have really good design and implementation for the engine it makes me less eager to less, it's fun to try things out :---)

#octamed #amiga

TTT is my first appy app ever. Never done any so far. I hope this does not happen too often :-) I waited for years someone to make not exactly "chiptune tracker" but neither "renoise". Never happened so there was no choices, and also Caustic died. In the age of all this web vomit (frameworks? i don't know what they are) ,and generally complicated software configurations, you can still do cool stuff with plain C and some assembly magic... It's great.

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 🤷