I'm getting back into playing guitar, but I want to skip on constantly changing tunings and strings for them, also I would like some octaver effect or something like that.

Display of OpenGL context works fine on Windows, no issues with resizing. Function glViewport works as intended.

It only has issues with X11 on Linux (no plans yet to implement Wayland due to lack of free time). Resizing breaks everything, and it doesn't really work the way you expect (point of triangle moves down if you make it taller, etc). I cannot find anything on if I should call anything else besides glViewport, only that "you should use [insert already existing library], which will take care of this behavior". Others are suggesting me that it's an issue with my distro, but I cannot find any OpenGL testcase that is small enough to test on my VM or my Raspberry Pi to actually test whether that's the case.

When resizing an X11 window with OpenGL content, the image becomes garbled and certain parts of the window, usually at the parts that wasn't originally part of the initial framebuffer.

I couldn't find any documentation on if I supposed to call some extra functions when the window is being resized or not. I otherwise process that even as a system event, so it can be further processed by the program using my API.

I started to use Linux Mint on my VM, however it seems like it uses a different channel for packages, which means I get some outdated packages such as D compilers, which makes me unable to compile my programs.

While the D compilers have some userspace installer scripts, they're userspace only, meaning they need initialization scripts, which only work until the end of the given shell instance, which makes it particularly hard to use in certain contexts.

Is there some "untested" or similar branch to get some newer stuff? The compilers don't seem to interfere with anything system level, so it should be fine.

So far, Ubuntu 24.04 was an absolute nightmare for me. While upgrading to it in a VM, it randomly crashed, which broke the GUI. I had to go to the tty, and finish the upgrade that way to get back into GNOME. Then every time I launched its default file manager or its screen settings app (which became mandatory as it just randomly switched to 1280x800, thus making work a nightmare), it crashed so hard it took the VM host with itself.

Switching to VMWare, it was more stable, stable, but after the first restart, I get a lot of graphical glitches and a black background. Tried Kubuntu to see if it's a GNOME-related thing, but similar issues prevail, this time with a tanked performance until I switch to tty.

I need an easy-to-use and relatively stable distro, for compiling, testing, and rewriting software with GUI, thus I cannot use WSL on Windows 10. I want to spend my time developing, and not resolving bugs, nor with tinkering with the OS. Likely I will have to keep my primary development platform as Windows, and Linux does not offer me anything more, and "deploying/cross compiling to Windows" is not very feasible to me at the moment due to I'm writing my own middleware to interface with OS API, and I also want to test on native Windows rather than in an emulator. Windows 11 might push me in the direction to use a Windows installation inside a VM, but only if disabling telemetry becomes impossible.

Design documentation: https://github.com/ZILtoid1991/pixelperfectengine/blob/master/docs/formats/m2.md

It has some weird solutions due to my limited experience with the subject and the target usage favor preallocation instead of live allocation. I took some inspirations from Music Macro Language, Assembly, and Lua. Due to the lack of a MIDI 2.0 format, I thought I'd come up with my own, adding capabilities to program adaptive soundtracks (emitting MIDI commands with calculated values, conditional emitting of MIDI commands, conditional looping and pattern playback, etc).

I initially gave it the name .m2 but while M.2 is an entirely different thing, an MML format by the name .m2 does exist on the PC98, thus I'm looking for some new name for mine. The only thing I can come up on the spot is MASM (or MIDI Assembly), but it's close to an already existing MASM (Microsoft Macro Assembler).

After a crash during an update (which I managed to recover from), the default file manager Nautilus no longer works, and crashes so hard it crashes VirtualBox too.

I tried by deleting it then reinstalling it, but didn't change this behavior. Also there's a non-zero possibility that the original crash was caused by Nautilus itself.

d package int poll_win_RawInput(ref InputEvent output) nothrow @nogc { MSG msg; BOOL bret = PeekMessageW(&msg, null, 0, 0, PM_REMOVE); if (bret) { ////Some code that supposed to swallow WM_SYSKEY and the likes, but does not work as intended//// DispatchMessageW(&msg);//In the aforementioned block ////Function that optionally gets text input messages//// switch (msg.message & 0xFF_FF) { ////Regular user input handling via RawInput and some legacy stuff + XInput handling in separate function//// Since it's for games, the default Alt key behavior is undesirable for me. It makes my test application hang and make error noises since it doesn't have a menubar. I checked whether my window had a flag that enabled the menubar or not, but couldn't find it.

Thanks to the current SEO nightmare, I can no longer use search engines the same reliability as before. Stackoverflow is too toxic and often all I need is to properly look up some more obscure stuff about some API, which "could just be googled". AI, of course, is very unreliable.

Searching code on Github, then adjusting it in many ways to my needs (like to a different language, renaming variables to make more sense, additional optimizations, etc.) seems way more feasible nowadays. However, while there's a lot of code with very permitting licenses (including public domain licenses), others are not so much, and I don't want to argue against them, often I'm even understanding the reasons behind their decisions. I even try to give credit wherever I can, or look up the original source of an algorithm I find being referenced by someone else.

After getting angry at Lua for bugs reappearing after fixing them, and otherwise having issues with making it interoperable with my own language of choice (D), I decided to roll out my own VM out, with some enhanced optional features compared to regular Lua (type safety, static arrays on the stack, enhanced metatables, etc.), and also allowing the potential of other scripting languages to be ported to the VM. As I already have crafted a VM for a programmable MIDI format (M2: Docs / Implementation ; bit incomplete as of now), I thought it'll be easy, just don't optimize this time entirely around preallocation (M2 has 128 not entirely general purpose registers per pattern (musical thread) + 128 shared registers + shared arrays), add stack handling, add heap handling, add more types, etc.

Thus I begun working on PingusVM, to contribute to the problem of ever growing number of standards.

However, as time went by, I had to realize (just like every time I've added another engine feature) that it's way more complicated, especially as I have realized mid-development that I had a lot of oversight on design. Not only that, I have a lot of other projects, such as the game engine I've originally intended the VM for. My main issue is, potential candidates either lack integer support, or are very bloated (I don't need a second XML DOM parser, etc). Lua kind of worked, but after I fixed an issue (which was hard as every tutorial implied you just wanted to load a file directly instead of having the ability of loading the text directly) a very similar one reappeared, while following every tutorial possible. Others would lead me to introduce some C-style build system, as they would need "hard linking" to my engine, and that "hard linking" is why I had to halt development of my image library, as I would have needed to introduce a build system into my project for the LZW codec (required for GIF files).

Art by me, after a typo by my friend.

... but it was neither as massive nor important as AI techbros claim.

It's biggest haters were (and still are) fine art elitists. You know, those grumpy men, that will scream at you for using watercolors instead of oil paints, or claiming anything not fine art (e.g. anime, comics) is not art at all. Collectors hate(d) digital, as you cannot trade JPEGs and PSDs for good money, nor early digital artists had the name recognition to inflate said prices if they could do as such.

The other part was it's mere inaccessibility due to expensive equipment and software. Back then, you only really had Photoshop (or Paint Shop Pro if you were adventurous, or Manga Studio if you knew about it and wasn't scared away by its name), which still lack support for things like rulers, so you had to use its vector graphics capabilities to get around them. This was combined with PCs that couldn't physically handle more than 4GB of RAM even if they tried, all with dual core at a long time only being an option on specialty workstation/server motherboards with 2 CPUs. This was also all before better pen tablet options. First you either had a Wacom with a screen, a Wacom without a screen, or some rebranded horror made by KYE (Genius, Trust, etc.), all while the Wacom tablets monopolized battery-free tech through patents and KYE had to rely on AAA batteries. Once we had XP-Pen and Huion with batteries (often AAAA, that are hard to obtain), we finally had some more options, but those were less available in computer shops. But once the Wacom patents expired, the lower-end tablet market become blossoming, then Manga Studio rebranded as Clip Studio Paint, and also Krita became mature enough for general use (both of which have proper on-screen ruler support). Nowadays those alternative manufacturers have even eating into the more professional market of Wacom, all while KYE have mostly disappeared from that market save for remaining stocks.

Alt text: Using AI is the coolest new way to let people know you have no imagination of your own