Giocoso's default mode of working with a back-end database is first to pick a composer at random, and then to pick something written by that composer, again at random. This two-fold randomness ensures that Giocoso doesn't end up playing lots and lots of Mozart (say), simply because he has contributed a huge amount of music to your collection: during that first-pass randomisation process of composer, Mozart stands as much chance of being selected as Qigang Chen or Frederic Cliffe. If you randomise the composer, you end up distributing plays of compositions across all of them, roughly equally.
But that is only Giocoso's default way of playing music: if you prefer, you can always 'intervene' in the randomisation process by specifying a number of runtime parameters to 'guide' Giocoso in its randomisation process. There are five selective runtime parameters that force Giocoso to consider:
- Performer (or 'distinguishing artist')
There are additionally four filtering runtime parameters that permit an otherwise-selected recording to be passed over:
- Unplayed Composer
- Unplayed Works
- Minimum duration
- Maximum duration
Whether most of these parameters have the effects you desire very much depends on the way you have tagged your music, because practically each parameter considers the metadata contained within specific metadata FLAC tags. Store the wrong information in the wrong tag and whilst the parameters will continue to work, the results they produce may not be exactly what you were hoping for!
Before I tackle all these parameters in turn, let me make the point that each of them is independent of the other and all or any of them can be used in combination, to construct very complex and subtle selection pressures on Giocoso. For example, 'play me a mass by Haydn that lasts less than 40 minutes and is conducted by Richard Hickox' can be represented by this sort of combination of filters such as:
--composer=haydn --performer=hickox --genre=choral --maxduration=40 --composition=missa
You can also negate any or many of the selective parameters (but not the filtering ones), to produce even more specific selections, by adding a final @ sign to the parameter value. For example, 'play me anything by Haydn that isn't a mass and isn't conducted by Richard Hickox, but does last at least 40 minutes and which I haven't played before' would be:
Here, the inclusion of the at-symbol (@) at the end of a parameter value means "not this value". There is no negation of the filtering parameters allowed: the negation of "only play unplayed works" is not to say "only play unplayed works" in the first place, for example. The opposite of 'play works longer than 40 minutes' (i.e., with a minimum duration) is 'play works that are no longer than 40 minutes (i.e., with a maximum duration). Thus the @-symbol negation can only apply to the five selective runtime parameters.
I'll now explore each of the selective and filtering parameters in more detail and in sequence below.
2.0 Selective Parameters
The use of the --genre=xxxx parameter instructs Giocoso to only select for possible play recordings which have been assigned the value xxxx (whatever it might be) in their GENRE metadata tag. I recommend a specific set of genre values to use when ripping and tagging your classical music in this article, but there is no requirement for you to have used them. Your parameter values will need to match what GENRE tags you have actually decided to use, therefore, when ripping and tagging your CDs.
Accordingly, the effectiveness of this parameter in providing 'selection pressure' to Giocoso will depend on how well you have identified your genres and how consistently you've applied them to your actual digital music files. If you've tagged some music as 'choral' and others as 'choir', one --genre=<something> filter cannot select both. Similarly, if you've tagged everything with the one genre 'classical', then you've effectively rendered this selective parameter useless!
Once the genre parameter has restricted the pool of music that Giocoso can play, it will still randomise a specific selection of something to play from that pool. If you launch Giocoso with --genre=ballet, for example, then whilst you know that a ballet of some sort will be played next, you won't know which specific one Giocoso will pick to play.
You cannot specify the same parameter twice. If you do, the second instance of it will be the one that gets applied. Hence, --genre=ballet --genre=opera will mean you will next be listening to some opera: the ballet parameter will be entirely ignored.
All selective parameters are matched by Giocoso in a case-insensitive and wild-carded manner. That is, --genre=symphonic has the same effect as --genre=SYMPHONIC or --genre=SymPhonIc. Likewise, --genre=symph will be as effective as --genre=symphony.
If your genre parameter value contains spaces or other punctuation marks (such as apostrophes), then wrap the whole value within a pair of double quotes. Thus --genre="Film, Theatre, Radio" will work without error (though bear in mind that wild-carding could mean that --genre=film is just as effective at finding matches as the more specific version).
As mentioned in the introduction to this article, ending your parameter value with an at-symbol (i.e., @) will mean 'not this genre'. In other words, whilst --genre=opera will guarantee that the next bit of music played will be an opera, [email protected] will guarantee that the next bit of music played will definitely not be an opera.
The use of the --composer=xxxx parameter instructs Giocoso to only select for possible play recordings which have been assigned the value xxxx (whatever it might be) in their ARTIST metadata tag. I want to emphasise that it is the ARTIST tag which is matched when assessing this parameter, not the COMPOSER tag. This is in accordance with Axiom 2 of my article on the way to tag classical music. Functionally, it's equivalent to matching the COMPOSER tag because, again according to Axiom 2 of that article, ARTIST and COMPOSER tags should always match exactly (and if you use my CCDT tagging tool, they are forced to match exactly, anyway!)
Axiom 12 from that same article also suggests that when tagging a piece of music by Britten, for example, you should use his customary full name: Benjamin Britten. That means your ARTIST tags will probably contain spaces between the various parts of a composer's full name. If you need to specify any of the selective parameters with values that contain spaces or other punctuation, wrap the whole value within double quote marks. Thus --composer="Benjamin Britten" or --composer="Vincent d'Indy".
The use of the composer selection parameter means that Giocoso now selects from a pool of music written by the specified composer. What specific piece of music gets played from that pool remains a matter of random chance, however.
You cannot specify the same parameter twice. If you do, the second instance of it will be the one that gets applies. Hence, --composer="Arnold Bax" --composer="Arthur Bliss" will mean you will next be listening to some Arthur Bliss. The Arnold Bax selection will be entirely ignored.
All selective parameters are matched by Giocoso in a case-insensitive and wild-carded manner. That is, --composer=britten has the same effect as --composer=BRITTEN or --composer=BritTTen. Likewise, --composer=britten will be as effective as --composer="Benjamin Britten", provided only that there's no composer in your music collection called Frank Britten -because then the latter will not select his music to play, but the former will.
As is true for all selective parameters, the use of the at-symbol (@) indicates the negation of a parameter value. That is --composer=britten will mean you will next be listening to something written by Benjamin Britten; but [email protected] will guarantee that the next piece of music you listen to will be by anyone other than Britten.
The use of the --performer=xxxx parameter instructs Giocoso to only select for possible play recordings which have been assigned the value xxxx (whatever it might be) in their PERFORMER metadata tag. Axiom 6 of my Axioms of Classical Music Tagging article explains that the expectation is that the PERFORMER tag will contain the name of whichever performing artist makes this recording of a work different from that one -a piece of data that this website often refers to as the 'distinguishing artist' in consequence. That is usually the conductor of a work, but it might be the violinist for a Violin Concerto, or the soprano prima donna in a Bellini opera. There are no fixed rules, other than that it should be the ordinary, full name of the person that makes a recording stand distinct from any other recording of the same composition.
Usually, the performing artists for any recording would be listed all together in the COMMENT tag (see Axiom 3). The PERFORMER tag might therefore be considered a little superfluous. Nevertheless, Giocoso permits you to select on the basis of it, should it be more useful to you than it is, personally, to me.
Since we are dealing with a tag that probably contains a person's full name, it will likely contain spaces between the name components. If you need to specify any of the selective parameters with values that contain spaces or other punctuation, wrap the whole value within double quote marks. Thus --performer="Herbert von Karajan" or --performer="maria callas".
The use of the performer selection parameter means that Giocoso now selects from a pool of music where the distinguishing artist is that named individual. What specific piece of music gets played from that pool remains a matter of random chance, however.
You cannot specify the same parameter twice. If you do, the second instance of it will be the one that gets applies. Hence, --performer="karajan" --performer="callas" will not get you recordings in which Karajan conducted Callas. It will mean only that you will next be listening to something sung by Maria Callas, conducted by who-knows-who? The Karajan selection will be entirely ignored.
All selective parameters are matched by Giocoso in a case-insensitive and wild-carded manner. That is, --performer=callas has the same effect as --performer=CALLAS or --performer=CaLLaS. Likewise, --performer=karajan will be as effective as --performer="Herbert von Karajan", assuming that Karajan didn't have a twin brother who also conducted!
As is true for all selective parameters, the use of the at-symbol (@) indicates the negation of a parameter value. That is [email protected] will mean you will next be listening to something that Leonard Bernstein did not conduct.
The use of the --composition=xxxx parameter instructs Giocoso to select for possible play only those recordings which have been tagged with the xxxx value (whatever it might actually be) in the ALBUM tag. This is expected to contain the extended composition name of a classical music recording (see Axiom 5). Practically, this means the tag will contain data such as 'Symphony No. 5 (Bernstein - 1967)', and you can supply all of that or just some of it as the parameter value to have its chances of being the next recording played boosted.
Given that sort of data in that tag, we are almost certainly dealing with data that contains spaces, and potentially lots of apostrophes: as is true for all runtime parameter values, if you wish to specify a value containing a space or punctuation character, enclose the whole thing in double quotes. Thus --composition="Peter Grimes" or --composition="The Spider's Feast".
Generally speaking, you would expect the complete extended composition name to be unique (unless you like spending money buying multiple copies of the exact same recording, by the exact same artists, in the exact same year!). An instruction to play --composition="Peter Grimes (Britten - 1958)" will therefore make Giocoso completely non-random in its choice of the next piece of music to play, because that's practically the definition of a primary key for my music collection! However, an instruction to play --composition=grimes, whilst certainly ensuring that the next thing played will contain the word 'grimes' in its ALBUM tag somewhere is much less specific: if I had a recording called 'The Grimesthorpe Colliery Band plays loudly' or 'The Four Sea Interludes from Peter Grimes', either of those might get selected for play instead of the complete recording of Peter Grimes.
That example also confirms that all selective parameters are matched by Giocoso in a case-insensitive and wild-carded manner. That is, --composition=grimes has the same effect as --composition=GRIMES or --composition=GrMEs. It also confirms that --composition="war requiem" will be as effective as --composition="ar r": there might be other compositions whose names contain the sequence a-r-space-r, but I can't think of many!
You cannot specify the same parameter twice. If you do, the second instance of it will be the one that gets applies. Hence, --composition="otello" --composition="carmen" will not get you a double-billed performance of Otello followed by Carmen. You'll get a recording of Carmen played and the attempted selection of Otello will simply be entirely forgotten about.
As is true for all selective parameters, the use of the at-symbol (@) indicates the negation of a parameter value. That is [email protected] will mean you will next be listening to something that definitely doesn't have the word 'requiem' in its extended composition name.
The last of the selective runtime parameters, the use of --comment=xxxx when launching Giocoso forces a selection of recordings which have the xxxx value in their COMMENT tag. Per my Axioms of Classical Music Tagging article (see Axiom 3), this tag is expected to contain a free-form, comma-separated list of the various performers making a given recordings. The conductor would usually be listed first, then the orchestra, then the choir, then the various soloists and so on. Given its free-form nature, it is unlikely you'd ever supply a specific and totally unique value to Giocoso with this parameter. It's more intended to make Giocoso play, for example, operas in which Joan Sutherland sings, rather than ones in which Maria Callas is performing.
Given that sort of data in that tag, we are almost certainly dealing with data that contains spaces, and potentially lots of apostrophes: as is true for all runtime parameter values, if you wish to specify a value containing a space or punctuation character, enclose the whole thing in double quotes. Thus --comment="Marisa Robles" or --comment="du Pré".
An instruction to play --comment=robles will ensure that Giocoso selects for possible play all recordings in which the harpist is listed in the COMMENT tag as being Marisa Robles (well, sort of: if there's a trombone player tagged in COMMENT whose name is Thomas Robleson, that will select for him too!) Giocoso will, however, still make a random selection from all possible candidate recordings, so there's no telling which specific Robles recording you're going to be listening to next.
That example also confirms that all selective parameters are matched by Giocoso in a case-insensitive and wild-carded manner. That is, --comment=Robles has the same effect as --comment=ROBLES or --comment=RoBlEs. It also confirms that --comment="norrin" will be as effective as --comment="Roger Norrington": so long as the tag contains the parameter value somewhere within it, it'll match and count as a selection candidate.
You cannot specify the same parameter twice. If you do, the second instance of it will be the one that gets applies. Hence, --comment="bernstein" --comment="karajan" will not get you a double-billed performance of something conducted by Leonard Bernstein followed by something conducted by Herbert von Karajan. You'll get a Karajan conducting something and that's it: the attempted selection of something where Bernstein is listed as a performer will simply be entirely forgotten about.
As is true for all selective parameters, the use of the at-symbol (@) indicates the negation of a parameter value. That is [email protected] will mean you will next be listening to something that definitely wasn't conducted by Sir John Barbirolli.
2.6 Combination Selective Parameters
As has been mentioned throughout this section, it's perfectly OK to combine multiple selective parameters to make up complex and subtle queries. Thus, it would be valid to do something like:
--genre=symphony --composer=b --performer=solti --composition="No. 3" --comment=London
...to mean "play me a symphony by any composer with a 'B' in their name, so long as it's that composer's third symphony, and so long as Georg Solti is conducting a London orchestra".
The logical underpinning of any such complex query is, however, entirely down to you. Whilst it's valid to submit a query such as:
--composer=beethoven --composition="Le Nozze di Figaro"
...you should not be surprised to see this error message appear when you do so:
Giocoso will perform multiple attempts to find something that meets your selection requirements: the default number of tries is the number of records you have in your music collection -which means inspecting every single recording to see if it matches your selection choices. That can take quite a few minutes to do on a multi-thousand recording music collection, however, so you are allowed to set the MAXSEARCH parameter in the persistent configuration file to any number you like to limit the time Giocoso takes to search for matches.
Ultimately, however, no matter how long Giocoso searches, it is never going to find a recording of Beethoven's Le Nozze di Figaro, since Mozart wrote it! If you present Giocoso with logical absurdities such as this (or --composition="Peeter Grimes", for example), then Giocoso will certainly try to find a match, but when it fails to be able to do so, it will respond with the red error text you see above. The solution is to relax or reconsider your choice of selective parameters so that you aren't constraining Giocoso so much.
3.0 Filtering Parameters
Using the --unplayed=xxxx filtering runtime parameter requires Giocoso to consult the ARTIST tag of all possible recordings and see if that artist (i.e., composer) has ever appeared in the history of recordings which have been previously played by Giocoso. In this sense, the filter means 'unplayed composers'.
To make this parameter be effective, Giocoso essentially performs a 'select from recordings where composer not in plays' test. Therefore, if a single track of anything at all by composer xxxx has ever been played previously, this filter will not make the works by that composer selectable.
All filter parameters can be added to any combination of selective runtime parameters. Thus, it would be possible to say something like 'play me anything conducted by Richard Hickox that's by a composer I've never played before'. That would be --performer=hickox --unplayed.
When you use the --unplayedworks filtering runtime parameter, you are asking Giocoso to consult the ALBUM tag of all possible recordings and see if that exact, extended composition name has ever appeared in the history of recordings which have been previously played by Giocoso. If you have played Symphony No. 5 (Bernstein - 1967) before (there's no limit on how many years or months before), then that exact recording will not be selectable as the next play by Giocoso; but Symphony No. 5 (Karajan - 1971) would be.
This parameter works because Giocoso essentially performs a 'select from recordings where composition_name not in plays' test. If you ever edit the ALBUM tag for a recording, you don't change the fact that the recording was previously played under its old name; therefore, the altered ALBUM tag will make the recording look 'new' when the Giocoso database is next refreshed -and that means it will be in the pool of recordings never previously played. It's new composition name won't match what is in the plays table.
All filter parameters can be added to any combination of selective runtime parameters. Thus, it would be possible to say something like 'play me a Haydn mass conducted by Richard Hickox that I've never played before'. That would be --performer=hickox --genre=choral --composition=missa --composer=haydn --unplayedworks.
Note the difference in meaning between --unplayed and --unplayedworks: whereas the former says 'find me recordings by a new composer', the latter says 'find me a new recording'. A recording by a composer you've never heard before will, of course, also be a new recording. But the converse is not true: you may have listened to lots of Beethoven violin sonatas, but never played Currentzis' latest recording of Symphony No. 5. That recording of the symphony is a new recording, but the composer is well-known and well-played by you.
The --minduration parameter can be used in conjunction with any other parameter. It takes a numeric argument which represents minutes. The default value for this parameter -and the value that kicks in if you supply an invalid value for it, such as ‘-10’, is 0. All recordings in your colleciton last at least 0 minutes, of course, so the default meaning of this parameter is to not exclude anything from playback.
The presence of this parameter with a valid, non-zero value makes Giocoso select randomly only those candidate recordings which are known to last for at least that number of minutes.
You can apply this parameter on its own or in conjunction with other parameters. Thus:
giocoso --dbname=main --minduration=30
…means ‘play me something, anything, provided it lasts longer than 30 minutes’. Whereas:
giocoso --dbname=main --genre=ballet --minduration=30
...means ‘play me a ballet that lasts longer than 30 minutes’. And so on.
The --maxduration parameter works exactly like the --minduration one, except that it sets a maximum length of time a piece of music can last for it to be a candidate for playing, with the parameter value again being a whole number of minutes.
Maxduration can be used on its own, in combination with other parameters -and even in combination with --minduration. This, for example, would be fine:
giocoso --dbname=main --genre=ballet --minduration=30 --maxduration=90
...and means ‘play me a ballet that lasts between 30 and 90 minutes’.
The default value for --maxduration (and the value that kicks in if an invalid value is supplied) is 525960 minutes, which is about the number of minutes in a year -and thus effectively means ‘no selection at all is being applied’ (unless you are a John Cage fan and like to play 'As Slow As Possible').
If both min and maxduration are used at the same time, the minimum should be lower than the maximum, for hopefully obvious reasons: you cannot ask for something 'longer than 60 minutes and shorter than 20 minutes' without making all sorts of logical nonsense! If they are not the right way round, however, Giocoso will automatically reverse the meaning of the supplied parameters. This, for example:
giocoso --dbname=main --minduration=60 --maxduration=20
...will be imaginitvely re-interpreted by as if you had typed:
giocoso --dbname=main --maxduration=60 --minduration=20
...which now makes logical sense: 'longer than 20 minutes, but less than 60'. Incidentally, Giocoso doesn't care which way round you combine the parameters: the max can physically be typed before the min, for example, as in this example; or the other way round, as in the previous example. It doesn't matter what the physical ordering of the parametes is, in other words; it's the logical meaning of the combination of the two parameters that needs to make sense, and which Giocoso will force to make sense if it has to!
As was mentioned when discussing the selective runtime parameters in Section 2 above, the negation character is the at-symbol (that is: @, which you see in email addresses). If you terminate a selective parameter's value with the negation character, you reverse the meaning of the filter. That is:
...means 'select music that is composed by Verdi'. Whereas:
...means 'select music that is not composed by Verdi'.
When you construct a complex combination of selective parameters, any or all of those parameters can be negated or not, as needed. Thus something like this would be valid:
...meaning 'play me something by Mozart that is not a mass, but is conducted by Herbert von Karajan, so long as the Berlin Philharmonic Orchestra are not playing'.
Note that the negation character can only be applied to the selective runtime parameters, never to the filtering ones. Logically, it would make no sense to apply them to a filtering parameter. If --maxduration=40 means 'play me something that lasts less than 40 minutes', the [email protected] is presumably meant to mean 'play me something that does NOT last less than 40 minutes'... which is exactly the same as saying 'play me something which lasts at least 40 minutes'... and that's what --minduration=40 would achieve. Likewise, [email protected] would be 'play me something that does NOT last more than 30 minutes', which is precisely what --maxduration=30 would mean. The negation of one filter is simply the logical equivalent of specifying the other, so no negation of either is permitted.
The --unplayed and --unplayedworks filters cannot be negated either, partly because they don't even accept an value. They are either present or absent when you launch Giocoso. If they are present, the negation of them would more simply be to make sure that they are not present. If they are not present, then there is no parameter that can be negated anyway!
Finally, please note that if you negate a parameter whose value has been encased within double quotation marks, it makes no difference if the at-symbol goes inside or outside the double quotes. That is:
--comment="Peter [email protected]"
...is exactly equivalent to:
...with both meaning, 'play me anything so long as Peter Pears isn't listed as one of the performing artists'.
5.0 Record ID Selection
I have not listed the --recordnumber selection parameter as one of the selective runtime parameters, because it is quite unique and ought to be regarded as rather sui generis. It is the only runtime parameter which effectively turns off all of Giocoso's randomisation functionality, because it is an instruction to play a specific, uniquely-identified, recording.
Every recording that is scanned for metadata and added to the Giocoso database during a create or refresh database operation is assigned a unique record ID number. You can see what number has been assigned to what recording by issuing the command:
giocoso --dbname=main --recordinglist
(You obviously replace 'main' with the name of your own Giocoso database). The command produces output such as shown here:
If I then wanted to force Giocoso to play, specifically, Aaron Copland's own 1969 recording of An Outdoor Overture, I could do so with the command:
giocoso --dbname=main --recordnumber=28
This is the only deterministic 'selective' parameter in consequence: it's functionally equivalent to cd 'ing to a particular recording's folder and invoking Giocoso without the --dbname parameter at all. Since it is so specific in what it is saying should be played, it makes no sense to combine this parameter with any of the others and you may not, therefore, do so. If you try to mix this parameter with any of the others previously listed in this article, the recordnumber parameter takes precedence and will be the only factor that determines what gets played next.
Finally: please note that recording ID numbers are re-assigned every time the Giocoso database is refreshed: they are not immutable. If I added Aaron Aardvaark's Symphony No. 88 to my music collection, I would find all my Aaron Copland recordings would have shifted 'downwards' (because Aaron Aardvaark would be alphabetically sorted before Aaron Copland) and thus acquired higher recording numbers after the next database refresh.
Summing up Giocoso's selection and filtering options, then:
- Giocoso will default to selecting a composer at random and then selecting something written by that composer, using the contents of the ARTIST tag to mean 'composer'.
- Five selective runtime parameters allow Giocoso instead to select positively by ARTIST (--composer), ALBUM (--composition), PERFORMER (distinguishing artist, a.k.a. --performer), COMMENT (performing artists, a.k.a. --comment) and GENRE (--genre)
- All five selective parameters can be used individually or in combination
- Each of the five selective parameters can be individually negated by terminating their value with an at-symbol (the @ character).
- Four filtering parameters allow Giocoso to filter out from possible play those recordings which do not meet the stated requirements for minimum duration, maximum duration, previously-played-composer or previously-played-recording status
- Any of the four filtering parameters can be used in combination with the five selective parameters
- None of the four filtering parameters can be negated by the use of the @ character.
- If you use multiple examples of any of the parameters, only the last one takes effect. If you said --composer=britten --composer=beethoven, you'd get to listen to some Beethoven, not some Benjamin Britten.
- Any logical absurdities arising from the use of multiple selective and filtering parameters (such as requesting to play music which has genre=syyyymphony, or the composition=Pieter Grimes, will trigger Giocoso to perform multiple searches to try and find something that matches -but will eventually fail when the maximum number of searches has been performed
- The default number of searches Giocoso will attempt before giving up is the number of recordings in your collection. If your collection is large, this might result in multi-minute waits for Giocoso to find something that matches all your search and filtering criteria
- You can limit the number of searches Giocoso will attempt to perform by setting MAXSEARCH=x in the Giocoso persistent configuration file, where 'x' can be any number you like. Practically, I have found 500 to be a reasonable compromise between giving Giocoso a good chance to find something and waiting ages for it to do so.
- A special --recordnumber=x parameter removes all randomness from Giocoso's music selections and instead directs it to play precisely one recording, that recording being the one known to have been assigned that record ID number when the Giocoso database was last refreshed. Record number IDs can be listed using the --recordinglist reporting runtime parameter.
Remember: you don't have to use any selective or filtering parameters if you don't want to. Giocoso's default behaviour is simply to select some music to play, entirely randomly. You only need to use the runtime parameters if 'pure random' doesn't meet your particular listening needs in the moment. For example, on a Sunday morning, I've often found I might prefer to listen to some choral music, rather than have Giocoso randomly select some John Cage prepared-piano whackiness for me! You use the selective and filtering parameters to guide Giocoso's randomness into areas you would prefer it to go, if you have such preferences in the first place.