Jarkko Sakkinen
Posts
5299Following
345Followers
528OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
I wrote a little compositor to manage layout in my tracker with glScissors and textured rectangles :-)
0
0
0
Jarkko Sakkinen
jarkko
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 :-)
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
jarkko
Edited 8 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
jarkko
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 :-)
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
jarkko
Edited 11 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
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
Jarkko Sakkinen
repeated
repeated
Jarkko Sakkinen
jarkko
Edited 15 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.
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
jarkko
Edited 16 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
jarkko
new episode, love this series :-) https://www.youtube.com/watch?v=k6ROHHcF2rU
0
0
0
Jarkko Sakkinen
jarkko
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.
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
jarkko
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
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
1
0
0
Jarkko Sakkinen
jarkko
Mastodon gives those old school BBS dial-up vibrations when the images load in your feed from time to time ;-)
0
1
1
Jarkko Sakkinen
jarkko
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.
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.
1
0
0
Jarkko Sakkinen
jarkko
Edited 2 days ago
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.
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.
0
0
0
Jarkko Sakkinen
jarkko
My unnamed tracker has capability to play and import Polyend and Protracker projects and audio and DSP to realize that the fullest but in addition...
1. It will load/save its own format.
2. Decent modern real-time timestrech.
3. Arbitrary length samples mono/stereo.
4. Polyend song themselves even with old features just sound much better given high-fidelity signal, oversampling, across the board better and less aliased DSP and some magic dust :-)
5. From eight to 16 channels.
6. Curvature of envelopes (I don't get why they didn't just do this, it is very weird).
7. 1010music Blackbox'ish hardware synth auto-multisampling.
8. All 16 channels are equal. I.e. no weird 8/8 divisions. All do samples and MIDI instruments.
That's about it for 1.0 DoD :-) I retain my right to reconsider licensing up until I release anything but most likely GPLv3.
I'll support Pipewire on Linux and CoreAudio on macOS and obviously Windows and WASAPI and ASIO support are welcome as contributions.
#tracker #polyend #chiptune #pipewire #linux
1. It will load/save its own format.
2. Decent modern real-time timestrech.
3. Arbitrary length samples mono/stereo.
4. Polyend song themselves even with old features just sound much better given high-fidelity signal, oversampling, across the board better and less aliased DSP and some magic dust :-)
5. From eight to 16 channels.
6. Curvature of envelopes (I don't get why they didn't just do this, it is very weird).
7. 1010music Blackbox'ish hardware synth auto-multisampling.
8. All 16 channels are equal. I.e. no weird 8/8 divisions. All do samples and MIDI instruments.
That's about it for 1.0 DoD :-) I retain my right to reconsider licensing up until I release anything but most likely GPLv3.
I'll support Pipewire on Linux and CoreAudio on macOS and obviously Windows and WASAPI and ASIO support are welcome as contributions.
#tracker #polyend #chiptune #pipewire #linux
1
1
3
Jarkko Sakkinen
jarkko
I will support first generation Polyend projects as an import format just like Protracker modules but my tracker will have its own project format and own unique features, which makes sense to me :-)
0
0
0
Jarkko Sakkinen
jarkko
The indie DAW/tracker is based now on emoon's awesome https://github.com/emoon/rust_minifb + GPU only i.e., it is now internally a game engine type of pipeline with graphics and multichannel audio :-) Active screen is rendered to a texture with a single shader pass, and then main screen is rendered with a 2nd pass with the screen texture at the center. A tiny CPU cost (or a wait state, depend how GPU is wired to CPU) might come from feeding state data for a shader program for the update.
Fixed track limits (vs. unlimited tracks in DAW's) also have advantages. One is ultra low and low variance audio latency that is "same same" anywhere and at any time. It's both because pipeline is optimized to carry the weight and also because plugins cause indeterministic latency peaks that need to be compensated by the DAW.
It's a crazy hobby...
Fixed track limits (vs. unlimited tracks in DAW's) also have advantages. One is ultra low and low variance audio latency that is "same same" anywhere and at any time. It's both because pipeline is optimized to carry the weight and also because plugins cause indeterministic latency peaks that need to be compensated by the DAW.
It's a crazy hobby...
1
0
1
Jarkko Sakkinen
repeated
repeated
Linux Security Summit 🐧
LinuxSecSummit
Reminder: the CfP for LSS-NA is open until March 15th.
RE: https://social.kernel.org/objects/b4dcda9a-582c-4803-9d6a-30e42dfc8538
RE: https://social.kernel.org/objects/b4dcda9a-582c-4803-9d6a-30e42dfc8538
1
3
1
Jarkko Sakkinen
jarkko
Edited 4 days ago
Old school file browsing experience :-) Rendered as a single GLSL shader program (except top and bottom bar). There's now 1:1 correspondence between shader programs and screens. Most importantly this stabilizes latency for each tick in audio playback (smaller CPU time variance).
#tracker #polyend #chiptune
#tracker #polyend #chiptune
0
1
0
Jarkko Sakkinen
jarkko
Edited 4 days ago
Yep, I started a C rewrite of my tracker so first version was a PoC.
I.e. want to spare time from clocks even from compiler injected memory checks. I.e. I drop Rust because of memory safety tbh. And also have really good touch what opcodes get generated.
This came up when my friend asked could this in theory to G3/G4 PPC that was basically it :-) I can do so much more now to make it compact, nice and fast.
🤷
I.e. want to spare time from clocks even from compiler injected memory checks. I.e. I drop Rust because of memory safety tbh. And also have really good touch what opcodes get generated.
This came up when my friend asked could this in theory to G3/G4 PPC that was basically it :-) I can do so much more now to make it compact, nice and fast.
🤷
0
0
0