Posts
5284
Following
343
Followers
527
Linux kernel hacker and maintainer etc.

OpenPGP: 3AB05486C7752FE1

Jarkko Sakkinen

Edited 3 hours 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

Jarkko Sakkinen

Mastodon gives those old school BBS dial-up vibrations when the images load in your feed from time to time ;-)
1
1
1
Or not JIT but "compiled song"
0
0
0

Jarkko Sakkinen

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

Jarkko Sakkinen

Edited 13 hours 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.
0
0
0
And various tools processing Polyend projects can easily adapt and recognize these project files and address the differences.
0
0
0
Powered by C ;-)
0
0
1

Jarkko Sakkinen

Edited yesterday
I do not need fixed purpose softsynths. At some point they need to be improved and that might be backwards incompatible, so you need a stupid checkbox to switch "compatibility mode" (lots of plugins do this). Or you can keep it as it is i.e., not being useful for anything.

Instead it is just better to provide higher quality algorithms for sample, wavetable and granular oscillators, and make that unified synth better with sound :-)

And this will never ever have plugins. But it will continuously sound better :-)
1
0
0

Jarkko Sakkinen

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
1
3

Jarkko Sakkinen

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
And also with a known number of tracks one can go crazy with SIMD optimizations in whole different level than N tracks...
0
0
0

Jarkko Sakkinen

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...
1
0
1
@LinuxSecSummit I'm a bit worried about US travel but I'll likely still submit and consider (personal safety).
0
0
0
@LinuxSecSummit thanks for the remainder!
1
0
0

Linux Security Summit 🐧

Reminder: the CfP for LSS-NA is open until March 15th.

RE: https://social.kernel.org/objects/b4dcda9a-582c-4803-9d6a-30e42dfc8538
1
3
1

Jarkko Sakkinen

Edited 2 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
0
1
0

Jarkko Sakkinen

Edited 2 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.
🤷
0
0
0
Show older