Giocoso: What's New?

1.0 Introduction

Giocoso version 2 is a major update to the original Giocoso classical music playing program, with dozens of new and changed features compared to the original version 1. Chief amongst these, perhaps, are the ability to run on macOS natively and Windows 10 via WSL2; the fact that all selection filters are now usable in any combination; and a persistent configuration file. There are also a number of features that have been dropped since version 1, plus a pile of bug fixes! On this page, I'll summarise each of these classes of change below. Where appropriate, I'll link to full documentation on the relevant features. Anyone that has used Giocoso version 1 will be immediately comfortable with version 2: the changes have not fundamentally altered the way things work!

For a changelog describing modifications to Giocoso version 2 since its first release, please see this separate page.

2.0 New Features

Support for running on macOSGiocoso now runs on macOS Sierra up to macOS Monterey. It has not been tested on the new macOS Ventura.
Support for running on Windows 10Giocoso now runs on Windows 10, thanks to the Windows Subsystem for Linux (version 2). That permits Windows to run a full-blown Linux environment 'within' Windows. Giocoso runs within that Linux environment.
Limited support for running on Windows 11Giocoso now also runs well on Windows 11. It's actually simpler to run it on Windows 11 than on Windows 10, because of improvements to the Windows Subsystem for Linux that Microsoft has made in that version of Windows. However, Windows 11 also requires modern hardware to be supported and I don't own any such hardware! Accordingly, though it runs fine, I'm declaring 'limited' support for Giocoso on Windows 11, simply because I can't promise to be able to replicate any issues someone running on 'proper' Windows 11 hardware might encounter.
Support for running on multiple new Linux distros In addition to the original distros that Giocoso version 1 ran on, Giocoso version 2 now runs on the following new Linux distros: Garuda, Devuan, Linux Mint Debian Edition, antiX, Peppermint, Gecko, Zorin, Elementary, LiteOS. Given the recent releases of Fedora 36 and Ubuntu 22.04, Giocoso has been checked as running fine on those two distros, too. Giocoso continues to run on Arch, OpenSuse Tumbleweed, MX, Debian, Manjaro, Solus, Endeavour OS, Linux Mint, Pop!_OS, Raspbian, Manjaro on Raspberry Pi and Ubuntu on Raspberry Pi.
A new Persistent Configuration File.There are now over 40 double-hyphen (runtime) parameters used to fine-tune the way Giocoso works. Typing that many things out every time you want to play a bit of music is clearly impractical. Giocoso now uses a persistent configuration file to store common parameters with 'permanent' values, so that the equivalent runtime parameters don't need to be supplied to have an effect. If you need to temporarily over-ride the persistent configuration file setting, the equivalent runtime parameter can still be supplied and will take precedence.
A new --debug runtime parameterIt can sometimes prove difficult to understand why Giocoso has selected a piece of music for play, or has failed to do so. A new --debug runtime parameter exposes all the variables and SQL statements that Giocoso uses, thereby exposing the 'internal state' of the program just before it starts playing something.
A new low-precision timerIn Giocoso version 1, a high-precision timer was used to calculate and display a 'time remaining countdown' when playing music. That was (as the name implies!) highly precise... but at the significant cost of high CPU usage. A new persistent configuration file parameter (TIMER_PRECISION) can now be set to a value of low, thereby reducing CPU consumption by around 75%, without noticeably impacting the functionality of the countdown timer.
Multiple independent filtering and searching parametersIn Giocoso version 1, you could do a combination search for composer+genre, but that was the only combination search allowed. In Giocoso version 2, you can now use the --composer, --comment, --composition, --performer and --genre runtime parameters in any combination you like. Similarly, the --unplayed and --unplayedworks now work in combination with those other selective runtime parameters (in Giocoso version 1, they over-rode all other parameters).
A new --editconf runtime parameterThe new persistent configuration file is a text file and can be edited by any desired text editor. As a convenience however, if you launch Giocoso with the new --editconf runtime parameter, you can directly edit the configuration file in whatever text editor is set as your system's default text editor (as specified by the EDITOR environment variable).
Precise positioning of the Album Art panelIn Giocoso version 1, you could only fix the location of the album art display window if you were running KDE and used KDE's special window location settings. If you were running any other desktop environment, you were out of luck. New in Giocoso version 2, however, are the SCREENWIDTH and SCREENHEIGHT persistent configuration parameters. By adjusting these parameters, you can precisely locate the album art display window anywhere you like, regardless of what desktop environment you're using. This also means Giocoso now supports running on 3+ monitor setups.
Better choice of album art caption coloursWhenever album art is displayed, Giocoso always creates a 'caption' underneath it, so that the precise composition being played can be easily seen. The background colour of that caption panel is now able to be determined by a real-time analysis of the colours used in the original album art itself. This is triggered by using the new --smartcolour runtime parameter (or the SMARTCOLOUR=Yes persistent configuration file parameter).
A choice of caption fontIt is now possible to specify CAPTIONFONT=xxxx in the persistent configuration file and have Giocoso use that when displaying the caption panel underneath the album art display window, rather than the default Dejavu Serif font.
Adjusted album art positioning for systems with docksA new runtime parameter --withdock (or a persistent configuration file equivalent) can be set to nudge the album art window upwards by 42 pixels, for those systems where a dock runs along the bottom of the monitor screen and threatens to obscure the album art.
Re-display of closed artwork now possibleIn Giocoso version 1, once you closed the album art window, that was it: you couldn't re-open it at all, and you'd have to wait for the next recording to play before the window would appear again (displaying new artwork, of course). Giocoso version 2 now lets you run the command "giocoso --artwork" from a second terminal session and that will trigger the re-opening of the original album art window.
Skipping a recording is now possibleYou can now issue the command "giocoso --skip" in a second terminal session to trigger the original, music-playing session to immediately terminate what it is playing and move on to a new recording (assuming that --selections was set to a number that permits Giocoso to play multiple recordings one after the other in the first place).
Manually-constructed playlists are now possibleIf you create a text file that lists, one folder per line, a bunch of folders that contain FLAC music files, you can point Giocoso at that text file and have it play that music selection in order. The new --playlist runtime parameter takes as its argument the full path and file name of the text file.
Direct Plays can be recorded in a databaseDirect play mode is what happens when you run Giocoso without a 'source' database to tell it where to find music files on disk. In Giocoso version 1, if you ran without a source database, but instead navigated directly to a folder of music files, there was inevitably no database in which you could record the fact that you had just direct-played the music in that folder. In Giocoso version 2, you can now do direct plays with a new --destdb=xxxx runtime parameter and have the fact of such plays recorded in that database. This means the Giocoso database can record all music plays it performs, not just those that are sourced from itself.

3.0 Changed Features

The --edit runtime parameter is now --editxTo help distinguish between the in-place editing of the persistent configuration file from the in-place editing of the excludes.txt file, the old version 1 parameter --edit is now --editx (the 'x' is meant to suggest 'the excludes file'). The functionality is no different; it's purely that the parameter has acquired an extra character.
The program's logo has been changedThe little logo at the top of the main Giocoso program window didn't display very well on macOS (because that operating system does Unicode extended characters in a different way than is used in Linux). A new 'musical notes' logo should display on all platforms equally well, provided only your terminal font supports Unicode characters at all.
Program play modes have been re- and more consistently namedThe 'boilerplate' text displayed at the top of the Giocoso program window mentioned 'Direct Folder Play' when launched without a database and 'Randomised Play' when launched with a database. Those terms were rather misleading (as a database can be used to do directed, non-random play). The terminology and text has therefore been changed to better reflect reality: Direct Play Mode means you're telling Giocoso directly and specifically what to play and where to find it on disk; Database Play Mode means Giocoso uses a backing database to tell it what music exists and where on disk it can be found.
Inverted duration limits no longer trigger program exitIf you specify --maxduration=10 and minduration=40, you're asking Giocoso to find and play something that is no longer than 10 minutes in length, but which is simultaneously at least 40 minutes in length. Giocoso version 1 would have thrown an error at that logical absurdity. Giocoso version 2 inverts the parameters so that they make logical sense: in this specific case, it will try to find music which is anywhere between 10 and 40 minutes in duration.
Database Play Mode is now the defaultGiocoso version 2 now assumes that you will use a database to source your music and therefore Database Play Mode is the default mode of program operation. Direct Play Mode must therefore be explicitly invoked by launching Giocoso with a --dbname=none runtime parameter. If you don't say 'none' for the database name, Giocoso will assume a database called 'music' is intended to be used. The non-existence of such a database will therefore trigger a launch error.
How long Giocoso searches for music is now configurableIf you supply lots of selection parameters (composer=this, composition=that, duration=something else, performer=someone else again, etc) then Giocoso may not find a matching piece of music the first time it looks for one (because it looks randomly and therefore might get unlucky). In Giocoso version 1 there was a hard limit of 50 searches before the program would give up trying to find a match. In Giocoso version 2, the MAXSEARCH persistent configuration parameter now allows you to specify any limit you like. The parameter defaults to searching every single recording that's mentioned in the Giocoso database, which might be way too high -and hence take way too long to complete- for a large music collection. It's up to you, therefore, to balance convenience and speed of getting results against the comprehensiveness of the search for matching music.
Performance improvements by better indexing in the databaseThis is a somewhat technical change that probably won't be noticeable to anyone, but the Giocoso database has undergone significant revision in the way its indexes have been designed, with the intention of speeding up performance when trying to find music that meets various selection criteria. This comes at a cost: the database has effectively doubled in size, but the database cataloguing my own 15,000 recordings (and 2TB of disk space) is still only 23MB big, so it's still comparatively tiny. Note that the change to indexes is handled automatically as you upgrade to version 2 from version 1: the database remains compatible between both versions.
Reporting time periods are now better definedIn Giocoso version 1, --reportdays=10 would mean 'report on plays which have taken place in the past 10x24 hour period'. If you ran the report at 6pm on (say) the 30th June, your report would have listed plays from the 20th June onwards -but only from after 6pm on the 20th June. Giocoso version 2 now no longer cares when you are running the report: it counts back 10 whole days (in this example) and then lists all plays which took place on that day and onwards. A Giocoso version 2 report done at 6pm on 30th June will therefore list a play that took place at 8AM on 20th June.
Reporting on recordings is now more flexibleIn Giocoso version 1, the --recordinglist runtime parameter took no arguments. In Giocoso version 2, it now takes 'screen' or 'path/filename' arguments, just as the --report parameter always has done. Thus, reports on what recordings exist in your music collection (whether or not you've ever played them) can be produced as proper pipe-delimited text files, for subsequent import and analysis in your favourite spreadsheet program.
The location of the configuration file needed to scrobble has changed.Giocoso version 1 stored its authentication credentials in $HOME/.config/giocoso-scrobbler/giocoso-scrobbler.conf. Giocoso version 2 now expects to find those same credentials in $HOME/.local/share/giocoso. This makes no practical difference to anyone running Giocoso for the first time. Anyone upgrading from version 1 to version 2 needs to copy (or move) that giocoso-scrobbler.conf file to $HOME/.local/share/giocoso to permit continued scrobbling in the new version.

4.0 Removed Features

Giocoso no longer runs on openSUSE 15.x LeapGiocoso version 2 uses a number of features that were introduced with Bash version 5, but openSUSE Leap 15.x only ships with and uses Bash version 4. Therefore, support for running Giocoso on that distro has been removed. Giocoso still runs very well on openSUSE Tumbleweed, since that's a rolling distro and thus generally uses the latest versions of software packages -including Bash.
The --register runtime parameter no longer existsThe --register runtime parameter has been removed, largely on the grounds that no-one ever bothered to use it. It was a 100% optional way to email details of what distro you were running Giocoso on, so I could more sensibly focus my development efforts. But (understandably), people don't like registering things, even when it's free, optional and non-binding in any way to do so. So that runtime switch has gone, and if you'd nevertheless still like to let me know what sort of hardware platform and distro you're running on, you can just email me the details.
The --integrate runtime parameter no longer existsThe --integrate runtime parameter created various configuration files that more closely integrated Giocoso version 1 into the Desktop Environment manager on Linux, provided you were running KDE (because KDE offers that sort of functionality in a way that Gnome or XFCE, for example, don't). Since the world and his dog don't use KDE exclusively, it was a feature of limited use and building that sort of functionality into the core application seemed misguided. The functionality has been completely removed in Giocoso version 2, therefore.
The --captiontext and --captionbackground runtime parameters no longer exist There have been several mechanisms used at different times to get Giocoso to colour the background to the 'caption panel', shown underneath album art whenever that's displayed. The --captiontext runtime parameter let you pick the colour of the caption text used in that panel; the --captionbackground runtime parameter let you pick the background colour of that panel. The two parameters required you to know the exact colour name, of which there were over 600 to choose from, and was really far too fiddly for mere mortals to work with reliably. They have accordingly been abolished. The caption panel is now adequately coloured by either the --autocolour or --smartcolour runtime parameters (or their persistent configuration file cousins).
The --listcolours runtime parameter no longer existsThe runtime parameter that let you see all the 600 colour names you could set --captiontext and --captionbackground to is not really needed once you can't use either of those two parameter... so --listcolours has been abolished, too.
The --colourcombo runtime parameter no longer existsThe --colourcombo parameter was used to colour the caption panel in one of eight possible preset colours, with names based on properties found on the UK Monopoly® board game. This has now been removed in version 2, largely because different countries use different property names for the same board game, so insisting on the UK version names was somewhat parochial. The other reason for the parameter's removal is that --autocolour still uses Monopoly® board colour schemes, but without needing to know any property names.
The --negate runtime parameter no longer existsIn Giocoso version 1, you inverted the sense of a selection parameter by adding --negate to the command used to launch Giocoso. If you said "--composer=haydn --negate", you meant "play me music by anyone other than Haydn", but if you had more than one selection parameter, you could only negate both or none, not one or other. You couldn't, for example, say "--composer=haydn --composition=mass --negate" to mean "play me anything by Haydn that isn't a mass", because the --negate applied to both selection criteria. You thus ended up saying "play me something that is not by Haydn and isn't a mass". This is way too inflexible and restrictive and thus has been replaced by adding an "@" symbol to the end of any selection parameter you like. In Giocoso version 2, therefore, you can say "--composer=haydn --composition=mass@" and mean 'play me something by Haydn, so long as it's not a mass'. With the use of the '@' character to signify negation, there is thus no need for a separate --negate parameter.
The --reporttype runtime parameter no longer existsGiocoso version 1 let you output reports on a full or differential basis, and --reporttype was used to specify which. This feature has been removed from Giocoso version 2. Differential reporting meant only listing those records not previously listed, which required an update to the database to record what records had been previously listed. After due consideration, it was concluded that (a) updating a database in any fashion when doing mere reporting is not a good idea; and (b) the functional usefulness of differential reporting are probably minimal. Once you have a few hundred plays to report on, it's probably best to export them all to a spreadsheet and do your filtering and so on there, anyway: the right tool for the job, basically, is not your music player!

5.0 Bug Fixes

Lack of ImageMagick prevented program displayIn Giocoso version 1, ImageMagick was required for the display of album art, but installing it wasn't actually insisted upon, as displaying album art wasn't considered core functionality for a music player. It was thus perfectly OK to install Giocoso and not have ImageMagick present on the system. Unfortunately, the absence of ImageMagick would then incorrectly stop the details of the music that was being played from being displayed. This is now fixed in two ways: Giocoso always displays music details correctly, and there is no dependency on ImageMagick to be able to do so. The second 'fix' was to bow to the inevitable and finally insist on ImageMagick being installed: Giocoso now checks for it when first run and prompts to install it if it's found to be absent.
ImageMagick can now generate captions without requiring security downgradesIn this blog post, I described an issue whereby some Linux distros implemented baked-in security policies that prevented programs reading the contents of text files. This was specifically a problem for ImageMagick, because it wanted to read a text file containing the composer and composition name of the music being played so as to construct the 'caption panel' underneath the album art display. The workaround described in that blog post was to downgrade those baked-in security policies, so that ImageMagick would be able to read from a text file. That was obviously a fairly undesirable thing to do. New in Giocoso version 2, ImageMagick now generates the caption panel text direct from values stored in temporary variables, without the need to access text files on disk. The caption panel therefore now works correctly without downgrading basic system security.
Giocoso on Fedora prompted for the wrong program nameWhen run on Fedora, Giocoso tests for the presence of a package called 'sqlite3', which is the package that makes the Giocoso database functional. If it found that package missing, it would have prompted for the installation of 'sqlite3'. Unfortunately, whilst the executable is called 'sqlite3', the package you install to get that executable is just called 'sqlite'. Giocoso would therefore have prompted you to install an incorrectly-named package ...and the installation command it offers you would therefore have failed. This actually wasn't a problem before Fedora 36, though, because Fedora installed sqlite3 by default, so the 'wrong installation instructions' issue never arose: the package was there already and therefore didn't need prompting for in the first place. Fedora 36 has decided not to install sqlite3 by default, however, thereby exposing this problem ...and necessitating a bug-fix!
Reports written to disk would fail When running reports, you can specify whether the data should be written to screen (i.e., for on-screen scrolling and inspection) or to disk (i.e., as a pipe-delimited text file). If you opted to write the report to disk, and the path and/or filename you supplied contained spaces, the report would appear to be written successfully... but it actually wouldn't be written at all. That has now been corrected: provided you wrap your path/filename with spaces in them inside a pair of double quotation marks, Giocoso version 2 will write the report correctly.
Countdown timer would display invalid 'ending at' timeThe countdown timer that displays at the bottom of the program screen whenever music plays would sometimes display an 'Ending in 23:59:59' message as a piece of music completed its play. It no longer does so: the completion time will be shown, correctly, as 00:00:00 hours, once the playback of a recording is completed.
Database creates and refreshes now lock each other outIn Giocoso version 1, it was possible to launch a create or refresh database operation whilst the first was still running. The second operation would then erase files that the first would expect to be there, and general mayhem would result. A database create or refresh in version 2 now creates a lock file. A second session seeing that lock file will simply quit (displaying an explanatory error message). Creates/Refreshes don't trample all over each other, basically. This does mean, however, that an interrupted create or refresh leaves the lock file behind, preventing any future creates or refreshes. The lock file can, however, be manually removed if appropriate, using standard file system commands (rm $HOME/.local/share/giocoso/scanlock will do it, for example).
Database creates and refreshes which find no FLAC files now terminate nicelyIn Giocoso version 1, if you were doing a create or refresh database and you pointed --musicdir to a folder that had no FLAC files in it, the database population process would fail with errors about needed files not being readable or accessible. That's simply because the files were created only if FLAC files were found, so the lack of FLACs meant no file creation... and hence file system errors when Giocoso later tried to read the files it assumed would be there. That's now been fixed: in Giocoso version 2, a create or refresh database operation that is pointed to a folder containing no FLACs now terminates cleanly, with a suitable error message displayed.

Note: there are countless bug fixes that have been made that I consider too minor to be worth reporting on. The ones above were significant enough to affect very visible program behaviours.

[Back to Front Page]