A Voyage Around My Ears
Anyone paying attention to my listing of music I’ve been playing at home will have noticed that after playing at least half a dozen pieces a day (and often double that), I suddenly played nothing at all on 20th March and only managed a single play on 21st March, quite late in the evening.
I’m blaming Covid-19! Specifically, I was fortunate enough to receive my first dose of the Oxford-AstraZeneca vaccine on the Friday 19th March. The jab happened around 3.30pm, so quite late in
I have been aware for quite some time that, occasionally, plays of music made by AMP would not get recorded in the PLAYS table as they should. It’s difficult to know precisely why: when you’re developing the code and saving changes to the script as it’s playing something, it could well be that your editing has caused the ‘record in PLAYS’ bit of code to get skipped.
Or it could be a locking issue. Putting it at its simplest, databases cannot have one person modifying data whilst simultaneously allowing a second person to read that data. If I am in the process of withdrawing £5000 from my bank account just as a credit check is being performed, do we let the credit agency see the £5000 in the account? Or do we see it missing the £5000, even though I might be about to type ‘Cancel’ at the ATM? To resolve these data concurrency issues, all databases implement a form of ‘locking’: if I am going to withdraw money from my account, we lock the data until my withdrawal is complete, so that no-one can see it, either with or without the £5000, then when I’m finished at the ATM, we unlock and people can read the definite results.
The database which AMP uses has a fairly crude locking mechanism, whereby a ‘write of data’ blocks a ‘reader of data’… and (potentially) vice versa, in precisely this way. So if I’m simply querying the data in the PLAYS table, that would potentially prevent AMP from being able to record a new ‘play’ in the PLAYS table… and that might explain the occasionally ‘missing’ records I’ve noticed over time. (The timing of reads/writes would have to be quite precise to encounter the issue, but it’s a plausible explanation for most of my missing ‘PLAYS’, I think).
Fortunately, there’s a fix, though it’s a bit database-technical! Instead of writing a new play directly into the PLAYS table, you could get an application to write the new PLAY record into a special sort of log -a log which is never directly read or queried, so no-one’s going to be locking it: the write will therefore always take place, guaranteed. At a time the database thinks propitious, it will transfer the records from this log into the actual PLAYS table -and, because the database decided when to do this, it is also guaranteed not to block or fail because of someone querying the table. This mode of operation is called ‘Write Ahead Logging’ -or, more colloquially, ‘running your database in WAL mode’. It is not SQLite’s default mode of operation… and the AMP database therefore doesn’t run in WAL mode by default either.
So, the latest release of AMP comes with yet another run-time switch: ––setwalmode. It needs to be used together with the ––dbname parameter, otherwise we won’t know what database you mean to put into WAL mode (or, rather, we’ll assume it’s called ‘music’ if you insist on not mentioning a database name at all!). In my case, I run everything out of a database called “main”, so I need to type this:
amp --dbname=main --setwalmode
… and that will switch my AMP database into running in WAL mode. When AMP sees this new switch, it will check if the database is already in WAL mode (and warn you politely if so, before quitting without having done anything). If it isn’t, it will switch it into WAL mode -which is a one-time, set-and-forget process. No data is harmed in the conversion process, which takes mere seconds to complete. Once it has been converted, the AMP program quits and you can relaunch it more normally with whatever combination of commands you usually use to get it to play music. The difference won’t be noticeable to anyone, particularly, but it should mean that your database is protected against extraneous locking problems in the future.
It’s a very technical increment in functionality, in other words, but quite an important one. If you choose not to run your database in WAL mode (or to convert it to run in that mode), AMP will not complain or warn you about it. It’s just something I now encourage you to do to ensure there are no locking issues arising in the future.
I will mention in passing, too, a second new feature added in the current release of AMP: ––reportexport. You may have noticed the website has recently acquired a new page of text-based music listening listings. Did you stop to wonder where the data for that page comes from? Well, it comes out of AMP! The report of ‘plays’ which AMP has always allowed you to generate and view on-screen can now be exported to an external pipe-delimited text fie, thanks to the new ––reportexport parameter, which takes a path/filename value. So, for example:
amp --dbname=main --report --reportexport=/home/hjr/Desktop/myplays.txt
That command will return with a ‘report written successfully’ message after mere seconds, and the output (if opened in a text editor) might look something like this:
PLAYDAY|PLAYTIME|ARTIST|ALBUM|GENRE|DURATION 2021-01-09|16:48|Olivier Messiaen|Thème et variations (Loriod - 1977)|Chamber|00:12:17 2021-01-09|17:00|Gregorio Lambranzi|Dances from the School of Gregorio Lambranzi (Ball - 1980)|Orchestral|00:09:47 2021-01-09|18:13|Giacomo Antonio Perti|Gesù al Sepolcro (Vartolo - 1990)|Oratorio|01:12:29 2021-01-09|19:23|Johann
Thanks to another recent video by David Hurwitz, I was finally persuaded to bite the bullet and splash out on the complete Domenico Scarlatti keyboard sonatas as performed by Scott Ross (the album artwork of which appears off to the left). It’s a 34-CD collection, available for purchase from Presto Classical at only around £2.50 a box, which seems reasonable value to me.
Curiously, this collection of works has previously been discussed by me in
This is yet another story about AMP (my ever-evolving music player) being updated. This one, however, has a subtle twist that most of you probably won’t care about, let alone make use of.
It’s all to do with colour. In all my software, I try to use just four colours in a consistent way: (1) Terminal Default Foreground; (2) Bright Red; (3) Bright Yellow; and (4) Bright Blue. The terminal default will depend on what colour scheme you’ve configured your terminal to use. Commonly, as in the screenshot on the left, it’s bright green for me and my desktops. It’s used to display fairly ‘static informational’ text: things like the program name, the data labels and so on. Bright Red is used to display error or out-of-condition messages or alerts to program behaviours. Bright yellow is used to display user-input or fairly static information derived from user input (such as the folder path/name from which you’re currently playing music). Finally, Bright Blue is used to display fairly dynamic text derived from user input (the name of the database you’re using, for example, or any override switches you’ve specified that affects what music will be selected for play). I may not always be entirely consistent with the way I use my colours, but that’s the general scheme I try to use and stick to, anyway!
Unless you’re colour-blind, in which case, Lord alone knows what you will perceive the colour of any given piece of displayed text to be, if you can see it at all!
As it happens, I have my own colour-perception problems: if something is in C major, I see it (and feel it) as dark blue; in A major, it’s bright yellow; in G major, it’s a sort-of rusty red. It’s all a bit weird, frankly! Anyway, I also know that there are people out there who are more ‘conventionally’ colour-blind, in which case coding things to display in red and green, or blue and green, is probably less than helpful! So, I’ve added a new run-time switch to AMP (which bumps to version 1.17 in consequence): ––colour-light. For our American cousins, it can also be supplied as ––color-light, but really: Noah Webster should have been drowned at birth! Anyway, if that switch appears on the command line, anywhere, however it’s spelled, then the program display will be as you see it in the linked thumbnail: the green comes from whatever your choice of terminal colour scheme deems to be ‘normal’; everything else will appear as ‘white’.
There’s an additional option for those occasions where you prefer a light-themed terminal and thus displaying everything in white-on-light would not make best sense! For fans of light-coloured terminals, there is thus an equivalent new switch: ––colour-dark (which also comes in the American variant ––color-dark). If you use this dark-themed variant, all text will appear in black, not white. Something like this, then:
Finally, there’s the ––colour-neutral option (and it’s American cousin ––color-neutral), which basically makes things look like this:
…where all text will appear in bright yellow, unless it’s normal, static text provided by the program -in which case, it will appear in whatever colour ‘normal’ is defined by your terminal theme (in the above case, it would seem that ‘white’ is normal).
You may need to experiment with your terminal colour and profile appearance settings to get the desired effect, but at least you have a little more control over the appearance of things than you had before. If it’s not sufficiently flexible, you can email me and request some specific outcome and if I can make it happen, I certainly will do my best to do so. Obviously, by reducing the colour palette in these ways, you remove the ‘subtlety’ of the classes of information I alluded to at the start. No longer will you be prompted to spot the difference between mostly-static v. dynamically-derived information. But I figure it is probably better that all the program text is basically legible rather than that, in trying to convey subtlety, it becomes invisible to some people.
If you don’t have any colour perception issues, feel free to ignore the new switches: everything will simply continue to display in green, yellow, red and blue as necessary! A similar colour-changing capability has been added to all my other software scripts, too, and they’ve all incremented upwards in the version number stakes in consequence. Fresh updates for all of them are, of course, available from the usual software download page, so make sure you pick up the new capability whenever you can!
Even if you don’t have colour perception problems, you may also want the new upgrades, however, since there are a couple of bug fixes and display enhancements in most programs. Sticking purely to AMP-related news, for example, there is a new twist on the reporting capability AMP has had, almost since the first day it was written: you can now specify the number of days’ data to fetch and display. In my case, for example, if I simply say:
amp --report --dbname=main
…I will see this sort of response:
PLAYTIME ARTIST ALBUM GENRE DURATION ----------------- ----------------------------------- -------------------------------------------------------------------------------- ----------------------
For no particular reason, other than wanting to post something that didn’t involve a new update to some software script or other, I would like to take this opportunity to share with you all the latest picture of Harper, my cat. He was a rescue cat -though the pound wouldn’t tell us why and what he was rescued from. He did have an aversion to feet for a long time, though, so we figured he might have been the victim of some injudicious kicks in his time. I called him Harper because of
Another round of software tweaks and twiddles -mostly minor, some a little more significant.
First, AMP has been bumped a couple of notches to 1.16. It’s mostly to do with a few colour tweaks, but also an annoying bug dealing with distros that don’t have the ‘bc’ utility installed by default. Those should all now work fine (so that’s OpenSuse, Endeavour OS,
The world of open source software can sometimes be confusing, because if someone likes your code, they can take it and ‘fork’ it -that is, essentially, copy it and declare it to
Today has been fun, in an up-and-down and terrifying sort of way!
First the good news: I finally managed to build a pure Arch-based virtual machine with no slip-ups, mistakes or catastrophes. Installing Arch is never for the faint-hearted and I’ve done it lots of times in the past… but never done it ‘quite right’, with always something missing or not-quite-working! I accordingly long ago gave up hope of ever achieving something that seemed stable and functional. But
A correspondent from the west coast of the USA recently got in touch to say that whilst he enjoyed using some of my music-related software, he regretted having to point out that the code didn’t run properly on his Raspberry Pi running the Raspbian Linux distro …but that he’d hacked a way to get it to work anyway.
A couple of thoughts came to mind when I read that. First, the grumpy-me thought
Today, I’m releasing another new version of AMP (this one is version 1.12) with a slightly-tweaked ability to use override switches to control the randomness of what gets played.
Specifically, version 1.09 introduced the ability to specify a ––genre= OR a ––composer= switch to force AMP to randomly select a work that falls into a specific genre, or that was written by a specific composer.
The new version 1.12
You will perhaps have noticed a dramatic change to the ‘look and feel’ of the website: the result of getting bored with what had been the look-and-feel for nearly 2 years, I’m afraid! I’ve gone minimal and, I hope, more ‘punchy’ and easier to read in consequence.
There may be a few colour/font tweaks and twiddles in the days and weeks to come, but I think most of the disruption is done and dusted.
The second (quite big) change is that the site has now acquired
Another week, another new version of the Absolutely Baching Music Player (AMP to its friends). We move from 1.10 to 1.11… and the new release contains two basic new features being introduced!
First, a new run-time parameter is provided called ––artsize=xxx. The ‘xxx’ values permitted are ‘small’, ‘medium’ and ‘large’, with ‘medium’ being the default if the parameter is not supplied at all, or if