And various tools processing Polyend projects can easily adapt and recognize these project files and address the differences.

Powered by C ;-)

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

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

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

Instruments parameters refurbished :-)

The shader program for screen covers always the parametrized state space of the screen view and it is rendered to a texture for the canvas, which has the surrounding shenanigans.

And also with a known number of tracks one can go crazy with SIMD optimizations in whole different level than N tracks...

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

@LinuxSecSummit I'm a bit worried about US travel but I'll likely still submit and consider (personal safety).

@LinuxSecSummit thanks for the remainder!

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

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

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

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

@timojyrinki thanks! would be anyhow good to learn the debian process, appreciate this, thank you!

I wonder if I should get this packaged: https://codeberg.org/jarkko/lsiommu

In addition of /sys traversal it discovers through libudev. I should probably make this dynamic option and change CONFIG_DISCOVERY to CONFIG_UDEV (i.e. /sys or /sys + udev).

It did not exist in easy single executable form so I did this already long time ago.

You can filter out the info also with lspci but it is tedious/unergonomic :-)

@timojyrinki, How do I do first babysteps to package this for Debian?

I once made a chatbot with it mixing some basic algorithms to derive text randomly and put it to bunch of random Telegram channels. It was not great idea :D It really caused some havoc. So up for next project :D

Just for plain interest how to make ollama running in NVIDIA GPU useful for something? Not for being LLM prompt. Just ideas what would be applications :-) Like, could I make it analyze local network traffic for instance or be part of that type of scheme?

@jani, I guess I did not learn anything from previous round ;-)

I'll create a rootns AUR repository for Arch Linux kernel with rootns patches. I want to run it in my desktop for some time to get more feel for it and fix any glitches.

I think it is pretty good but for a namespace it is better to try to use it for a while before submitting anything.

The idea of rootns is to namespace root / superblock i.e., that way this dilates from David Howell's original series (or by evolution actually following all review comments from Al and Eric). In David's series topologically container object was something managed by task_struct. In this series, rootns is part of nsproxy, and purely a namespace.

You would think that root is part of filesystem namsepace but actually formally filesystem namespace is all non-empty sets of mount trees not including empty state (there's BUG_ON() to underline this in VFS code). This namespace plays only with detached roots and that way can give guarantees of not mixing up the kernel state.

Once again (as with swcam driver), I ripped off the SRCU/spinlock locking scheme from SGX driver and there are no loops inside spinlock or anything weird like that. I should remember to add cond_resched()'s tho to iterations :-)

I think the gist of David's code had absolutely a reason to exist. It was just not enough constrained, scoped and explained. And it was completely misunderstood by most. I have to give credit to Eric Biedermann giving such great (and many) review comments despite being in existential opposition. This is uncommon and shows high-standards professionalism in a person.

Super useful tidbit on serum wavetables (44 kHz vs 48 khz): https://backstage.polyend.com/t/workflow-making-wavetables-on-tracker/4742