Projects Update - June 2026 Edition

While I've been relatively quiet here on my blog the past few weeks, "project wise", that couldn't be further from the truth!

 

1) Introducing "Spectrochrome" - The biggest news of course that I've finally made a great deal of progress on my MusicViz project again, for the first time in ages.  I plan to share more details about this in a dedicated post in a due course when I complete the last few major chunks of work on it, but before then, here's a brief sneak peak of what's been brewing:

 

Live link to the latest stable version:

 https://aligorith.github.io/musicviz_playpen/spectrochrome.html

What you have here, is a web-based spectrogram tool (built as a single-page tool, that runs completely in your browser on your own machine, using HTML5 technologies), that analyses any audio clip you throw at it (*1), renders each frequency / pitch with a unique colour (i.e. based on the colour scale I covered in the first edition of this series) using a "showcqt" like visualisation, and tries to figure out what the "dominant" pitch at any point is (so that we can then use that in future to drive the "next-step-up" visualisation that will try to do something with the main melodic line detected...

Other stuff it supports (but not really shown in that screenshot) includes:

 * Being able to playback and scrub the audio

 * Being able to render out a video of the spectrogram being progressively drawn as the audio plays

 * A bunch of interactive  adjustment + tweaking tools (i.e. these are some of the active areas of development currently under way)

 

 (*1)    Disclaimer:  It works best for short clips (about 1 - 1.5 minutes in length) - which are the typical ones it is designed to handle (i.e. that's the length of almost all the music I write + record, which is why I need this tool). I can however be used on standard pop-song like songs too (though the processing runs a bit longer, and the longer timeline means that fine details get horizontally compacted / compressed, making any melodic line features less legible.

Linux Annoyances Rant - Solutions for Rough UX Sought

This post covers 3 main annoyances I'm currently working on solving across various Linux machines I have to use. I'm mainly only talking about the issues that I haven't got solved on other machines I used...

 

1) Taskbars - Fully un-grouped windows, absolutely not ordered or grouped by window, and able to be freely reordered.

NOTE: I have long had this problem solved on Windows (i.e. using 7+ Taskbar Tweaker), and also on KDE (yay!  Those guys rock!), but on the RH 9 type Gnome-based Linux we're in the process of migrating to?  That's the one I'm currently seeking solutions!  Of course though, all of these could've been solved if everyone didn't do the stupid thing that they learned from Windows 7, OR perhaps they learned that from Apple first?!  Whatever...

2) Gnome Button Ordering

3) Kubuntu (Auto) Update Checks on Resume from Sleep

  

On Patterns and Chunks in Music

Sunday morning thoughts on music stuff (since this is the hour when I'd have violin lessons for over a decade)

Something I only really learned / realised in recent years, particularly after watching someone very skilled at sightreading demonstrate their skills [1], which maybe would've been better to know earlier:

Patterns, patterns, patterns.

While many of us of driven mad to the point of curling up in a crumpled mess a few bars in then barely holding on, what higher level performers do here is they are able to quickly deconstruct what they see into the building-block patterns the composer used.

What do I mean?

Scales + Arpeggios.

Ultimately, many composers are relatively "lazy" in that they will use runs of scales + arpeggios to "fill out space / make noise", acting as "connective tissue" between stretches of melody. This is especially true the more "showy" and "virtuostic" the piece is supposed to be...  [2]

This sort of ties into an interesting Ted talk from Benjamin Zander years ago where he talks about the progression of musical skill (i.e. The "one buttock playing" one - IYKYK). The central thesis here is that, what distinguishes beginners from more advanced players is the progression of skill away from trying to tackle things on a note by note basis (i.e. equivalent to kids learning to read having to spell out words letter by letter, stringing those together, then trying to make sense of them), they are instead looking more broadly at larger chunks, eventually focussing a phrase-level progressions.

Yes. These are pretty much the same same kind of fundamental insight as:

"What makes a piece of music memorable / easy for people to understand? Repetition. People need to hear ideas several times, and especially in different ways, for them to start picking up on them, and before recognising and/or even eventually liking them. It's not *boring* that something needs to be repeated several times - as long as you do it to establish a pattern that you then subvert to create some minor novelty / interest... That is just what needs to happen. To satisfy our stupid lizard brains."   [3]

Hopefully this helps unlock something for some music student out there sometime... 

MediaSlurper Updates - Launcher works on Linux now

Just a quick WIP teaser tonight:

Today I finally bit the bullet, and figured out all the necessary changes to get MediaSlurper running under Linux  (though to be fair, I'm only really testing this under Kubuntu currently, but may soon also test under Manjaro for good measure)!

MediaSlurper GUI running under Kubuntu, with the "Foreland" wallpaper from Manjaro

 

Reactions to Baldur Bjarnason's - "The Old World of Tech is Dying"

This morning, I read a fascinating essay from Baldur Bjarnason:

https://www.baldurbjarnason.com/2026/the-old-world-of-tech-is-dying/

A good few things resonated with me quite a bit, so I've pulled them out into a post here:

* 1)  On "Singular Revelatory Events" (aka "Silver Bullets That Fix / Change Everything")

* 2)  On what's rotten with the "Global Tech Industry"

Old Computer Hardware Revival Saga: Desktop 1 still crashes Kwin using a newer Live USB

Sigh...  this evening, I finally got to test a newer KDE Live USB on Desktop 1 (which had issues with Kubuntu 25.10)

Salient part of the initial coredump - Looks like it's in libgallium *again*...  (i.e. likely the same place as last time too), when doing a framebuffer blit in Kwin

 

Unfortunately, I am still getting crashes with this new version:
* Can now confirm it happens when trying to bring up any window

* Can also confirm that Kwin now pops up a very handy "Crash Handler" that can show the relevant coredump.

* The problem though, was that, after the first crash (from trying to open System Settings), the next dozen in quick succession (when trying to open the "Start" menu after waiting a few minutes) were happening so frequently, that I couldn't inspect if they were all crashing on the same thing.

Recent Linux Learnings + Experiments + Attempts to Upgrade Linux Laptop to Kubuntu 26.04 LTS

After several days of trials, I've been itching to deploy Kubuntu 26.04 LTS to my Linux laptop, as it has so far seemed pretty OK, but with a bunch of cool new things...

This update covers:

* 1) First impressions of the new LTS

* 2) A whole bunch of niggly tech things I've learned in the past 24 hours, either from general poking around and/or from trying to upgrade my test laptop 

Photo Organisation Scheme

Someone recently asked me how I currently structure my photo collection. 

 

The short answer - It's a mix of:

* "Structured" stuff for my "proper camera" stuff from 2010 onwards, 

* A similar system for camera photos too this past year and a bit, alongside / integrated

* Haphazard per-device collections for the rest

While I should try to improve this, I have also been burned before, having lost a good few months of stuff (suspected) from one old camera from a botched reorder that I then backed out from...

Windows Terminal Tip - New Tab Behaviour

Saving this here to save me another mad search again next time:

 

If using "Windows Terminal", to make the "New Tab" behaviour sane, go into each relevant profile, and change the "Starting Directory" setting to "./"  (i.e. current directory that the active tab is using)

 

Notes: 

* This makes the behaviour match watch every other OS does, and what you'd naturally expect, when trying to fork up another terminal tab to work on a sub-task from the same deeply nested folder

* The stupid default value here defaults to "%USERPROFILE%, which is akin to opening a new window from the start menu, located miles away from where the files you want to work on here and now live!

Linux Migration Experiments - First Attempt with Desktop 1, and Hardware Upgrade Roadmap Thoughts

Having previously tried with Desktop 2, and on the back of recent success with CodeQuest Laptop, I finally decided to try and brave testing Linux on Desktop 1 for the first time ever, to see how it would fare. 

After all, as soon as I am forced to take it off Windows 10 (if something sufficiently bad comes along that means that all old machines absolutely need to be taken off the internet immediately - and even then, I can buy some more time by just disconnecting its USB wifi dongle (more on that in a moment), then it'd be good to know that I can safely do this with that machine.

Of course, there's a LOT of water to pass under the bridge with this one first... As in - tons of hardware upgrades + tweaks first (which may be somewhat familiar from prior posts in this series). 

This update covers two things:

* 1) The immediate future hardware-upgrade needs of this system, which are still up in the air somewhat

* 2) Tonight's "failed" first experiment running it under Linux 

Hard Earned Lessons When Doing Backups on Windows Using Robocopy

This afternoon, I tried updating the set of secondary backup drives I'd previously spent Easter weekend painstakingly (and very frustratingly) spent waiting several *DAYS* to complete...

At the time, I'd ended up doing a bunch of reading, about what may have been going wrong (especially as it seemed awfully slow + hard to predict what was going on / when the copy jobs "may" complete). Well, turns out I needed to call on those lessons today, confirming that that does seem to have been the culprit  (i.e. it had only made progress over like 2-3 folders for the past month's data, when usually each time I'd copied those using Windows Explorer onto another drive, the process was usually way quicker!)

In Short:

It seems that that combination of "robocopy /mt" and "exFAT" drives in particular is slower than a frozen snail!🤬

So yeah, don't do what I did over Easter Weekend  (contributing to over half of my tech pain that weekend):

* 1) Do NOT use "robocopy /mt" when copying to an external HDD - Apparently, the "/mt" arg only really makes sense if you're copying between local drives, and really, only when one of those is a SSD even. (If it's over USB, or to anything other than NTFS... yeah, don't bother!)

* 2) Especially do NOT use "robocopy /mt" when copying to an "exFAT" formatted external hard drive

* 3) Probably do NOT use Window's Explorer's "Format Drive" right click menu to do so either!  (With my other external exFAT HDD drive, I had to get it to do a "scan + fix errors" on it after I aborted the first round of copies!) 

* 4) Oh, and make sure you've got something like "wakepy" running when you start up your copy job, so that your machine doesn't end up going to sleep during the copy operation before it finishes (resulting in a job you thought you left unattended to run as-quick-as-possible overnight actually terminating about 2-4 hours after you left the room) - This last tip applies to both Windows AND Linux...  Both of these apparently ignore the fact that robocopy or rsync are busily chugging away:  Robocopy doesn't set the necessary flag that wakepy does, while rsync on Linux err... I can't remember the details now!   (e.g. See my "wakepy_keepalive.py" script in my "cmdutils" repo)

 

Outcome: 

I've now replaced corresponding flags for the other drive's backup script too, so hopefully that will  faster when I get there!  (There's still half a month's data to copy at time of writing this post)

 

NOTE: The problem isn't as pronounced when the drives were formatted as NTFS, hence I hadn't really bothered. But as exFAT... yeah... big mistake!  (It's too late to reformat those drives now and re-copy them from scratch again without having to waste another weekend. I'm better off making a third set of backups instead, to be able to have rotating backups instead!)

 

Linux Setup - Partitioning Editor Feature Requests

Based on my experiences today, I'd like to offer the following feature requests to Linux install tool partition editor UI devs:

1) If you have to use MiB, just give us an alternative units drop down for MB (defaulting to MB), and do the necessary calculations / conversions under the hood

2) It's high time to add the option to do a "Standard multi-partition install" equivalent of the "Erase Disk (and create single partition install)". This would essentially ensure you have separate root and home directories (*), with swap + anything else needed all getting auto included too. All of these would be set to default sizes relative to the available disk space, that can then be tweaked as desired (ie mainly OS vs Home dir split).

(*)  In this day and age, that would seem a sensible default choice, given how many OS's need reinstalling every few years anyway, whereas your personal files are often a lot more persistent (i.e. you really don't want to have to keep restoring those from backups all the time)

3) Lower priority, but could we also get the option to reorder partitions we're newly creating / don't exist yet. Makes it easier to figure out how much space we can play with?

EDIT:  Turns out most distros use the "calamares" installer. Hence, I guess these feature requests should be directed towards that project!