BBritten.com - blog

christmas_news

Anonymous (anonymous@undisclosed.example.com) — 2025-12-29T14:12:53+00:00

Christmas News

My apologies to readers for basically not having posted anything over the Christmas period and not even getting around to wishing anyone a Happy Christmas! The unfortunate truth was that I woke up on the morning of December 20th basically unable to move. I've no idea why, but perhaps I'd slept at an awkward angle or something: my neck would spasm in excruciating pain if I did so much as try to talk. Two days in bed, immobile, brought some relief… but the problem still hasn't entirely resolved itself a week and a bit later. I am at least moving around, able to cook the Christmas lunch and get plastered at the local watering hole, though: so things are looking up!

A new version of Giocoso will probably be released on schedule sometime on December 31st, but my enforced bed-rest has meant less ability to code than I'd have liked, so I might push the release date back a day or two.

It's going to be an interesting release, though, because a long-standing speed/screen refresh issue has finally been resolved. The problem is that Giocoso draws its various screen elements at specific positions in the terminal by means of making calls to the external (i.e., non-Bash) tput utility. It works fine… but every call-out to tput requires a context switch on the CPU and is thus relatively expensive in compute resources. On PCs with slightly under-powered CPUs (such as my Raspberry Pi 4 that I use as my music player, or the 2015 iMac I'm now using as my daily driver) the consequence was that every change of the terminal contents would produce notable “flashing” as the screen was laboriously re-drawn. It looked pretty ugly.

And then I started watching Dave Eddy's YouTube channel! The man is a wicked genius at Bash scripting (and other stuff, but his Bash skills are extraordinary) and in his latest Christmas video, specifically around the 32 minutes mark, he happened to mention in passing that he'd written a purely-Bash implementation of much of the tput utility's functionality. Since it's all done within the same Bash session, there's no CPU context switching and the functionality is thus implemented with much greater efficiency than before. His code was therefore swiftly copied and pasted into assorted parts of Giocoso… and the transformation has been immediately, obvious and impressive. The thing finally runs much more effectively and without the 'flashing' during screen re-draws. It's an amazing little tweak, for which I can't thank Dave enough… though he does get a formal copyright acknowledgement in the code comments inside giocoso3.sh!

In the New Year, I'll be busy editing my second edition of the Ralph Vaughan Williams Society Journal, due out before the end of February, so coding is likely to take a back seat during that period. The promised new version of Semplice that (mostly!) runs on macOS will thus have to wait until after that's all done: maybe some time in March, then.

By way of a bit of catch-up, I can't help but report on this, which happened in November:

That's me, fourth from the right, looking directly at the camera, singing on the stage of the Snape Maltings Concert Hall! A lifetime's dream come true, basically The occasion was a 'Ceremony of Carols from Scratch', wherein a complete bunch of amateurs came together to sight-read and rehearse Benjamin Britten's great work from the 1940s, A Ceremony of Carols, and then to give a performance later in the afternoon. I so rarely get to sing these days that the occasion would have been great fun even if it had taken place in someone's backyard. To be able to do it on that particular concert platform, however: amazing!

Now is also about the time that I do a 'year in review' of my music playing. The charts tell their own story: this year, I've played fewer recordings (by number) than in any year since 2018. That's because, in my efforts to drive down the number of recordings in my collection that hadn't been played at least once by Giocoso, I spent the first half of the year playing lengthy works by the likes of Wagner and Verdi. Few in number, but lengthy in terms of minutes of play-time: that's why you'll also see that the 'Play Durations by Year' graph shows me playing 3,875+ hours of music this year …almost matching last year's play durations and comfortably exceeding the duration of music listened to in any of the other previous four years. That many hours, by the way, equates to 161 days: I was basically listening to music for 44% of the year!

My top composers this year have been (with hours of play-time shown next to each composer name):

Johann Sebastian Bach	526
Richard Wagner	400
Ludwig van Beethoven	330
George Frideric Handel	314
Giuseppe Verdi	271
Wolfgang Amadeus Mozart	263
Antonio Vivaldi	120
Joseph Haydn	92
Gioachino Rossini	81
Benjamin Britten	54

Britten squeaks into the list this year because of his November 22nd birthday… everyone else is there because of the 'drive to play everything once' playing campaign. I have found, since that goal was achieved on October 14th, that I'm now playing a huge number of different composers once more, which is much more pleasant. I have Giocoso set up to prevent a composer's works being replayed more than once per month and to restrict play durations to less than 90 minutes: the number of variety of relatively short compositions played have therefore rocketed in the past three months, which has been a delight.

Given the names in the 'top composers of 2025' list, it shouldn't be a surprise what were the most common genres to be played this year (again, with hours played shown in the second column):

Opera	1388
Oratorio	466
Symphonic	388
Choral	351
Keyboard	324
Concerto	221
Orchestral	151
Chamber	80
Quartet	58
Film - Theatre - Radio	53

Most of that huge opera listening was thanks to just two lads from 1813: Wagner and Verdi. They're going to be rare pleasures in 2026, given that the need to play them at least once has now passed and the desire to play them again is tempered by the realisation that you're into a multi-hour-long bout of melodrama and emotional excess if you once start playing anything of theirs!

Perhaps the biggest news from 2025 from the deepest recesses of musical Lincolnshire is that I have abandoned Linux as my daily driver and switched to, er, <cough> macOS. Yup: I don't particularly like Apple's software, but their hardware is lovely and the retina screens from even a decade ago are pleasing to my ageing eyes. I'm really hoping that in the New Year I shall finally summon up the wherewithall to go purchase a modern Apple Silicon iMac from the Apple store in Cambridge. It will involve eye-watering amounts of cash… and I hate the built-in obsolescence timer that means anything you buy now will cease to receive official support in just a handful of years. I had been contemplating a move from Linux to BSD at some point: Linux developers have been doing weird things of late (Wayland, anyone?!) and though I've been using it exclusively since 2012, I've basically had enough of it. Apple's macOS is essentially BSD under the hood, with a very weird userland on top of it! I can cope, I think. I just need the bank balance to expand to accommodate the new fashion!

Anyway, that's it from me for 2025: see you again soon in the New Year, I hope. Entirely incidentally, bonus points to anyone who can examine the thumbnail to this post and work out why AI is very artificial and definitely not intelligent!!

earthquake_in_lincolnshire

Anonymous (anonymous@undisclosed.example.com) — 2026-01-27T17:25:21+00:00

Earthquake in Lincolnshire :-)

It's finally happened, though I think I swore for about 12 years that it never would: I've only gone and bought an iMac! I got the 10-core green machine you see at the left: delivery Thursday, assuming we all survive the torrential rain that is threatening to drown all of us in the UK right now! I've been using my old 2015 iMac for a couple of months now and though I still find the operating system quirky as hell, it's acceptable… and I still get to use all the open source software I got familiar with on Linux. It is, however, the first time I've changed operating systems since about 2010 (when I switched full-time from Windows to Linux, of assorted distro flavours), which is still a bit of a shock to the system! I've even gone and bought an old iPhone 12 (delivery tomorrow!): if one is going to jump down the rabbit hole, one might as well do it with both feet!

I don't know whether it's sensible or not, but there it is: and it makes rather a difference to my software developments! Giocoso and Semplice will become Tier 1 support on macOS now, because I'll finally have an Apple Silicon iMac and a current OS to run things on, no Open Core Legacy Patcher required. Updates to the documentation for Giocoso and Semplice will come in due course.

I'm not sure about Niente: I don't run that on my desktop and it's not really suitable for running on an interactive desktop in any case. It's meant to chug away in the background, doing quite a lot of disk I/O and CPU computations: that's the sort of thing best suited for servers and Apple don't have a server product! We'll see; but it's certainly not a priority.

Anyway: the world's most passionate user of the command line interface is now a confirmed Mac-ite. Wish me luck!

fedora_43_is_out

Anonymous (anonymous@undisclosed.example.com) — 2025-11-19T15:43:48+00:00

Fedora 43 is out

The thumbnail at the left shows a brand new installation of Fedora 43 Workstation running Giocoso in perfect fashion (and with no weird lack-of-graphics problems!).

I dislike the Fedora installation process: it assumes answers to questions it never prompts you for and it's harder than it should be to over-ride those assumptions. For example, no power on Earth would ever persuade me to use the btrfs file system as my main file system but it's Fedora's default option for the root partition. Finding how to change things to use ext4 instead is much harder than it should be, requiring you to click on various unidentified sets of three dots (I believe the yoof call them 'hamburger menus') and then do an awful lot of manual finagling. Not my recommended operating system, then… but at least my software runs on it without drama!

for_the_want_of_an_apostrophe

Anonymous (anonymous@undisclosed.example.com) — 2026-01-12T17:31:56+00:00

Punctuation Matters

Naked Apostrophes

I have recently become somewhat embroiled in a bit of controversy over the correct form of possessive to use when dealing with singular nouns and names that end in single-s: I thought it might be worth documenting my viewpoint and the justification for it. First things first, then: in the 1970s my grammar school taught me a very simple, three-part rule:

Words ending in not-s (e.g., bell) take apostrophe-s: The bell's chime was clear.
Words ending in double-s (e.g., princess take apostrophe-s: The princess's dress was blue.
Words ending in single-s (e.g., bus) take apostrophe only: The bus' route was blocked.

This is indeed coded into my music player Giocoso, with code I first wrote back in 2019:

# For apostrophes, if a word ends in single-s, add only an apostrophe. If it ends in ss or not in s at all, then it's apostrophe+s.    
if [[ ! -z $displaycomp ]]; then   	 
    if [[ ${displaycomp: -2} == ss ]]; then
      displayapostrophe="'s"
    elif [[ ${displaycomp: -1} == s ]]; then
      displayapostrophe="'"
    else
      displayapostrophe="'s"
    fi
  else
    displayapostrophe=""      # If, for some reason, they are playing un-tagged FLACs directly, then we can't be displaying this at all
  fi

This code is why you'll see this sort of thing when playing music with Giocoso:

Or this:

Arthur Bliss ends in double-s, so he gets an apostrophe-s, but Ralph Vaughan Williams ends in single-s, so he gets a naked apostrophe to indicate possession.

It is possible, of course, that I was taught extremely badly back in the 1970s (and it's also very likely that fashions have changed since those days). However, I checked what (vaguely) current authorities on the matter have to say.

First, we have New Hart's Rules, OUP, 2014: The Oxford Style Guide, p.71

This is certainly more nuanced than the rule I was taught. Indeed, with the example given of “Lord Williams's School” it appears to flat-out say my rule is simply wrong. Except that it does no such thing: if it gives the example of Nicholas' and Nicholas's, it's showing that either form is acceptable. I cannot see a meaningful difference between the name “Nicholas” and “Williams”: both are three-syllable names ending in single-s, so what applies to Nicholas should equally apply to Williams. The examples given are, in other words, merely pointing out that long, multi-syllable names ending in single-s can and cannot take a naked apostrophe ending. They specifically chose to say Nicholas' was correct; they could equally well have said that Williams' was acceptable on precisely the same logic… but I imagine space got the better of them!

We shouldn't, in any case, look for a rule spelled out that simply mandates or forbids the naked apostrophe. The point is to demonstrate that a formidable authority on punctuation has just demonstrated that the naked apostrophe is acceptable “where an additional s would cause difficulty in pronunciation”. It is, in other words, more a matter of 'internal voicing' that occurs when you read than a hard-and-fast rule-book approach.

This well-known hospital would, for example, probably want to take issue with their advice on 'personal names ending in s':

Anyway: the New Hart's Rules permits naked apostrophes for singular names that end in s. It doesn't compel their use but it doesn't ban them, either.

My second authority is The Oxford Guide to Style, published in 2002. On page 113 we find:

Almost all these examples (why syphillis should be unique, I have no idea!) support the idea that words ending in single-s get a naked apostrophe when forming the possessive. More importantly, however, is the statement that there is no hard-and-fast rule but that “euphony is the overriding concern”, again making the point that it is the pleasing nature of your 'inner voice' as you read that determines whether a naked apostrophe is acceptable or not.

Which brings me to my inner voice, I guess! When I read of “Vaughan Williams' symphonies”, I do not pronounce it in my head (and never have) as “Vaughan Williamz-iz symphonies”. The extra syllable is, for me, redundant. I hear it as simply “Vaughan Williams Symphonies”, with the middle word pronounced as three syllables, not four. I am not claiming that other people don't 'hear' it with the extra “-iz”: if they wish to type “Vaughan Williams's symphonies”, they're not wrong to do so, if that's how their 'inner voice' works. Whatever is euphonious to someone is correct: I just happen to find the extra syllable jarring and ugly.

It is probably fair to say that I am somewhat old-fashioned in this, however: it's quite difficult to find, quickly, examples of modern literature that do it 'my way'. I can always find plenty of examples from the past that agree with me, of course:

A dog—old Carlo, Mr. Rivers’ pointer, as I saw in a moment—was pushing the gate with his nose, and St. John himself leant upon it with folded arms; his brow knit, his gaze, grave almost to displeasure, fixed on me. I asked him to come in. (Charlotte Brontë, Jane Eyre (1847), Chapter 31)

“I am an archer of my lord Douglas’ outer guard. I can have no promotion save from him or those of his house — not even from the King himself.” (S.R. Crockett, The Black Douglas (1899), Chapter VIII)

Somewhat more modern, though:

A cloud began to cover the sun slowly, wholly, shadowing the bay in deeper green. It lay beneath him, a bowl of bitter waters. Fergus’ song: I sang it alone in the house, holding down the long dark chords. (James Joyce, Ulysses (1921), Chapter 1)

This time, something a little more specifically relevant to music and to Vaughan Williams specifically:

I can think of the complete Matthew Passion, Brahms’ Requiem, and works like Parry's Job and Vaughan Williams’ Sea Symphony… (Adrian Boult, My Own Trumpet, 1973, Page 51)

April 1935 saw the first performance of Vaughan Williams’ F minor Symphony… (Adrian Boult, My Own Trumpet, 1973, Page 106)

Vaughan Williams’ Job made a deep impression, helped perhaps by my idea of putting up some large cards with numbers, which showed the nine scenes, so that the audience could follow dramatically as well as musically. (Adrian Boult, My Own Trumpet, 1973, Page 138)

And finally, something equally relevant to music, but from Benjamin Britten:

…you know how I dislike conducting. But because of Krips’ sudden defaulting I had to take on Budd… (Reed, Cooke & Mitchell, Letters from a Life, Volume 4, Page 42, quoting Britten letter 728 written March 1952).

Anyway: my point remains, there's ample support for using the naked apostrophe on names ending in single-s, in both grammatical authority and literature, including literature that is specifically musically- and Vaughan Williams-related. It's not a requirement, but a personal preference, depending on one's sense of 'euphony'.

Commas

While we're on punctuation matters, I'd also like to throw this in:

That's from the same Oxford Style Guide (2002) as before, this time page 117. It again acknowledges that there is no single, hard-and-fast rule on the acceptable use of the comma: it is a matter of fashion as much as anything and 'best comma practice' is a moveable feast. My own personal approach to them, again taught back in the 1970s, is to never use them before conjunctions and to avoid excessive 'slow down' commas — that is, commas whose function is to exhibit the writer's sense of pacing and breath-drawing which may not match my own. Generally, I prefer to let the reader parse things as they wish or need… but again: it's all to do with 'inner voicing' as one reads, not blind application of a simplistic grammar rule.

Lest I be accused of selective quoting, let me make it clear that the Oxford Style Guide goes on to recommend the use of commas before conjunctions:

My reaction to that is that it's an awfully convoluted rule to state and difficult to apply: you have to assess whether main clauses are 'semantically related', 'grammatically similar' and 'too long', which is an incredibly subjective thing to determine, I would say. Of the first three examples shown, with commas, I would dispose of the comma in the first two. The third one (“I will not try now, yet it is possible…”) I think is just ugly writing. I would re-write it to be “I will not try now. It is possible I may try again in future”. The second set of three examples are, I think, how I would generally try to write: I wouldn't reserve that comma-less approach for just 'short and closely linked' clauses. Interesting that the last example cited is practically a verbatim re-write of the third but without the comma: I think it proves that the comma in that third example is really unnecessary and thereby demonstrating that comma usage is a matter of taste as much as anything else.

It has been said to me directly that commas are necessary to structure a complex sentence properly. They may well be: but my response to that assertion was and remains that you shouldn't be writing sentences so complex that their meaning necessitates numerous commas in the first place. At best, they will make your prose slower to read; at worst, they will not resolve ambiguities that your convoluted prose wraps in a tangle of clauses and sub-clauses. Epithetically: write more simply; need fewer commas.

The Oxford Comma

Of course, the Oxford Style Guide is going to recommend the use of the Oxford Comma (or 'serial comma' as it's sometimes called), too:

I cannot stand the Oxford Comma: for me and my 'inner voice', the presence of that last comma in the list just enforces a pause that is completely unnecessary: there's nothing wrong with 'urban, squat and packed with guile'. There's no ambiguity about what's meant and I'd much prefer to get on to the end of the sentence than have a visual instruction to halt momentarily for no good reason. Putting it bluntly, I find the Oxford Comma slows down reading by introducing visual clues to pause for no good reason.

Sometimes, removing the comma would give rise to confusion. A dedication of a book that read To my parents, Mother Teresa and the pope certainly suggests that the author has two illustrious parents, neither of whom should really be having children at all, let alone together! The suggestion is that re-writing that as To my parents, Mother Teresa, and the pope makes it clear that three separate dedicatees are intended. I don't completely buy that argument but I can certainly agree that the slight, momentary pause introduced before the Pope is mentioned helps makes it a little less problematic. My personal preference would be to re-phrase the dedication completely, however (for example: To my parents, to Mother Teresa and to the Pope).

In the general case, removing an Oxford Comma may need a sentence to be lightly re-worded to make it retain sense and specificity. I think writing is clearer (and more euphonious) when the Oxford Comma is disposed of and I rather suspect that's why the in-house style guides of both The Times newspaper and the The Economist magazine say not to use it. Plenty of other style guides do recommend it, of course: I'm not suggesting otherwise. I am suggesting merely that it is as valid to dispense with it as to retain it.

In conclusion, therefore: naked apostrophes, comma abuse in general and the use of the Oxford Comma specifically are matters of taste and 'inner ear', not ones of rule-book rigour. I do not, in other words, claim that, “I am right” but merely assert that, “I am not wrong”.

giocoso_3.33_released

Anonymous (anonymous@undisclosed.example.com) — 2026-01-01T17:07:20+00:00

Giocoso 3.33 Released

I've just released version 3.33 of Giocoso, a day later than planned …but a day earlier than feared!

Upgrades are via the usual path: Administration menu, Option 1. After the update completes, quit Giocoso and re-launch it to have the new features picked up and applied. Ignore any errors that may be displayed on program exit: they're expected!

Key new features, in no particular order:

Album Art captions are now scaled and sized more appropriately, to better deal with high-resolution monitors
Various improvements to make things work better on macOS
The program logo now displays correctly again
Timebars are no longer limited to 999 hours: they are now unlimited
MacOS now can do Giocoso Pro properly, given that ancient macOS versions will tend to install ancient versions of the MariaDB client, which need special measures to deal with the existence or non-existence of ssl connection issues
MacOS mouse gestures would screw up the Giocoso program display: they no longer do so

Full details, as ever, in the Changelog.

Again: a happy new year to all Giocoso users!

giocoso_and_pipewire

Anonymous (anonymous@undisclosed.example.com) — 2025-10-12T09:19:40+00:00

Giocoso and Pipewire

The Linux audio stack is a convoluted mess!

In the beginning, Linux used OSS (the Open Sound System). This was replaced in the late 1990s by ALSA, the Advanced Linux Sound Architecture. ALSA is a kernel-level sound architecture that has no support for mixing multiple audio streams (so two programs cann't play simultaneously and one would block the other: some of us think this is what playing classical music ought to be like!) and no per-application volume control, because the kernel doesn't concern itself with the details as to what programs users might be running.

Along came PulseAudio, in the mid-2000s. It provided a wrapper around ALSA that allowed multiple programs to sound simultaneously and provided per-application volume control. It also added network audio streaming. By sitting on top of ALSA, however, PulseAudio added complexity to the sound stack and made working out why sound didn't work properly more complex, not less. It also was a high-latency layer, that made real-time audio tricky and started to fail, with jitter and dropouts, when the CPU was stressed enough.

So finally, in around 2015, PipeWire was invented. It replaces PulseAudio with a lower-latency and better real-time performance that's more immune to CPU load than PulseAudio ever was. PipeWire still sits on top of ALSA (ALSA is the kernel-level audio stuff, so both PulseAudio and PipeWire are the user-layer interface to ALSA). Amusingly, PipeWire runs a PulseAudio compatibility layer, so applications designed to run with PulseAudio can (allegedly) work seamlessly with PipeWire. I say 'amusingly' with venom because it now means you run an application and you haven't necessarily got a clue how it's talking to ALSA: it might be using the PulseAudio interface, or the PipeWire. Everything still works either way, so you're left a bit in the dark!

My music player PC (an ancient Mac Mini) runs Linux Mint. Linux Mint switched to using PipeWire as the default audio interface in the Wilma release (which is approximately late last year). I hadn't been aware of any of that… until I did a big software update the other day and things got “interesting”!

The issue is Giocoso's pause/resume functionality. Giocoso tells the process running the ffmpeg audio stream handler either to pause itself or resume itself. Under PulseAudio (or direct ALSA) doing this is not a problem: neither cared if the process was frozen or not, so resuming a frozen playback was without drama.

But PipeWire seeks to be modern and more efficient… which, of course, means it messes with the tried and true! When it detects that audio process has stalled, it suspends audio nodes to save power, marks the stream node as inactive and all its resources are freed. This poses a problem on playback resumption: the audio buffer behind the paused process will have been cleared, meaning that when the audio stream is resumed, it does so with invalid timestamps… and that manifests itself in garbled or 'scratchy' sound.

So guess what happened to my Giocoso setup after I foolishly subjected the Mac Mini in question to a recent software update? Pausing playback worked fine, but resuming it sounded like a Dalek with laryngitis had entered the room. Or maybe a Dalek attempting to sing Tristan und Isolde from the bottom of a swimming pool. It wasn't pleasant, put it that way.

Basically, the punchline is this: if your Linux distro uses PipeWire as its default audio stream handler, Giocoso's Pause/Resume is probably broken.

There is allegedly a fix. If you are able to tell PipeWire, “Do not treat a suspended audio device as being dead”, then the auto-cleanup of resources doesn't take place and the resumption of the playback should work as it used to. To do that, you need to create a new file:

~/.config/pipewire/pipewire.conf.d/99-nosuspend.conf

In that file, you type the following:

context.properties = {
  suspend-timeout-seconds = 0
}

Finally, you re-start PipeWire to get the new setting picked up and applied:

systemctl --user restart pipewire

Once these textual fixes are in-place, you'll find that Giocoso pauses and resumes cleanly once more.

This will be a problem for many modern Linux distros, because they've all been switching over to PipeWire by default quietly in recent months. The same fix should apply to them all. A new release of Giocoso will eventually be produced that applies this fix automatically, if PipeWire is detected on your system… but for now, the fix has to be applied manually.

My apologies for any inconvenience: this is what happens when the technological rug is tugged from underneath one! Giocoso development is, frankly, just a question of keeping up with what other Linux developers are… er, breaking!

Update 1: It turns out that this “fix” doesn't really work very reliably. Fiddling with the PipeWire suspend timeout doesn't appear to have fixed the garbled sound problem if the music playback is paused for a very long time (such as overnight): the resumed playback still sounds awful in that case. I shall attempt to get Giocoso working on different hardware to see if that resolves the issue, though why hardware which worked fine at the beginning of the week suddenly decides to misbehave after a software update is a bit of a mystery!

Update 2: Well, after much fiddling with other hardware, I ended up issuing the following commands on the original PC:

systemctl --user --now disable pipewire pipewire-pulse wireplumber
systemctl --user mask pipewire pipewire-pulse wireplumber

…to stop and disable pipewire. Then I issued this command:

sudo apt remove --purge pipewire pipewire-audio-client-libraries wireplumber

…to remove pipewire and PulseAudio from the Linux Mint 22 system completely. That means this PC is now going to be using ALSA directly (which Giocoso is happy doing). Finally, I issued this command:

sudo apt-mark hold pulseaudio pipewire

…to prevent Linux Mint “accidentally” re-installing either PulseAudio or PipeWire. A reboot followed at this point and, once the PC was back up, I issued the command:

aplay /usr/share/sounds/alsa/Front_Center.wav

…to directly play some sound… and heard everything just fine. The command:

aplay -l

…reassured me that the operating system could still see and enumerate audio devices correctly:

  **** List of PLAYBACK Hardware Devices ****
  card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
    Subdevices: 1/1
    Subdevice #0: subdevice #0
  card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
    Subdevices: 1/1
    Subdevice #0: subdevice #0
  card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
    Subdevices: 1/1
    Subdevice #0: subdevice #0
  card 1: PCH [HDA Intel PCH], device 0: CS4208 Analog [CS4208 Analog]
    Subdevices: 1/1
    Subdevice #0: subdevice #0
  card 1: PCH [HDA Intel PCH], device 1: CS4208 Digital [CS4208 Digital]
    Subdevices: 0/1
    Subdevice #0: subdevice #0

I was thus able to configure Giocoso to use the “plughw:1,1” device (the digital, optical output) and music playback was fine. I then paused a piece of music in mid-play overnight. On waking, music playback was able to be resumed without any garbling or distortion.

The short take on this is, therefore, that Giocoso works fine with PipeWire so long as you don't pause or resume; that it works fine with PipeWire for short pauses and resumes if you set the suspend-timeout-seconds parameter; but that it does not work at all well with PipeWire if you intend to pause for lengthy periods (say, a half hour or more). My advice is therefore to run Giocoso on systems that do not have PipeWire installed at all (such as Alpine Linux); to remove it if it is installed; and to avoid even PulseAudio unless you intend to route Giocoso's playback over your home network. Use ALSA directly, as Giocoso was always intended to do, basically.

It is possible that I shall nevertheless re-write Giocoso's pause/resume functionality to avoid stopping and resuming audio playback at the per-process level. Giocoso already has a pause/resume functionality that involves launching a completely new playback process when music playback is resumed: the Giocoso Pro 'Global Resume' functionality. If that were employed as the sole pause/resume functionality, the garbled sound issue would be resolved even in the presence of PipeWire. It's a lot of work, however, and I wouldn't hold my breath!

giocoso_broken

Anonymous (anonymous@undisclosed.example.com) — 2025-10-24T13:26:01+00:00

Giocoso Broken!

Click on the thumbnail to this post and see if you can see a bit of a problem!

In one window, on the left, you see Giocoso running as it's supposed to: displaying album art within its terminal session. In the window on the right, however, you see Giocoso playing music just fine… but there's no album art on display.

Giocoso has always displayed its album art by using a technology called “sixel graphics”. Terminals that support sixel graphics can display an image within the terminal by using a command such as: img2sixel albumart.jpg. Konsole, the KDE terminal I'm using on the right of that thumbnail has always supported doing this, which is just as well as it's the terminal I use daily to develop Giocoso in the first place! Unfortunately, as that screenshot tells you, Konsole has stopped doing this for mysterious reasons that I can't fathom. It now means that Giocoso run on any version of KDE within a Konsole window is at risk of not being able to display album art graphics sometime in the near future. The specific version of Konsole that appears to have developed this problem is version 25.08.2.

Since my desktop PC runs on EndeavourOS (a bleeding-edge distro based on Arch Linux), it's software stack is forever being updated: it's picked up the new version of Konsole and has lost the ability it once had to display in-terminal album art. My music playing PC (the one that's plugged into the amplifier and speakers) is running Debian 13, a much more sedate (some would call it old-fashioned!) distro that is running version 24ish of Konsole. Clearly, the Konsole developers nixed sixel graphics sometime in the last year: I'm not holding my breath for them to un-nix any time soon, sadly.

There are alternative terminal emulators, of course: xterm, for one. Unfortunately, they need to be compiled with sixel graphics support and none of the many terminals I've tried on EndeavourOS display sixel graphics properly:

That's xterm not displaying a JPG file. It's true for uxterm, too; for ghosty; for mintty; darktile, gnome-terminal and any other terminal emulator you might suggest, at least on EndeavourOS (and Arch or Arch-derived distros in general: I found Manjaro to be similarly affected).

The only exception is a terminal emulator called kitty, which doesn't use sixel graphics at all, but its own unique way of doing in-terminal graphics which continues to work in every environment I tested:

Unfortunately, you can see that kitty displaying anything requires some quite new syntax… and positioning the graphics display is nowhere near as easy to do as with sixel graphics. I'm also reluctant to make Giocoso dependent on a specific terminal emulator. So, this is not a road I'm keen to journey down.

Of course, Giocoso already has a workaround:

You've always been able to configure Giocoso to display the album art in its own separate pop-out window, which is nowhere near as elegant but continues to work fine, even on Arch-based distros:

For now, my understanding is that this is the only way to get album art displayed correctly on a fully-updated Arch-based distro. More worryingly, as other distros upgrade their KDE environments, I suspect they will lose the ability to do in-terminal graphics display, too. There's nothing much I can do about that, I'm afraid, though I am on a kitty learning curve as we speak.

Edited to add: I have swiftly realised that the kitty terminal emulator is just a special example of a terminal that understands the kitty graphics protocol. Other browsers can understand that protocol too, so it's easy (even on an Arch-based distro!) to get Konsole or other browsers to display images using it:

The title bar tells you this is Konsole… but it's still displaying a piece of albumart anyway! So this is definitely a route I will have to travel in the near future, I think!

giocoso_over_a_dodgy_network

Anonymous (anonymous@undisclosed.example.com) — 2025-10-10T18:19:29+00:00

Giocoso over a dodgy network

I recently had trouble talking from me desktop PC to my music-playing PC, running Giocoso. I'd launch a remote ssh session to the player PC, kick off some music playback …and the ssh connection would die, stopping the music playback as it did so. Very annoying if, say, you'd played 1.75 hours of a 2 hour opera: when the ssh session dies, the partial play is essentially regarded as never having happened, so you have to start from scratch next time you connect.

My first thought on fixing this was: screen. It's a utility you launch on the music-playing PC immediately after you've ssh'd into it from the desktop PC, and then within screen, you can launch Giocoso. If the ssh connection dies between desktop and player PCs, screen and anything launched from within it continues to run regardless. Brilliant! But, unfortunately, this is what launching Giocoso inside screen looks like:

Complete gibberish, of course! I mean, you can just about make out menu options and navigation aids and the thing will actually play music.. but it's obviously not ideal! It probably has something to do with the way Screen handles terminal emulation: I did try fiddling with the value of the TERM environment variable before launching Giocoso, but it really didn't make any difference.

So my second thought was tmux, which does the same sort of thing as Screen: provide an environment in which programs can be launched such that, should the network die, the running program doesn't.

So I tweaked my desktop PC's launcher for 'remote Giocoso'. It's application remained unchanged from before:

/usr/bin/uxterm

…that is, everything continues to run inside a local session of the 'uxterm' console program. What's different is the “arguments” that you pass to that uxterm session as it begins. Mine used to read:

-T 'Giocoso - A Digital Music Player' -xrm 'xterm*iconHint: /home/hjr/.local/share/giocoso3/art/giocosoico.xpm' -bg black -fg green -geometry 103x28+0+0 -fa 'Luxi Mono:style=Regular' -fs 12 -ti 340 -tn xterm-256color -e 'trap "" HUP; ssh -Y -t hjr@192.168.137.34 /usr/bin/giocoso3.sh'

…which is “give the terminal a name and a thumbnail icon, set it to be black with green text, make it 103 columns wide and 28 rows high, positioning it in the top left of my desktop PC's monitor; set the font to something nice, and then ssh over to the music-player PC and launch Giocoso”. Looks messy, but it worked (or did if the network stayed up)!

The new “arguments” however now read as follows:

-T 'Giocoso - A Digital Music Player' -xrm 'xterm*iconHint: /home/hjr/.local/share/giocoso3/art/giocosoico.xpm' -bg black -fg green -geometry 103x28+0+0 -fa 'Luxi Mono:style=Regular' -fs 12 -ti 340 -tn xterm-256color -e "ssh -Y -t hjr@192.168.137.34 \"tmux new-session -A -s giocoso '/usr/bin/giocoso3.sh'\""

Most of that starts off exactly as it used to. The new feature is that having ssh'd to the remote PC, it doesn't directly launch Giocoso, but launches tmux and creates a new session (called 'giocoso') and, within that session, runs the giocoso3.sh executable. This appears on my desktop PC almost exactly the same as it used to… except that I can now physically close the Giocoso window, thereby manually terminating the ssh session… and the music previously playing will continue playing without interruption. If my network dies of its own accord, the player PC will similarly continue playing without a murmur. Especially nice is that if I re-launch Giocoso on my desktop, it will automatically re-connect to the remote tmux session and display it exactly where I left it, album art and all.

The only slight fly in the ointment is that, by default, tmux likes to display a status bar at the bottom of the terminal window it's running in:

That glowing green bar at the bottom of the screen rather throws off my geometry calculations: Giocoso needs to run in a 103×28 terminal window… but if one of the vertical lines is taken up by tmux's status bar, Giocoso gets muddled:

None of the lines actually appear where they should and text over-writes them in places. The fix for this is relatively straightforward. One possible fix is to retain the status bar and just amend the “arguments” for my launcher to launch at 103×2*9* rather than 103×28. That's a client-side fix, of course. The fix I decided to adopt is a server-side one: on the remote PC, I create the file $HOME/.tmux.conf and type the following code into it:

set -g status off

Once a new tmux session starts, it picks up this new setting… and the result is:

The title bar of that terminal tells you that the session is running tmux… but now there's no bright green bar at the bottom of the screen. The status bar is off!

All of which means that no matter how dodgy my network connection to different parts of my home might be, I can be confident that Giocoso will play things through to completion, every time: no more getting 4.5 hours through Götterdämmerung and then having the rug pulled out from under me yet again! A future Giocoso installer may implement this tmux configuration tweak directly, though I haven't decided on it yet. Obviously: it only affects people who use Giocoso via a network/ssh connection, so it is maybe a bit niche to start making sweeping configuration changes to other programs at this point!

giocoso_random_music_selection_logic_bomb

Anonymous (anonymous@undisclosed.example.com) — 2026-03-25T09:18:49+00:00

Giocoso Random Music Selection Logic Bomb

Imagine I have 100 recordings by Benjamin Britten, of all sorts of durations, from 2-minute long songs to 3-hour long operas. Imagine, too, that I have asked to select 10 recordings by Britten, that last between 20 and 40 minutes, but only the first of the 10 should actually be picked to be played for some reason.

What Giocoso used to do was take the 100 recordings and randomly “rank” them: that is, it would assign a system-generated number to each one, starting at 1 and finishing at 100. Then it would grab the recordings with the first 10 ranking numbers (i.e., items 1 to 10), since that’s what I’d asked for it to select. Finally, it would assess those 10 recordings for their duration and make sure they fit between 20 and 40 minutes.

Here, for example, is the first pass: randomly select 10 recordings by Britten and rank them:

Now we apply the “between 20 and 40 minutes” filter:

Only three recordings now match all our selection requirements.

Except there was one other requirement which makes things even worse: from the possible play candidates, play only one. The way Giocoso did that was to say “where rank = 1”… and I hope you can see that I won’t be playing anything by Benjamin Britten, because his ‘rank=1’ item is one of the forbidden recordings (forbidden by its long duration). The Cello Symphony could be played on duration grounds, but because it was already assigned a rank of ‘3’, the ‘rank=1’ selection test renders it ineligible for play.

This is how Giocoso has been selecting music for a long while now… and it’s logically flawed. It certainly “worked” with a sufficiently large music collection with sufficiently high numbers of different composers and with sufficiently lax duration requirements: but it ranked first and filtered second… and doing things that way round means that lots of eligible recordings (say, Britten’s Cello Symphony or Violin Concerto from the above example) would not get selected, because they happened to be assigned the wrong, not-1, ranking number early on.

The logically correct way of doing things is to filter first and rank second. If I had done that, I would have struck out all the red items in the last table for duration reasons and that would have left this selection of three candidate recordings:

Only now do I assign a ranking:

When I finally add in the “rank = 1” selection restriction: lo and behold, my next cycle of 10 plays will include the Cello Symphony.

By assigning rank early, I make it highly improbable I’ll find a recording to play (it is pot-luck if a duration-qualified recording might get assigned a rank of ‘1’); by assigning it late, assuming any recordings meet the duration requirement, I’m absolutely guaranteed to pick one of them when I add the ‘rank=1’ restriction.

I mention this now because I’ve fixed it in the forthcoming release of Giocoso 3.37. That release (I’m tentatively aiming for the very end of March) re-orders the selection and ranking operations, with the result that it’s now much easier for recordings that qualify on duration or other configured selection criteria to make it through to being played, without being artificially disqualified on the grounds that their randomly-assigned rank number is ‘wrong’! Instead of seeing lots of this screen:

…you'll see much more of this sort of screen:

Giocoso music playback is, in short, now much more likely to play a diverse mix of works by multiple composers than before, whilst still holding fast to the ‘one composer per cycle of plays’ principle. I'm only sorry it took me this long to work out why I was having quite so many of the 'no music to play' screens before!

I’ll announce the next release here when it happens, of course: right now, I’m giving it multiple days of testing to ensure the logic is now really where I need it to be!

giocoso_version_3.32_released

Anonymous (anonymous@undisclosed.example.com) — 2025-12-12T20:18:27+00:00

Giocoso Version 3.32 Released

A day later than anticipated, I've just released Giocoso Version 3.32. It contains some significant new features, including support for Kitty graphics for terminals that can't display album artwork using sixel graphics; a terrible logic bomb I created back in 3.30 affecting the way the time bar worked that is now fixed; a new installer that looks better and performs more efficiently; and support (somewhat rudimentary!) for running on macOS.

Administration Menu Option 1 should get you the update, without major issue.

Edited to add: documentation is progressing well, with new pages regarding installation on Windows 11 now nearly complete.

giocoso_version_3.34_released_early

Anonymous (anonymous@undisclosed.example.com) — 2026-02-08T12:35:13+00:00

Giocoso Version 3.34 Released (Early!!)

I've just released a new version of Giocoso, Version 3.34: that's about 20 days earlier than planned, as a result of testing and dog-fooding having gone so well.

The big new feature is, I think, support for ReplayGain: if you enable the feature using the Administration menu, Option 2 you'll see the following new option:

It is set to 'no' by default, but if you set it to 'yes' and then play some music for which ReplayGain metadata tags have been computed and written, Giocoso will apply the necessary volume boost in real time, dynamically. It's a feature that music players like Foobar2000 have had for years: it was about time Giocoso caught up!

The program interface has had a bit of a makeover, too:

You'll note the ReplayGain information is now displayed (it says 'None' if you haven't switched on the new feature, or if your music files don't contain ReplayGain information tags) and that techy details have been 'ruled off' from the composer-composition-performer details. A minor 'touch up' to the look and feel, but I think it looks a bit tidier.

There are several other key new features, some of them quite important: read the Changelog for details, as usual.

Buried amongst references to bug fixes and enhancements is the over-riding truth that quite a lot of work has gone into refining the running of Giocoso on macOS, especially new, Apple Silicon macOS using Homebrew. Previously, much of my Apple work was done on older, Intel-based Macs that installed software dependencies via MacPorts. The two package managers work rather differently and pull down rather different software for the same package name, unfortunately! Anyway: that's going to be an on-going process, now that I've switched to macOS full-time, but things already work smoothly for me now.

Upgrading to the new release is accomplished in the usual way: take the Administration menu, Option 1 and follow the prompt to supply your sudo password. Once the update has completed, quit Giocoso completely (ignoring any error messages you might see on the way out) and then re-launch the program from scratch.

Have fun!

giocoso_version_3.35_released_early_again

Anonymous (anonymous@undisclosed.example.com) — 2026-02-22T14:01:43+00:00

Giocoso Version 3.35 Released (Early again!!)

I have just released Giocoso Version 3.35, a few days earlier than planned. It is a decently-significant release, in that it contains more bug fixes for running on macOS and a completely new reporting infrastructure: instead of attempting to display data within the confines of a size-restricted terminal, all Giocoso reports now open in a browser. By default, your system's default browser will be used, but a new configuration parameter allows you to specify any already-installed web browser instead:

In addition, a new report and selection filter allows you to see who your 'rarely-performed' composers are: that is, composers who haven't had anything played within the past 120 days. The selection filter is configurable (so you could declare 'not played within 82 days' to be 'rarely-performed') but the report is not.

Anyway: full details as ever are over in the changelog. Upgrading is the usual business of using the Administration menu, Option 2 and following the prompts. For assorted reasons that needn't detain us, you may be told at the end of the upgrade process that 'something went wrong': ignore that, quit Giocoso (ignoring any error messages that might appear on the way out) and then re-launch the program. A second attempt at an upgrade should give you a message along the lines of 'you're all good: nothing needs updating', at which point you're good to use the program as normal.

giocoso_version_3.36_released

Anonymous (anonymous@undisclosed.example.com) — 2026-03-18T12:36:03+00:00

Giocoso Version 3.36 Released

I have just released a new version of Giocoso: version 3.36. Full details are, as ever, in the relevant Changelog. Key takeaways, however, are:

Better handling of PulseAudio from within the program, rather than relying on environment variables
The introduction of minig: a way of launching a minimal Giocoso interface that can initiate playback or control existing playback from the sort of small, portrait-oriented terminal you'd likely get on a mobile phone (basically replacing mgiocoso, though that still exists for now, too)
The usual array of bug fixes, including one that means Giocoso is not flummoxed by decimal separators that are not the usual '.'
A new program logo that now works better with non-black terminal colour schemes:

Updating is accomplished in the usual way: take the Administration menu, Option 1, supply the sudo password when prompted and sit back and let it happen. Quit Giocoso when the update completes, ignoring any error messages that might appear on the way out. Re-launch the program and enjoy!

giocoso_version_3.37_released

Anonymous (anonymous@undisclosed.example.com) — 2026-04-01T09:04:54+00:00

Giocoso Version 3.37 Released

I have just released (on time!) a new version of Giocoso: it now moves to version 3.37. It is a fairly significant release for one main reason: the default music search algorithm had a fatal bug in it, which I discussed at length in a previous blog piece. This release fixes that logic error, resulting in much more music qualifying for randomised selection than before.

A less meaningful (but perhaps more fun!) enhancement to the program is that you can now adjust its visual components' colours. If you don't like the default cyan logo text, you can change it to magenta instead, for example. I noticed that some users don't run in jet-black terminal sessions like I do: this lets them make Giocoso usable even in light-coloured terminals.

I regret that this update is a bit messy to implement. You should certainly start by taking the usual Administration menu, Option 1 to obtain the newer software and providing the sudo password when prompted. Unfortunately, the result of that upgrade will look something like this:

Error messages visible from the operating system, a Beethoven image appearing in completely the wrong place, all text one colour and the wrong colour at that… yuck! Fortunately, it's easily fixable: just take the Administration menu, Option 2 to edit the configuration file. Just click the [OK] button to cycle through all the pages of the dialog. When you click [OK] on the last of the pages, you'll be returned to the main menu with everything looking perfect:

Added immediately after the release: It is possible that you now won't see visual mayhem on quite this scale after an update: a couple of tweaks to some code has tackled most of these issues out-of-the-box, I believe. But it does no harm to warn you of what can happen and how to fix it, especially as even now, I'm pretty sure you'll be needing to adjust the size of that Beethoven logo: which still requires a visit to the Administration menu, Option 2 and an adjustment to the 'Size of the Program Logo' setting.

The temporary problem is caused by your existing configuration file not having the new colour codes in it: merely editing the file and doing nothing causes default codes to be added to the file, after which the program displays normally. You could then use the new Administration menu, Option 8 to modify the program colour settings to something that is non-default and more suitable to your needs.

Full details about what's in the new release are available, as always, from the Giocoso changelog.

That concludes the bug-fixes and tweaks to all three of my music-related bits of software: I rather suspect that they will all now 'go quiet' for a good few month, unless someone gets in touch to report a bug or two that I haven't encountered! Here's to a less code-filled few months!

got_there_at_last

Anonymous (anonymous@undisclosed.example.com) — 2025-10-14T08:55:02+00:00

Got there, at last!

The screenshot at the left tells you that, after about 5 or 6 years of working towards it, I've finally achieved my goal of having listened to every recording in my collection, with Giocoso, at least once.

The last few recordings were dealt with much faster than I'd anticipated, in fact.

So what's next? Well, basically… to immediately screw up the statistics by adding a bunch of new recordings to which to listen! There's 758GB of ripped music sitting on my hard disk that needs classifying, cataloguing and adding to the collection. That's approximately 1,895 new CDs-worth of music. It will be added in small increments, though, with listening to the new additions being worked into randomised re-listening of existing music, so the 'percentage unplayed' should never rise significantly. (Famous last words!)

Progress on switching things over to bbritten.com continues, if not exactly at pace then at least with slow determination!

I also have to apologise to visitors again, today, for a network outage that made the site unavailable for around a couple of hours. Not my fault, this time, but my ISP's (though we don't yet know the details). That's the third outage since the end of August, one due to the network infrastructure, one due to a widespread network outage and now one due to an ISP's apparent inability to configure itself properly. Very annoying… but they each gave me more time to listen to music, so it's all good in the end, I guess!

happy_new_year_2026

Anonymous (anonymous@undisclosed.example.com) — 2025-12-31T18:46:32+00:00

Happy New Year, 2026

A short note to wish all my readers, regulars and just-passing alike, a very happy 2026. I shall likely be off-line for much of January and early-to-mid-February, given my editing responsibilities for the Ralph Vaughan Williams Society's Journal, but I hope to keep the software coming nonetheless.

happy_st._britten_day

Anonymous (anonymous@undisclosed.example.com) — 2025-11-21T15:53:59+00:00

Happy St. Britten Day!

Tomorrow being St. Britten's Day (well, OK: it's actually St. Cecilia's Day, patron saint of music, but it also happens to be the birthday of the chief of her sons, the blessed Benjamin Britten, who you might have noticed is a sort-of patron saint around here!), I shall wish you all a happy Benjamin Britten Day and encourage you to play nothing but the great BB for the day.

I shall be telling Giocoso to do precisely that (and, in truth, have already started, for a couple of days now, as my play history might tell you!) and I think you'd find it rewarding too.

But, seriously: listen to any good music you care about. As Wystan Auden once put it: Blessed Cecilia, appear in visions to all musicians: appear and inspire!

macos_woes_part_94

Anonymous (anonymous@undisclosed.example.com) — 2026-03-23T18:46:42+00:00

MacOS Woes (part #94)

I'm two months into my 'exciting' adventure with macOS! For the most part, it's been fine, even if the windows handling is primitive and its privacy/security settings can seem a bit over-eager at times. Today, however, I got really cheesed off! The problem is a big one for fans of classical music who are forever having to tag things with ß, ä or è characters. Like me who, yesterday, finally got around to cataloguing a performance of Ernest Chausson's Poème.

The first issue is how you type foreign characters on an iMac at all: it has its own native way of doing it (for example, holding down the 'e' key will, in most situations, produce a pop-up from which you can select the appropriately-accented version), but that doesn't work in Semplice because all you get by holding down the 'e' key there is 'eeeeeeeeeee'! Anyway, I sorted this out way back in January in a way documented (roughly) here: see the section headed "Compose Key". I can now type “poème” as I would have done on any Linux machine: tap right-command, press `, press e: job done!

This morning, however, I played the piece I catalogued yesterday and saw this in Giocoso:

In case it's not obvious, let me zoom in on the artwork display there:

Rather than “Poème”, we have Giocoso rendering things as “Poe me”: no accent, but an extra space. But look over on the left-hand side of the Giocoso display: there the work is rendered as “Poème” entirely correctly! And here's the thing: both the artwork and the left-hand side text are both being read from the same metadata tag (in this case, the ALBUM tag). So what's going on?!

The issue basically boils down to the fact that (unbeknownst to me!) there are actually two Unicode renditions of any given character. We might call them “composed Unicode” and “decomposed Unicode”, because the point is that è can be represented as a single, merged glyph or character, or as a combination of the separate “e” and “`” characters. Linux uses the “composed” version of accented characters… and, guess what?!, macOS uses the “decomposed” version. The net result is that, if you tag your music on macOS, you think you're typing a single, composed è, but macOS steps in and stores it as the decomposed “e+`” equivalent. Text applications tend to render either version identically (which is why the left-hand side of Giocoso gets it right), but ImageMagick, the graphical program that's used to generate the artwork and captions for the right-hand side of Giocoso's display, does not.

What's particularly annoying about this is that my Karabiner Elements keybindings explicitly produce composed Unicode in the NFC form… yet macOS takes it upon itself to decompose the resulting character and store it in the decomposed, NFD form. It deliberately changes what you've typed in! And in a way you'd never know, because things like file systems display the results identically.

Anyway, after some tweaking of the Semplice code and a bit of re-tagging, this was the result by this afternoon:

And zooming in again for clarity:

The cost of this fix? It's to make the uconv utility a dependency of Semplice on macOS (it's installed as a consequence of installing icu4c, which is done with a brew install icu4c). Semplice detects if you're running on macOS and, if so, takes your input for composer, composition, performer name as well as all other textual tags and passes them through the uconv utility to explicitly (and, this time, successfully) turn them into the composed, NFC version of Unicode that Linux recognises and prefers. If that utility is not present on your macOS then the conversion to composed Unicode doesn't happen and you may end up having to deal with captioned album art with weird spaces in it in future!

A new version of Semplice is imminent, but its release may have to be pushed back a little to ensure this latest cludge is working correctly! Watch this space, anyway. The new version will, of course, only affect fresh Semplice installations: if you're already using Semplice on macOS you'll need to install icu4c manually and, in addition, you'll need to make sure it gets into your PATH so that Semplice can find it when it needs to. Using Homebrew, the commands are:

brew install icu4c
sudo ln -s /opt/homebrew/opt/icu4c@78/bin/uconv /opt/homebrew/bin/uconv

If you're using Macports, the equivalent command is:

sudo port install icu

The “4c” part of the name is omitted and there's no need to link anything when using Macports, as the install ends up going into your existing PATH anyway.

It's annoying that there is such a low-level discrepancy in the way macOS and Linux handles such a fundamental issue. I wasn't aware of it earlier, simply because I hadn't done a lot of tagging work on macOS that involved characters with accents and the like… but the minute I started, the problems erupted, too! Hopefully fixed, anyway.

niente_version_4.04_released_on_time

Anonymous (anonymous@undisclosed.example.com) — 2026-02-28T13:21:05+00:00

Niente Version 4.04 Released (On Time!!)

Completely on schedule, despite a migration of my website to a Proxmox-hosted LXC container and a whole new iMac purchased at the end of January (I trust I am impressing you!), I have today just released a new version of the Niente FLAC-checking program. It is the first new version since 10th April 2025, brings the version number up to 4.04 and is a fairly significant release for a number of reasons.

Principle amongst these is the significant amount of code re-writing needed to make Niente a full first-class citizen on macOS, AlmaLinux 9 and AlmaLinux 10. This website's own page of Niente statistics has been produced by macOS since about the 10th February; between December 2025 and the end of January 2026, they were coming out of AlmaLinux 9; and between February 1st and February 9th, they were the product of AlmaLinux 10. All three new operating systems have been tested pretty comprehensively, therefore.

The other huge new feature is a complete overhaul of Niente's reporting mechanism. Niente is, fundamentally, a metadata collector and a report generator, so to have half its core functionality pretty much re-written from the ground up is fairly significant! All Niente reports have had their logic tweaked and refined… and every one now outputs to your system's default web browser. A new configuration option allows you to specify a specific browser if you prefer, but if you leave it blank (which it is by default) whatever your default browser is will be used to display all reports.

One final key new feature I should mention, too, is that Niente is now ReplayGain aware: its database table acquires a new column to store any ReplayGain_Album_Gain metadata tag values detected within a FLAC: if there is none, that results in a new item on the Aggregate Statistics report, counting the number of FLACs that don't have ReplayGain data. You might have no interest in ReplayGain, of course, in which case you can ignore the statistic: it's listed as an “other” statistic and therefore not actually indicative of a physical or logical metadata problem.

Full details, as ever, are in the Niente changelog.

Upgrading is a bit of an issue, this time round. The last version of Niente was released back in the day when the source of software updates was absolutelybaching.com. It is therefore unfortunately the case that attempting to use the usual Administration menu, Option 5 to update will not work, as the program will be attempting to obtain fresh software from the wrong source. To obtain the latest Version 4.04 software, therefore, the upgrade procedure is simply:

wget software.bbritten.com/neninst
bash neninst

…and follow the prompts. It's basically a fresh installation from scratch and is likely to mean that you'll need to perform a full database re-load (Database menu, Option 2) followed by a full integrity check (Integrity Checks menu, Option 1). Apologies for this break in the usual upgrade process: the change of website between absolutelybaching and bbritten.com is the sort of one-off upheaval that has unintended consequences! It shouldn't happen again.

niente_version_5.05_released

Anonymous (anonymous@undisclosed.example.com) — 2026-03-29T13:09:21+00:00

Niente Version 5.05 Released

I have just released (almost on-time!) the latest version of Niente: version 5.05. The changelog, as ever, has all the details, but the short version is that there was a fairly nasty bug concerning Niente and ReplayGain, which is now fixed; and there's been a whole truck-load of flim-flammery concerning Niente's visual appearance. The story there is, basically, to bring it in-line with how all my other software works (or is about to work): colour selection and a graphical logo.

Unfortunately, these changes mean that the upgrade process is not as simple as using the Administration menu, Option 5. It's a little bit more convoluted than that! Here goes:

First, make a note of all your existing configuration settings. We're going to wipe these shortly and you'll need to be able to put them back later. So take a screenshot now of Administration menu, Option 5 and or otherwise note the contents of that configuration setting: we're going to need to use that as a template later.

Next, you need to ensure that both libsixel and kitty are installed, so that Niente can do its new 'graphical logo thing'. How you do that depends on your distro:

Fedora: sudo dnf install libsixel libsixel-utils kitty
Mint: sudo apt install libsixel-bin kitty
AlmaLinux10: sudo dnf install kitty
Suse: sudo zypper install libsixel1 libsixel-utils kitty
Arch: sudo pacman -S kitty libsixel
Debian/Raspbian: sudo apt install libsixel-bin kitty
Ubuntu: sudo apt install libsixel-bin kitty

I should explain that I cannot find a way to install sixel graphics support on AlmaLinux 9 or 10, so we don't bother and instead install the Kitty terminal, which is a completely different ball-game that still manages to install support for doing in-terminal graphics. Note that this means either that 1) you can't use 'gnome terminal“ to run Niente going forward; or 2) if you insist on using gnome-terminal, you're not going to see the 'beethoven looking grumpy' logo.

Anyway, once those new packages are installed, you fire up Niente and take the Administration menu, Option 5: Check for software updates. Follow the prompts and the upgrade process should complete without error… except that you're very likely to see variations on this unholy mess at the end of it:

Don't panic! At this point, exit Niente (tap 'x') and then issue this command:

rm -f $HOME/.local/share/niente/txt/niente.conf

That deletes your specific persistent configuration file, because the absence of such a file triggers Niente to create a default one, containing all the new parameters that the new version expects to find. Of course, this also means that the new configuration file will be missing all the really important personalised settings you may have set previously: that's why you were told to make a note or screenshot of those existing settings before we started! You did do that, didn't you?!

Now you can re-launch Niente (on AlmaLinux, this must be from within Kitty): you will likely be warned that your new, default configuration file mentions a database called “niente” (the default name), but that no such database exists:

Again, this is the consequence of having deleted your original configuration file. It's expected, so click [OK] and Niente will launch in its new 4.05 guise. Immediately visit the Administration menu and take the Edit Configuration File option. Put back all the 'correct' configuration file options you previously made a note of, such as the default database name. Make sure you add in values for 'Preferred browser', for example. If you are on AlmaLinux, you must switch on “Use Kitty Graphics”: set it to a value of “yes”. Quit Niente once more and then immediately relaunch into it: you should now find that you're viewing Niente correctly, with colour, and with a colourful logo in the left-hand pane:

You may well notice, as in this screenshot, that the logo is way too big and in completely the wrong place! Again, don't panic: you have the Administration menu, Option 1 to adjust the 'Size of the Program Logo' and the “Program Logo position'. On my particular virtual machine, displaying on an iMac (so who knows what the right settings might be on real hardware?!), I found setting the logo size to “110” and the position to ”-5” to be ideal:

Play around as you like… and then consider taking the Administration menu, Option 6 to fiddle with the colour values associated with the various program display elements.

I'm sorry the upgrade process is a bit more convoluted than normal this time around. If you prefer, you can simply re-install Niente from scratch:

wget software.bbritten.com/neninst
bash neninst

A fresh install automatically installs the Kitty terminal and libsixel components needed to get that graphical logo displayed correctly. For a mere upgrade, you have to take care of those extra component requirements manually, I'm afraid. It is a once-off requirement! I did find that even on fresh installations, Niente would look ghastly until you had taken the Administration menu, Option 1 and pressed [Enter] to create a new persistent configuration file: it's a quirk of the transition, sadly.

Additionally, note that you don't have to run Niente with a graphical logo. If you would prefer to run Niente on AlmaLinux (for example) in the gnome-terminal, without switching on Kitty graphics, that will work just fine:

You just won't see the 'grumpy beethoven' icon on the right-hand side (which some might prefer, the Luddites!)

Note that unmentioned in the changelog is a bunch of code tidying that is really rather important that you have: I can't tell you the number of subtle code howlers I spotted whilst preparing this release! So I'd encourage you to upgrade, apologise again for the extra steps required, and assure you that nothing this big should happen again for quite a long time!

normal_service_has_been_resumed

Anonymous (anonymous@undisclosed.example.com) — 2026-03-26T17:07:22+00:00

Normal service has been resumed...

I had noticed that in recent days, this website had started to produce quite a few occasional '502: Bad Gateway' errors. This morning, it turned into a veritable flood, to the point where I literally could barely write anything without triggering one. I have accordingly spent a long 5+ hours trying to get things back on to an even keel, all ultimately without success. In a fit of desperation, I moved my entire website out of a Proxmox container and back onto physical hardware (albeit quite slow physical hardware!)

I trust that if you're reading this, it demonstrates that the move has achieved its goal of getting the site back online and in good order. My apologies for the outage. It does, unfortunately, mean that the raft of software updates I was planning for in the next day or two will have to be bumped back a bit (maybe a week).

normal_service_will_resume_in_3...2...1

Anonymous (anonymous@undisclosed.example.com) — 2026-02-26T22:03:12+00:00

Normal Service will resume in 3...2...1...

My apologies for the fact that this site was down for most of yesterday. I was in the middle of a long-planned move of the site from a virtual machine to an LXC container, for efficiency reasons, when real life intervened and I had to leave the migration in mid-move. I believe everything has been brought across now and normal service should have resumed, but see the picture at the right….

Let me know if you spot any outstanding issues.

poor_peter_grimes

Anonymous (anonymous@undisclosed.example.com) — 2026-03-10T18:46:05+00:00

Poor Peter Grimes

Last Friday, I had a great night out at Nottingham's Theatre Royal to see a performance by Opera North of Benjamin Britten's Peter Grimes. Expectations were high: I don't think I've ever seen a whole performance of this opera live, though I definitely remember walking out of Jon Vickers' mangling of the role at a performance in Covent Garden sometime in the 1980s! Let me say at the outset that I enjoyed the evening, on the whole. The orchestra played wonderfully and the chorus sang vividly: no complaints there, at all. They were thrilling to hear. Balstrode and Swallow were sung magnificently; Ellen Orford was sung rather well; Bob Boles' was also a strong performance. Unfortunately, Auntie was sung by someone who simply couldn't get down to the low alto notes and therefore was practically inaudible throughout. Peter Grimes was also not sung brilliantly: his Act 1 was fine. His mad scene was histrionic without emotion. And throughout, his top notes just weren't really there. When your eponymous hero can't quite sing the best parts of the role, you have a bit of a problem, I feel!

All that said, the music wasn't the main problem of the evening. That belongs with the director. The opera is supposed to open with a “bang!”: “Peter Grimes, Peter Grimes, we are here to investigate the cause of death of your apprentice, William Spode”. Straight in, no messing, scene set, backstory explained, all done within 20 seconds of the conductor raising his baton. What we got in Nottingham was some sort of “pantomime”, in which the curtain rose, silence descended and a torso wrapped in fishing nets was 'discovered' by children scampering across the stage. Presumably, this was the body of William Spode: though I have to say it was an exceptionally well-developed torso of a thirty year-old, not exactly your weedy boy apprentice that William Spode is supposed to have been. Regardless of the incongruent torso's physique, however, the point is: the opera doesn't require a stupid pantomime to contextualise the rest of the action. That's done for you in the first 18 words of the opera, blasted into the auditorium within seconds of the music starting. The pantomime was just the director trying, one presumes, to spoon-feed a context to an opera-illiterate audience. I didn't appreciate it, shall we say?

Worse, the ending: Peter Grimes is supposed to sail off until he loses sight of land, then sink his boat. The Borough's population is then meant to get on with their lives, essentially as if nothing much had happened. Curtain down, cue the applause. What we got, instead, was the music ending but the cast staying on stage swaying ridiculously from side to side with a giant net (see the thumbnail above), which made 'swooshing' sounds as it moved. This lasted an excruciating few minutes before the curtain finally descended and applause ensued. The swooshing sound was, of course, intended to sound like the sea (as some excited woman on the way out of the venue announced she had discerned). The trouble is that the sea is not meant to be a protagonist in the opera, with the last word. It's a character, of course, with varying moods, from thundering storm to twinkling sunlight on glittering waves. But it isn't the villain of the piece: that role is reserved to the people of the Borough whose conformity and resentfulness of difference and vision is what dooms Grimes. Theirs is supposed to be the last word: “Coastguard reports, there's a boat sinking out at sea… I see nothing… Just one of these rumours… move on”. If you detract from that conclusion, you lose the whole point of the opera: of the visionary dreamer against a constrained, conventional society; of the outsider against the indifferent crowd. Opera North comprehensively missed the point: we don't need nets sounding like the sea to conclude this opera. We just need the Borough to shrug its collective shoulders and get on with life, dismissive of the visionary it has just destroyed. The ending of the performance was as gormless as its opening, basically.

Another annoyance, too: at the end of the opera, Balstrode gives advice to Grimes to take his boat out until he loses sight of land, then sink it (and himself) to oblivion. It is meant to be an act of kindness, even of love: to spare Peter from the wrath of the Borough and relieve him of his pain and torment. It is meant to be said kindly and gently. Our Balstrode, however, decided to turn tail, lose patience, metaphorically roll his eyes and clearly couldn't wait to be rid of this Grimes fellow. Again, a total misreading of the opera, its meaning and intent.

I didn't like the staging much, either. When the libretto mentions “Grimes' hut”, you kind of expect “a hut”, not something that looked like a curtailed oil rig in the North Sea (see picture at the right). I'm prepared to suspend my disbelief quite willingly… but no man could live comfortably on a 12 foot square of timber in the upper atmosphere! Watching the new apprentice get hitched to a wire before falling off said platform was just excruciating. He's meant to walk out of a hut, leave the door open… and then we hear him scream as he falls down the cliff off-stage. There's neither reason nor point in making the poor lad do a leap in the centre of the stage, even with a harness laboriously attached. It just looked stupid.

I won't mention (OK, I will) the fact that there are really two big emotional fulcrums in the piece: the clash between Grimes and Ellen outside the Church on Sunday, and Grimes' mad scene. Unfortunately, the Nottingham audience wasn't playing ball for either key moment. During the outside-Church confrontation, a fellow in the rows behind me decided he was going to have some sort of epileptic fit. Which is absolutely fine: these things happen and my sympathies were definitely with him. Unfortunately, his fit took the form of rather loud and continuous moaning and instead of getting him out of the auditorium with all due haste and minimum fuss, this went on throughout the piece. Key moment #1 missed entirely. The lady in the row behind me then decided she would have a coughing fit throughout the Grimes mad scene. Again, I wouldn't have minded so much, except that she apologised to everyone around her in a rather loud stage whisper. Which was, perhaps, considerate… except that she then chose to round things off by getting out the throat sweets and unwrapping them throughout what remained of the mad scene. Key moment #2 thereby ruined.

I lay those misadventures at the feet of the idiotic public, not those of Opera North, of course. But the ham-fisted production of this opera is all their own doing and the less-than-stellar performances of Grimes and Aunty are equally of their own creation. Full marks to the chorus and orchestra, however… and extra marks to the Theatre Royal: it's a proper 'traditional' opera house, in green and gold, in the raked-box style of La Scala and with a most impressive chandelier! I had no idea Nottingham was blessed with such a beauty (and I lived there for six years!).

Overall, 7/10 for the orchestra, chorus and powerful Act 1. Points off for completely unnecessary and misguided prologue and epilogue 'pantomimes', the weak performances from two key singers and the (expected) dreadful behaviour of assorted members of the public. There are reasons I don't go to live performances of opera very often: this outing reminded me of what they are.

rethinking_support

Anonymous (anonymous@undisclosed.example.com) — 2025-12-12T20:19:23+00:00

Rethinking Support

I've been thinking for some time of revamping the support I offer for my three bits of software: there are simply too many distros to be testing all three on all of them! So instead, I've decided on a “tiered support” structure, allowing to focus my efforts on distros I actually use for real, on real hardware, and offering a lesser form of support for running on other distros that I only ever virtualise or have barely heard of.

Tier 1 will be comprehensively tested on real hardware, using distros I actually use for real every day.
Tier 2 will be tested for installation and basic functionality using only virtual hardware.
Tier 3 will not be tested usually, but if specific issues or bugs are raised with me via email, I'll spin up virtual machines on an ad-hoc basis and get issues sorted.
Tier 4 will not generally be tested at all. Things should work but you're basically on your own should issues ever arise.

Putting specific names to the various tiers, then, we have:

Tier 1: Full Support: AlmaLinux 9 and 10, Raspberry Pi OS, Fedora, Linux Mint
Tier 2: Partial Support: Debian, EndeavourOS, Ubuntu
Tier 3: Some Support: OpenSuse Leap & Tumbleweed, GeckoLinux, Arch, Manjaro, Garuda Linux, Devuan, Linux Mint Debian Edition, Peppermint OS, MX Linux, AntiX Linux, Pop! OS, Linux Lite, Zorin OS, Elementary OS, KDE Neon, Tuxedo OS, Nobara, Ultramarine
Tier 4: Unsupported: Windows, macOS

Two big casualties are apparent in this new plan: Arch and OpenSuse. Arch is just too fast-moving for me to keep up and is, in any case, never installed in standardised way, which makes supporting it practically impossible. OpenSuse is dropped as a tier 1 platform because it's peculiar and literally no-one I know of uses it as a desktop OS.

Ubuntu and Debian also take a bit of a hit: I loathe Ubuntu's use of snaps and several other features of its 'not invented here' approach to OS development; and Debian is probably a bit too slow-moving and out-of-date to be anyone's primary choice of desktop distro. Nevertheless, it's not that I won't test my software on them at all, but the tests won't be real-world, extensive usage tests. I'm also restricting myself from here out to testing on Long Term Support (LTS) editions of Ubuntu only. Currently, that means 22.04 and 24.04. Imminently, it will also include 26.04… but I won't support running anything on a xx.10 non-LTS release.

The numerous 'minor' distros that proliferate endlessly are all now in Tier 3. Distros like Peppermint Linux, MX Linux, Devuan, Pop! OS, Zorin, Tuxedo and Linux Mint Debian Edition and so on all get some sort of support because their parents (usually Ubuntu or Debian) are in more supported tiers above them. If I'm notified of specific bugs or irregularities in the operation of my software on such 'niche distros', I'll be more than happy to spin up a virtual machine and try to sort the issue out: but I won't generally or routinely test on these distros any more.

The move of Windows to Tier 4 status is occasioned by the end of official support for Windows 10 and the fact that I don't own any hardware that can officially run Windows 11 (and refuse to have a mandatory Microsoft account to use Windows 11 even if I had the hardware!) I know my software will run on these platforms, because if my software runs on 'real' Linux, it will run just fine on the same distros running under the Windows Subsystem for Linux… but I can't really support that platform if I can't myself run it in an officially supported manner. So Windows moves to the “it ought to work, good luck” tier! I'll certainly look at issues if they're brought to my attention, but it will be on a 'best effort' basis only.

On the plus side of the ledger, AlmaLinux gets tier 1 support: it's a free-of-cost clone of Red Hat Enterprise Server, so support for it also applies to Rocky Linux, which is another clone of the same thing. I use AlmaLinux 9 to run Niente and this website; I use AlmaLinux 10 in a virtual environment only. I'll do thorough testing on both versions, though. Raspberry Pi OS also gets tier 1 status because I now use a Pi 4 as my main music player PC and a Pi 3B+ as a secondary player in the summer house. I don't own a Pi 5 yet, so I can't claim things will definitely work on that platform, but they should do.

Fundamentally, then: I'll still offer help and support for running my stuff on any Linux distro. But there will now be just a handful of distros on which I guarantee things will work. There'll be a handful of distros where things have been tested enough to give me confidence things will work -but there might be some edge cases my testing misses. There'll then be a swathe of distros where ad hoc support will be available, but very little pre-release testing will have taken place. And then there's Windows!

Documentation updates will soon take place for Giocoso, Semplice and Niente to reflect this new approach.

Incidentally, the next version of Giocoso (version 3.32) is likely to be released around December 4th, a week earlier than anticipated: it's been in daily use here for a coupld of weeks and there have been no issues, so holding back an extra week seems a bit pointless. Watch this space, I guess…

rvw_journal_now_out

Anonymous (anonymous@undisclosed.example.com) — 2025-10-08T19:39:08+00:00

RVW Journal now out!

Just announcing that the latest edition of the Journal of the Ralph Vaughan Williams Society has been published and is available for purchase from the Society's website. It happens to have been edited by my own good self!

I encourage you to become a member of the Society, for the princely sum of £25.

semplice_version_2.12_released

Anonymous (anonymous@undisclosed.example.com) — 2026-02-04T16:44:10+00:00

Semplice Version 2.12 Released

I have today released the next version of Semplice, Version 2.12. The details are, as ever, in the Changelog but there are two big changes that deserve special mention.

First and most significantly: Semplice now installs on and is fully supported in Tier 1 fashion on macOS. It's been tested on everything from a 2012 Mac Mini running Catalina to a 2026 M4 iMac running Sequoia and Tahoe, so whether you're using Intel CPUs or Apple Silicon, it should all work as intended. There are two known issues regarding ripping CDs. First, macOS cannot detect a CD/DVD drive unless there's a disk inserted into it. Semplice on macOS cannot therefore 'poll' the CD drive to see when a disk is inserted because that drive doesn't even exist until after the disk is inserted! It's a minor issue, really, and simply means that you insert your CD before invoking Semplice's ripping options.

The second issue is a little more awkward: if your CD/DVD drive happens to be an Apple SuperDrive, Semplice cannot automatically determine the correct read offset to use when ripping to ensure accurate rips. That's down to Apple: multiple manufacturers made the internals of the SuperDrive, each with their own read offsets… but Apple deliberately obscures that manufacturer information when interrogating the drive. Accordingly, it's physically impossible to know what the correct offset to use for any particular SuperDrive should be. I worked around this for my own SuperDrive by plugging it into a Linux machine and getting Linux to reveal that it was made by LG: knowing that, I was able to check the AccurateRip database of known offsets manually and thus determine my offset should be '+6'. An alternative workaround would have been to use a non-SuperDrive device: Apple doesn't obscure the hardware identifiers for such third-party drives and thus Semplice can still accurately determine the correct read offset for them.

Anyway: I use Semplice everyday on my iMac to rip new CDs and tag-up previously ripped-but-not-yet-catalogued ones. It works perfectly well.

The second big new feature is support for ReplayGain. Semplice has always previously performed volume boosts by physically altering the data in the audio signal part of a FLAC. That sort of physical volume boost is based on peak loudness: find the loudest part of a FLAC (or a folder of FLACs) and find out how far away that peak loudness is from 'ideal, perfect, non-distorting maximum possible volume'. Then boost the volume of all FLACs in a folder by that amount: everything gets boosted by the same amount and everything ends up as loud as it possibly can be. All of that functionality remains untouched in the new version of Semplice: it is also still the default volume boosting mechanism. The trouble with it is that it alters the digital data contained inside a FLAC in an irreversible manner… and rather a lot of audiophiles don't like doing that sort of thing! It also requires, at least temporarily, at least twice the disk space and a lot of CPU, because the original FLACs need to be transcoded into new, volume-boosted files before the originals can be deleted. To deal with those sorts of issues, therefore, Semplice Version 2.12 now can be asked to do a 'metadata-only' volume boost. The FLACs are analysed as before… but instead of then altering the volume of the digital audio signal, a set of five metadata tags are written to the non-audio part of the FLACs. These tags contain data about the peak loudness of the FLACs and the amount by which they can be safely boosted. It's then up to your music player to read these tags and to apply that pre-computed volume boost in real time, during playback. Remove those tags and the playback will be back at the original, non-boosted volume: this sort of volume boost is thus completely reversible, is quick to compute (because no transcoding is required) and doesn't consume lots of CPU or disk space (because no transcoding is required!). This 'metadata volume boost' is actually something of an industry standard way of doing things and is called “ReplayGain”. Semplice, therefore, now supports computing ReplayGain and writing the tags necessary for players to apply it.

Whether your player can apply ReplayGain is a matter for you to sort out: Foobar2000 can apply it, but it needs to be told to do so. Other players behave similarly. My own Giocoso is being re-written to be able to do it when appropriately configured and should be released fairly soon.

There are all sorts of other, more minor, enhancements and bug fixes, of course. As I say, read the changelog for those details.

Updating to the latest version should be just a matter of taking the usual Miscellaneous menu, Option 3 and following the prompts. For obscure reasons, that may however end in a message that 'something went wrong with the downloads, try again later'. If that happens to you, then just quit Semplice completely and issue the following commands in a terminal session:

cd
rm -f seminst
wget software.bbritten.com/seminst
bash seminst

…and then follow the prompts. This is in fact a complete re-install of Semplice, which will always proceed without a problem.

Incidentally, the new version release is a couple of days later than anticipated, for which my apologies… but getting the software to run on a whole new platform, especially with the purchase of a new PC in the middle of that, using a completely new CPU architecture compared to anything else I've ever used, meant rather more testing was required than I'd anticipated. As I say, I'm sorry about that… but we got there in the end with only a couple of days of delay!

semplice_version_2.13_released

Anonymous (anonymous@undisclosed.example.com) — 2026-03-30T15:17:23+00:00

Semplice Version 2.13 Released

A little later than intended, but I've just released the new Version 2.13 of Semplice. It's quite a substantial release: the new graphical look and feel is perhaps the most obvious one, along with the ability to set the colours for the individual display elements of the program interface. Under the hood, some fairly significant bugs got squashed, too, however: the biggest ones are mostly to do with making Semplice a first-class citizen on a macOS installation. In particular, macOS's handling of Unicode characters that involve accents is, er… “unpredictable” and the new version of Semplice brings some order to the chaos! Full details, as always, are available from the Semplice Changelog.

This update is, unfortunately a 'breaking update', meaning that simply taking the Administration menu, Option 3 will certainly upgrade to the latest Semplice release, but it will look like a disaster when you're done and some important things will be missing (which won't be missing if you were doing a fresh install, by the way).

So, to ensure the unpleasantness is kept to a minimum, you need to do a bit more than just taking that 'check for program updates' menu option. The first thing you need to do (again, only if you're upgrading an existing Semplice installation) is to install some extra packages which are new dependencies that Semplice now has and didn't before:

Fedora: sudo dnf install libsixel libsixel-utils kitty
Mint: sudo apt install libsixel-bin kitty
AlmaLinux10: sudo dnf install kitty
Suse: sudo zypper install libsixel1 libsixel-utils kitty
Arch: sudo pacman -S kitty libsixel
Debian/Raspbian: sudo apt install libsixel-bin kitty
Ubuntu: sudo apt install libsixel-bin kitty

Once that new software is installed, you can proceed to do the standard Semplice upgrade procedure (i.e., take the Administration menu, Option 3 and supply the sudo password when prompted). The upgrade will appear to fail:

Don't worry about that: just press [Enter] or click OK to accept the message: you'll be returned to the main program screen, which will look ghastly:

Don't worry about this, either. Just take the Miscellaneous menu option once more, Option 1 to edit the configuration file and then keep pressing [Enter] to step through every page of options without changing anything. When you press [Enter] on the last page of the configuration options, you'll return to the main program menu and see this:

At this point, the only real problem remaining is the size of the 'grumpy Beethoven' logo, over on the right of the program display: go back into the Edit Configuration File option once more. On the last page, you'll find a set of four new configuration options:

Set the “size of the program logo” to something smaller or larger, depending on how things are appearing on your screen. Use the “program logo position” parameter to supply a negative (move left) or positive (move right) number to adjust the precise position of the logo. For my Fedora installation, I found a size of 110 and a position of 0 worked fine, but your mileage might vary:

Once the display looks fine, your upgrade is complete. I apologise for the fact that this upgrade is non-trivial and requires a bit of manual intervention on your part beforehand: I try to keep these 'breaking updates' to a minimum and I hope this will be the last one for a good long while!

Finally, note that on AlmaLinux, the terminal type that the Semplice launcher runs Semplice in cannot display graphics: that's why these instructions mentioned installing the Kitty terminal, which can display those graphics (this may be true for other distros, too). It is accordingly recommended that you use the Kitty terminal for all Semplice operations on that platform in future. If you want to adjust the program launcher so that it invokes Kitty automatically, you'll need to edit the appropriate launcher file. That's located in $HOME/.local/share/applications/semplice.desktop. So:

nano $HOME/.local/share/applications/semplice.desktop

Change the “Exec” line of the file. At the moment, it's reading something like:

Exec=/usr/bin/xterm -xrm 'xterm*iconHint: /home/hjr/.local/share/semplice2/art/sempliceico.xpm' -bg black -fg green -geometry 103x28 -fa 'Luxi Mono:style=Regular' -fs 11 -ti 340 -tn xterm-256color -e semplice2.sh

Change that to read (rather more simply!):

Exec=/usr/bin/kitty -e semplice2.sh

You may also want to configure Kitty generally to display things in a nicer fashion than it does by default. That's done by editing the $HOME/.config/kitty/kitty.conf file. My own is very, very simple:

font_family      family='Luxi Mono' postscript_name=LuxiMono
font_size 12.0

…but many more configuration options are available to anyone with time to invest in such things!

something_new_is_coming

Anonymous (anonymous@undisclosed.example.com) — 2025-10-02T15:28:41+00:00

Something new is coming

Just wanted to announce that I'm planning a complete re-vamp of the website, into something more performant, less cluttered, much smaller and quite a lot simpler to configure and maintain!

some_code_comments

Anonymous (anonymous@undisclosed.example.com) — 2025-10-04T20:03:14+00:00

Some Code Comments

This website's “sidebar” (it's main menu, effectively) will refresh every five minutes, because of this code it contains:

<script type="text/javascript">
(function() {
   window.onload = function() {
     setTimeout(function() {
        location.reload();
    }, 300000);
   };
})();
</script>

…which triggers a refresh every three hundred thousand milliseconds (which is therefore every three hundred seconds… or every five minutes).

The purpose of this auto-refresh is to ensure the 'currently playing…' icon more-or-less accurately reflects the music I'm actually listening to, rather than a recording I was listening to several hours ago. A manual selection of any of the sidebar menu items will also trigger a refresh and thereby 'reset the clock' for the auto-refresh functionality.

state_of_play

Anonymous (anonymous@undisclosed.example.com) — 2026-01-25T17:05:28+00:00

State of Play

A quick update on the state of things for this website and its transitioning over from ye olde AbsolutelyBaching website (it's been three months already!) There are at least a couple of bits of good news, on what sometimes seems to be a neverending journey!

First, the Semplice documentation is now fully across and completely updated, to the point that it's actually describing version 2.12 which isn't scheduled to be out for another week or so! Whether that release stays on schedule is a little bit up in the air: I have yet to check that the installation works on macOS and to document it if it does. If it slips past January 31st, it won't slip far.

Secondly, with Semplice documentation out of the way, I've at last made a start on bringing across the Bach Cantatas catalogue. There's an enormously long way to go, including copying across all the cantata translations I did several years ago… but at least the work has begun! The Mozart and Vivaldi catalogues will come across after that work is complete.

A new Giocoso update is also on its way, with the ability to do album-level ReplayGain, bringing it inline with what many other media players do already (such as Foobar2000): it's in daily use here at the moment, so should be good to go within a few weeks.

the_problem_of_portability

Anonymous (anonymous@undisclosed.example.com) — 2026-03-14T10:11:01+00:00

The Problem of Portability (Part 1)

I was getting ready to release version 3.36 of Giocoso yesterday: it contained a tiny, but significant bug fix, whereby anyone using a comma as a decimal delimiter (as they do in Europe, say), rather than a period/fullstop (as they do in the UK, for example) would have their music playback garbled when the new ReplayGain feature was in use:

The problem is that ReplayGain is invariably stored, by whatever tool that puts it there, in the form “-1.43”. Confronted with that decimal point, European Giocoso installations declare the ReplayGain value to be 'not a valid number' and do what you see above. A quick fix was thus implemented that forced the use of a decimal point delimiter, whatever a user's general PC's locale would say, and thus guarantee that a ReplayGain would be seen as a valid number, despite the '.' rather than the usual (for them) ','.

Anyway: as I say, that fix is “in” and ready to release… but a bit of mission creep, er… crept in and thus I've deferred the release of version 3.36 until late next week.

The mission creep is to do with a problem I've tried to tackle several times in the past: how do I get music playing on multiple devices around the house, essentially following me as I move about it?

Things started off nice and simply, after all: I have a PC in a drawer connected via optical out to a Douk DAC/Amplifier and a nice pair of speakers in my listening room. Since it's in a drawer, that PC is headless. I therefore tell it what to play by ssh'ing into it from my iMac desktop and tell it to start playing from there. Music comes out of the speakers, sourced from a NAS elsewhere in the house which the drawer PC has mounted. The iMac runs nothing itself but merely tells the 'drawer PC' what to do.

But now I move out into the conservatory. It's no good my 'drawer PC' playing anything now as it will play to the listening room speakers, not anything in the conservatory. I'm also not sitting at my iMac, so I can't really ssh into anything conveniently to initiate play. Previously, I got 'conservatory music' by fitting a little Raspberry Pi in there and attaching it to some speakers. With a small 7 inch monitor, I could log in to that Pi directly and launch Giocoso and start playing music, thanks to the Pi having an NFS connection to my music storage server.

This is not terribly scalable. If I now want to play music in my bedroom, I have an old laptop there, which is again NFS mounted to the music NAS, has Giocoso installed, and can be logged on to directly and I can therefore tell Giocoso to start playing music via the laptop speakers or (more usually at 1AM) via the BlueTooth headphones the laptop can connect to. I mean, it works… but it's three fat PCs, each with their own installation of Giocoso, each requiring direct access to start and stop playback. I at least invented Giocoso Pro so that whatever each of the three PCs did, there would be a single record of who played what, wherever the play took place. Giocoso Pro however makes no difference for the need for three independently-usable, fully-fledged PCs, complete with keyboard, mouse and monitor, in the first place.

The thing is, I have ready access to a device that could SSH into any and all of these PCs: my mobile phone. I could simply have three headless Raspberry Pi 3Bs in each room, each connected to the music NAS, each with Giocoso installed. Whip out my phone, ssh into whichever one I want to start playing music and… and then? Therein lies the perennial problem. Let me give you a clue as to what happens when I try that and launch Giocoso:

It reminds me of the Rosetta stone, only somewhat less translatable! You might just be able to pick out the standard Giocoso main menu: Play Music, Database Management and so on. But the rest of the display is just junk, for the simple reason that there's no Android or iPhone terminal emulator I know of that knows how to display sixel graphics properly. What you';re seeing here, therefore, is how a non-sixel-enabled terminal handles displaying the Giocoso program logo. The same thing happens if you start playing a recording and Giocoso tries to display its album art in-terminal.

Apart from the graphical glitch, the other problem with Giocoso on a phone is that phones are mostly portrait in orientation, whilst Giocoso is definitely a landscape kind of app: wide than it is tall! Hence, on this screenshot, you can see the one-line top bar menu has wrapped onto two lines. Phone screens just aren't wide enough!

It is, of course, for this reason that I invented mgiocoso ('m' for 'mobile'!): it was designed to be a 'portrait' app and it didn't display any graphics, so the terminal wouldn't fill up with nonsense:

Much better! Intelligible output, displaying what the main Giocoso running on the machine I've ssh'd into is already playing, and giving you the ability to pause, skip, terminate or repeat that play, too, all contained within the device you probably already carry with you everywhere. What's not to like?!

Well… you'll notice that you can't initiate play with mgiocoso. You can control an already-playing Giocoso session, but you can't start playback from your mobile device. In my three-room scenario earlier, therefore, I'm doomed to require a screen on each room's PC, or to access all of them from one PC with a screen, via ssh.

So the mission creep for Giocoso version 3.36 is this:

It's in portrait mode, so fits a mobile display. It doesn't have any graphics, so doesn't scramble a mobile display with hieroglyhics. And, drum roll please, it has a 'Play Music' menu option. This is the new Giocoso “mini-player”, which will be part of the next 3.36 release. It can run on a mobile phone, displays OK and will let you initiate playback. So, now I could have three headless PCs, each with access to the music NAS, each with Giocoso installed; I can ssh into each of them as needed, invoke giocoso-player.sh and then start music playing on whatever PC or Pi I've ssh'd into:

I don't see any album art, true enough: but I wouldn't want to on my mobile phone. I do at least get comprehensive data about what's playing and when it's due to end -and I still can control the playback to some extent, with options to Autostop, Terminate, Skip and Repeat available as they would be in a 'normal', full-fat Giocoso session.

The only slight fly in the ointment is that each of my PCs still has to be beefy enough to have an NFS mount capability, to have all the Giocoso dependency packages installed and to be able to run Giocoso (and ffmpeg) without glitching. The new mini-player mode gives me control via my mobile phone device, but it doesn't in itself alleviate the need for the PC its controlling to be reasonably powerful enough to play FLACs by itself.

Fixing that requirement is another bit of mission creep that has delayed the next Giocoso release a little… and I'll discuss it in some detail in Part 2 of this post, in a couple of days: for now, this post has gone on quite long enough!

the_problem_of_portability_part_2

Anonymous (anonymous@undisclosed.example.com) — 2026-03-15T13:04:02+00:00

The Problem of Portability (Part 2)

I wrote last time about a new feature in the about-to-be-released Version 3.36 of Giocoso: the ability to ssh into a machine that has Giocoso installed and then to initiate play of music (and subsequently to control it). This, essentially, gives us the following situation:

A person with a mobile device can ssh into multiple PCs, each running Giocoso and each with output available to speakers. Each of these 'playing PCs' is network-connected with NFS to the NAS box that contains my music collection: in this way, music can play in multiple rooms in the house. This is a first step to achieving “music portability” around the home: the ability to initiate music playback from an ssh connection is important to making this happen.

The drawback to this approach is one I’ve already hinted at: I have to ssh into each playing PC separately and each playing PC has to have enough compute resource to run Giocoso; each also has to have its own NFS connection to the music collection. Neither are particular intractable issues, but editing /etc/fstab to create a mounted NFS on multiple devices is a bit of a pain; and (especially of late) computers with screens, mouse, keyboard, RAM and decent CPU are not available at quite the bargain-basement prices they once were!

However, there is also the possibility of this sort of configuration:

In this model, we have someone using a phone to control a single PC or computing device (and I’ll come back to the distinction between those two things in a moment!). It's the only computer connected to the NAS; it's the only one with sufficient compute resources to be able to run Giocoso. It is, in fact, the only PC running Giocoso! Somehow, however, this one 'playing PC' is pushing its audio output to four remote PCs over the network: these devices are mere ‘receivers’ of music, not players of it themselves. A subtle point being made in this diagram, too, is that the four ‘receiving’ devices are pretty minimal: they don’t have a screen, keyboard or mouse. They don’t need a powerful CPU (because they’re passive receivers of a music signal, not generators of it) and they don’t need much RAM (ditto). They do need speakers attached to them, obviously: they’re no use to anyone if they can’t make the audio signal they receive actually sound out in the air! My drawing skills didn’t extend to actually showing those necessary speakers, but they’re there nonetheless

But this prompts the question: how can this configuration possibly work? How can a ‘music receiver’ that lacks the ability to itself run Giocoso nevertheless receive audio from that single PC controlled by mobile phone over ssh? From the opposite perspective, how can that one directly-controlled computing device push its audio data over the network?

The answer is PulseAudio. It does for audio what X11 does for graphics: separates the creator of something from the presenter of it. With X11, you have a program that wants to draw a form or document on a monitor running on one PC and a second PC that actually has a screen attached to it is able to render the depiction of that form. With PulseAudio, a similar division of labour can exist: the one PC connected to the NAS wants to generate audio and the four playing devices have audio hardware that can actually make that audio sound out into the physical world. The beauty of this is that the hardware needed to generate audio data only has to exist in one place; the playing devices can be very lightweight things because they're not actually doing the generating, just the 'sounding out' of a passively received audio signal. You could have an ancient computer running with 1GB RAM and an asthmatic CPU playing excellent quality music, provided only it's hooked up to a decent pair of speakers.

It is to facilitate this sort of 'distributed music playing' that the new feature in Giocoso Version 3.36 that I mentioned last time kicks in. As a reminder, the new feature is the Giocoso mini-player:

It runs on a computer that has full-blown Giocoso installed on it, but its program display is in portrait mode and limited in width, without graphics, so it runs perfectly on a mobile device that is merely connected to the Giocoso player PC via ssh.

The point this time, however, is to note the Option 1 and Option 2 menu items: these let you set up a number of PulseAudio ‘sinks’ and then select one or other of them as actively in use. Here’s what you see when you take Option 2, for example:

You’re allowed to create up to five ‘sinks’ on this screen: their labels are up to you, but must be less than 14 characters long (they’ll be truncated otherwise). Each label is then paired up to the IP address of the device to which the label applies. Those rather obviously need to be fixed IP addresses (or, at least, addresses with DHCP reservations) so that they don’t change after initial setup: Giocoso on the playing PC needs to be able to find it on the network so that the audio can be sent to the right place.

Once you’ve built a library of possible PulseAudio sinks in this way, you can take the mini-player’s Option 1 to select a particular one of them to send audio to:

The current audio ‘sink’ is marked with an asterisk; your job is to up and down arrow through the list of available sinks and press the Space Bar when you’re sitting on the item you want to use for the next play: that press of the Space Bar will make the asterisk jump to that item, indicating selection success. Press [Enter] to make the new selection ‘stick’. You’ll be returned to the main mini-player menu where, towards the bottom of the screen, you’ll see confirmation of the currently-selected PulseAudio server: if you then tap the ‘P’ option to play music, it’s this IP address to which music will be directed.

To be clear, for any of this to work, the persistent configuration parameter Force the use of PulseAudio must be set in full-fat Giocoso’s configuration settings:

If you haven’t set that parameter to “yes”, then specifying a PulseAudio server to play to simply doesn’t work: audio will ‘sound’ on the PC you’re directly connected to, assuming it has speakers to use! It should also be obvious, I hope, that this can only work if your player PC and the devices it sends audio to are all configured to use PulseAudio (or its cousin, PipeWire, which is essentially the same thing as far as these purposes are concerned). Most Linux distros ship with PulseAudio out-of-the-box and very little, if any, configuration is needed to make them players or sounders. MacOS can also act as a PulseAudio client and server, though things get much more complicated there: I’ll have specific documentation prepared for this topic shortly.

The little secret ingredient I haven’t mentioned until now, too, is that the box doing the Giocoso playing and sending its audio out to ‘sounding devices’ doesn’t have to be a big PC. There’s a reason it was drawn in that earlier diagram with this logo:

That is the official logo of the LXC or Linux Containers project. What is an LXC container? Well, it’s sort-of like a virtual machine, running on a Proxmox hypervisor, but incredibly minimal and lightweight: I have an Arch one configured to use just 2GB of RAM, 8GB of hard disk space and two virtual CPUs. It runs nothing much more than standard Giocoso, configured to use PulseAudio. I ssh into it and, using the mini-player interface, direct it’s audio output to whichever one of my minimalist room setups I need to hear music from at the time.

It is quite complicated to get an LXC container to connect to my music NAS; it is even more complicated to get an LXC container to ‘see’ the physical music playing hardware that the Proxmox host has. Documentation on getting all that working is in preparation, too.

I hasten to add that none of this affects how you use Giocoso if you don’t want it to! All my ‘serious’ music listening happens in my dedicated ‘listening room’: that contains a passively-cooled PC hidden away in a draw, physically connected via optical-out to a full-on DAC and amplifier. I ssh direct into that machine and run full-fat Giocoso on it from my iMac desktop: there’s no PulseAudio involved at all there… and I wouldn’t want it to be!

The new features in version 3.36 of Giocoso simply means that it’s now easier than ever to have less-serious listening follow me about the house, if I want it to: I ssh into the LXC container and direct its output via PulseAudio to the lightweight playing device in whatever room I’m working in at the time. In my garden shed, the playing device is literally a Raspberry Pi 3B playing wirelessly to a small Bluetooth speaker: I’m not expecting great hi-fi fidelity from that setup and sending audio via PulseAudio and Bluetooth therefore doesn’t degrade anything below my already-low expectations! It is enough, however, to have music follow me around the house at will… or, at least, at the touch of some keys on my mobile phone

this_is_pleasing

Anonymous (anonymous@undisclosed.example.com) — 2026-01-15T12:40:00+00:00

This is pleasing...

The thumbnail to the left, when clicked, will take you to a glorious screenshot of my macOS Monterey desktop, running the yet-to-be-released Version 2.12 of Semplice, busy ripping an SACD over the network from my ancient, crusty but entirely functional Sony BDP-S490 Blu-ray player (as per this article). It's nice it's working at all; that it's doing so on macOS, an operating system I have practically zero experience with, is even nicer.

It happens that this is one of the last bits of functional testing I'm doing before the release of the new version of Semplice, which was scheduled for January 31st. Release seems to be a little bit more imminent than that, though, unless I stumble across new bugs not hitherto unearthed by my extensive testing over the Christmas and New Year breaks.

Stay tuned!

whisper_it_quietly

Anonymous (anonymous@undisclosed.example.com) — 2025-12-12T20:18:49+00:00

Whisper it quietly...

Seasoned visitors to my website, under whatever domain name it inhabits, will know my love of Linux and my loathing of all things Windows and Apple. Don't click on the thumbnail to this blog post, therefore, unless you are sitting down with a bottle of smelling salts handy.

I am a creature of impulse, sometimes, and when I was up in the loft getting down the Christmas decorations for this year's outing, I spotted a 2015 21.5“ iMac sitting forlornly in a spiderweb-encrusted corner and thought… why not? So down it came too, and its Debian installation was wiped and the machine restored to its El Capitan original OS, swiftly updated to the latest officially-supported release of Monterey. It looks nice enough: in fact, the retina screen makes text look gorgeous though twenty one and a half inches of screen real estate seems somewhat underwhelming. It's not a bad computer, though: i5 at 3.1GHz and 16GB RAM are decent enough. It's real drawback is the spinning rust hard disk that makes everything quite slow to load: an upgrade to an SSD would certainly improve things on that score. The star of the show is undoubtedly the retina screen, which makes text look stunning, as previously mentioned. I still find MacOS a complete mystery, though: perhaps unsurprisingly, as I must have spent at most… 16 hours or so using it in my entire life.

Anyway, a few years ago, I made Giocoso Version 2 run on MacOS for some reason or other that I now can't recall: I never bothered trying to get Giocoso Version 3 to run on it, however. The thumbnail to this post tells you, however, that after a day or so spent futzing around with things, I have been able to get Giocoso Version 3.32 (the one due to be released early in December 2025) running on it. I don't entirely know whether it is worth having done so, as everyone who loves Apple will have long since moved on from Intel Macs to the Apple Silicon variety that I don't possess (and am unlikely ever to do so). But the job is done anyway: impulse is like that sometimes!

This may delay the release of Version 3.32 a little: I mentioned last time that I was thinking of releasing it a week earlier than its planned December 10th release date… but the code changes I've implemented to get things on MacOS now need testing back on Linux, to make sure I didn't break anything there. So I think the release date reverts back to December 10th after all. All zero of the thousands not clamouring to run Giocoso on their Macs will be grateful, I suppose!

with_apologies

Anonymous (anonymous@undisclosed.example.com) — 2025-10-15T20:34:34+00:00

With apologies...

I started this morning with an innocent desire to learn how to host two domain names from the one server (I know how to do it with Apache and Wordpress, but I'm not using that technology stack any more). One thing lead to another and by lunchtime, I had literally re-directed absolutelybaching.com to bbritten.com, even though bbritten.com is running on spare hardware that's as powerful as an asthmatic ant. Basically, I hadn't meant to switch the domains around, but ended up doing so anyway: my enthusiasm got the better of me!

There will be quite a few weeks before I finally bring over all the content I intend to transfer to the new site. I'm afraid things will look rather unfinished and rough-and-ready until that process is complete.