I'm just about to release LGPL 2.1+ DSO but not sure should I put threats of legal action to README + some passive aggressive grin :D

And like even with Claude, I'm not going to blame the tech, could be useful for doing ports for simple projects that you (A) fully own rights to do that and (B) have ability to fully cross-examine the result. In order to act against bad actors I feel that balanced thinking of benefits and disadvantages and take legal action when require is way to go.

@pinkforest Given how "plain sight" that was perhaps LLM also told about clean room engineering. At least in my experience e.g., Gemini often describes and teaches stuff that is completely false it's like a thing with Google's AI how fucked up it is in its teachings :-) Very useful still for cross-checking specs etc. in "right hands" (apparently) :-)

@pinkforest ok, so i did put just in case https://github.com/chardet/chardet/issues/328.

Fucking scum tbh.

@Foxboron Like this https://github.com/chardet/chardet/issues/328

@Foxboron https://social.kernel.org/notice/B3vwLO7kTOKLjpxCee

@pinkforest i don't know the situation. if you have full copyright of all code you can relicense of course. Does not appear like that but dunno the context. I would contact legal entity e.g., https://www.fsf.org/licensing/team or legal@fsf.org.

I would also recommend to post issue to this MIT rewrite project to stamp this. Anyone can do this. Make it visibile.

E.g. my tracker project is good example of legit interop, which would stand any trial and even protected by e.g., EU laws so there's no need to. I'm not lawyer but for me that looks somewhat shady. These need to be really just brought more to the court. It's a new trend.

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

And hopefullly I get list for this for linux.dev, as I prefer my Git and comms like that... I could e.g. host this at infradead if David has retained my account (haven't logged in for some time) :-)

Powered by C ;-) And some SIMD for AVX2 and NEON (which is due to increase still quite modest use). Display context management is due to change from OpenGL to Vulkan. Uses kernel style both in code and the way we design objects in kernel. What works for tens of milions of lines of code will likely for this too.

If (or when) some assembly snippets, Intel syntax without question. I learned x86 assembly with Turbo Assembler, and have hated AT&T syntax since I first learned about GCC :-)

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

@pinkforest and my opinions about languages are by definition silly and more like bad hair day type of thing than any serious opinions :-) I have to use Rust ATM a lot at work so I guess it is way to distance from that.

@pinkforest, cannot disagree with you ... unfortunately. It is also way to distance myself from trend, if nothing else I see psychological benefits.

I mean over-use of energy for AI will end. Again, unfortunately, it will more likely end into global natural disaster than anything else :-) Just when we were getting rid of fossil fuels, humankind invented new oil...

Also, all these crates make you do really lousy code.

E.g., in my Tracker I just used ab_glyph dynamically to load TTF font and convert it to texture atlas. While doing C rewrite made me realize that I should probably instead use Python and Pillow to create atlas during the build time. Quite obvious but abstractions can blindfold you.

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