1.0 Pre-Version 3.30 Default Search
To understand the significant changes that Version 3.30 brings to the Giocoso music search algorithm, it's perhaps a useful thing to understand how the earlier version search algorithm worked. Underlying it was a belief that every composer should have an equal chance of getting the next-ranomised 'play', no matter that he or she only had 5 recordings in the collection whilst the likes of Bach and Mozart had hundreds (if not thousands!). The size of your contribution to the music collection should not determine the likelihood of you being selected for the next random play.
So, pre-Version 3.30 search had a two-stage selection process: first pick a composer, at random, from a list of all available composers, one row per composer. That meant every composer 'counted' as much as any other and had an equal chance of getting picked. Second, knowing the composer, find a recording by that composer.
In that first selection process (of a composer), you had to take account of the fact that assorted configured parameters affected who could be viable candidate composers. For example, if the minimum or maximum duration parameters were set, you could exclude any composer who was known to only have recordings shorter or longer in duration than those permitted values. If you had configured the 'only play previously unplayed recordings' parameter to 'yes', Giocoso would ensure that the one, selected composer at least had some unplayed recordings to his or her name. If the excludes.txt was set to explicitly prevent the playback of music by particular composers, those wouldn't be allowed to get randomly selected, either. The time-bar feature also kicked in: we'd only select as the one candidate composer people who hadn't already had music played within the past x hours (where x defaulted to 6). So, the 'random' selection of a composer was only made after the number of 'conceivable composers' had been culled of people who couldn't possibly pass various configured selection tests.
Similar tweaking had to be done at the second selection process (of a recording), too: if a 'minimum duration' and a 'maximum duration' parameter had been set, for example, the randomly-selected recording might not have met those criteria. In which case, you'd throw that selection away and pick a different recording (but by the same composer). If that failed the duration tests, you'd have another random selection ...and you'd keep going until you happened to stumble across a recording that met all the configured selection requirements. You'd keep going round this select-discard-re-select loop for as many times as had been configured for the 'maximum number of searches before giving up' parameter.
All of this resulted in a default search mechanism that randomly selected recordings to play whilst taking account of various 'modifiers of randomness' that were under user control, but did so on a recording-by-recording basis.
2.0 Version 3.30 Default Search
Version 3.30 potentially changes the environment in which Giocoso operates: instead of everything happening on one, local PC it's now possible for multiple PCs to be communicating with a single, shared database over the network. That changes things considerably: the idea of selecting something, throwing the result away and then having hundreds of other goes until you get lucky is a bit of a no-no in a networked environment. Networks are relatively slow to communicate over; and you don't want to be flooding them with unnecessary traffic if you can avoid it.
Accordingly, Version 3.30's default search algorithm changes significantly from what went before, even if no network is actually in use, though still with the goal of 'every composer having an equal chance of the next play' in mind. Putting it at the highest level first, Giocoso now performs a batch selection process, rather than a record-by-record one: this means multiple results are grabbed at once and the results are then filtered into usable form.
Search still remains a two-phase process, however: 'select composers', followed by 'select recordings'.
2.1 Composer Selection
To start, we select a pool of 'candidate composers'. The pool size is twice whatever has been configured to be the 'Number of plays per cycle' parameter in the Administration menu, Option 2. If you've said 'play me 10 recordings in a cycle' there, then 20 composers will be selected at random, for example.
The selection of those composers still regards each composer as worth exactly the same as every other, regardless of the number of recordings attributed to them.
- We filter for composers who cannot meet the configured minimum and maximum duration parameters: if you've said 'maximum duration of 20 minutes', there's no point letting Verdi or Wagner be selected as viable candidates!
- We also apply the 'unplayed works' filter, if it's configured to be on. No point in letting Britten in as a candidate if I've said 'only play things I've never played before', since I've played everything ever written by him many times over. So we weed people like him out early.
- Next we apply the under-played composers filter, if it's configured. Again, it would be pointless to consider the likes of Mozart and Beethoven as viable candidates if we've said 'only play under-played composers', given they've both got hundreds of hours of previous play-time to their credit.
- And finally, we apply the excludes.txt file, if one has been created. That is, we explicitly say 'the pool cannot contain composers x, y and z' because x, y and z are all listed in the excludes.txt file.
That query is then executed to return a pool of candidate composers.
Notice that we do not apply the time-bar parameter and/or exempts file criteria at this point. We don't have a single composer whose time-bar status we can easily evaluate: we instead have a pool of multiple candidate composers, some of whom might be time-barred and some of whom might not be. For various technical and logical reasons, we cannot easily evaluate all of their time-bar status at this point, so they are allowed into the pool of candidate composers anyway, at this stage.
2.2 Recording Selection
With a pool of (say, 20) candidate composers to hand, we then move on to the second stage of the default search process: creating a pool of 'candidate recordings' to play.
We start by selecting for any recordings by any of the 'pool composers' who meet the minimum and maximum duration tests. These tests were applied to the composers because we didn't want to regard composers as candidates who simply hadn't written music long or short enough -but now we have to apply the same tests to the recordings by those composers. Britten may have got into the pool of candidate composers because some of his recordings met a maximum duration test of 20 minutes (say)... but it's now time to exclude from consideration all the two hour-long operas he wrote!
We also need to re-apply the unplayed works filter, if it's configured: again, we potentially used this test to restrict the pool of candidate composers, but once a composer has become a candidate, he or she is likely to have a mix of previously-played and unplayed works: if the filter is set, we need to make sure only the unplayed ones make it into the pool of candidate recordings.
We then consider whether a time-bar should prevent some recordings being considered play candidates. First, we assess the exempts.txt file and consider if it lists anyone that should be exempt from the time-bar. If any of the candidate composers are listed in the exempts file, then all candidate composers are considered exempt for the duration of this play cycle: the time-bar filter is not set, and its unsetted-ness then applies to the entire selection of candidate recordings. If none of the candidate composers are listed in the exempts file, however, then the configured time-bar is applied to the selection criteria and thus all candidate recordings will be subject to the configured time-bar: only those written by composers who haven't appeared in the PLAYS table within the last x hours will make it into the pool of candidate recordings.
Note that this late application of the time-bar might mean that none of the candidate composers should have been selected in the first place: the Stage 2 selection will therefore return zero viable recording candidates. If that happens, you'll be told that your selection criteria matched nothing. You can manually try again, of course: you might get luckier second time around ...or (and what you should really do) is look at your configured defaults and relax some of them, permitting different min/max durations, allowing previously-played works and so on.
Assuming the time-bar filters are passed, however, you've not got a pool of candidate recordings, ordered randomly. We then apply a second filtering of that pool so that only one recording per candidate composer makes it into the 'final' pool of candidate recordings. Giocoso then proceeds to play through that pool, recording by recording, until the 'number of plays per cycle' number is reached, at which playback stops completely. Note that there might be 300 recordings in the 'candidate pool', but only the first 10 of them will be played (assuming 'number of plays per cycle' is set to 10, of course). The other 290 are just 'lost': they might get re-selected when you ask for a new cycle of plays to begin.
The ten plays, however, were achieved with just two visits to the database: one to grab the pool of candidate composers and a second to grab the pool of candidate recordings. The entire selection process is much more efficient than before, therefore, in terms of accesses to the database, especially if the database is a remote, Pro, one over the network.
3.0 Consequences of the new Search mechanism
The new search mechanism retrieves a pool of maybe tens or even hundreds of 'candidate' recordings that meet all your various configured search filters, in one visit to the database. There is no 'pick one, find it doesn't meet requirements, dispose, re-try' cycle any more: accordingly 'the maximum number of searches before giving up' configured parameter has been removed in Giocoso Version 3.30 (and is ignored if it's set).
If the search doesn't return any rows, it's because the combination of configured search parameters are set so tightly that no rows can meet all of the requirements. There's no point re-executing the failed search over and over, hoping for a different outcome: SQL either finds matching rows or it doesn't! Running it a second time will return the same result as the first time, so if search ever fails to match even a single recording, you'll see an error message advising you to relax your search parameters so that fewer database records are excluded from matching.
You may have 'plays per cycle' set to 10 (say), and only 5 rows meet your configured search requirements: that's fine. Giocoso will play the five candidate recordings and then stop. The 'plays per cycle' parameter is, in other words, a maximum, not a minimum. Not having enough candidate recordings to reach the target number of plays is not considered to be an error.
The time-bar and exempts mechanism now changes meaning significantly, as hinted at in Section 2.2 above. Let's say you've put Benjamin Britten into the exempts.txt, so no time-bar is set for him: no matter when he was last played, he can always be played again. Let's also say your standard time-bar is set to 6 hours (which is the default), and that you played some Elgar at 9AM, meaning that Elgar can't be a candidate composer again until 3PM. The new search mechanism in Version 3.30 means that if Britten happens to be one of the selected candidate composers, then all members of the pool of candidates are considered to be covered by Britten's explicit exemption from the time-bar.
So, let's say you're doing a new default search for something to play at 11AM. Remember that the time-bar is not applied at the stage of selecting candidate composers, so it's possible that the stage 1 selection process randomly grabbed Bax, Elgar, Walton, Britten, Beethoven and Mozart. Britten is then spotted as being exempt from the time-bar: therefore, so are Bax, Elgar, Walton, Beethoven and Mozart for this play cycle only. It is quite possible, therefore, that the stage 2 selection of candidate recordings will randomly select Elgar's Engima Variations. In earlier versions of Giocoso, the previous play of Elgar at 9AM would have not permitted this selection, but the new Version 3.30 algorithm does, because Elgar is in the pool with someone who is mentioned in the exempts.txt.
What's more, the stage 2 process might select Engima Variations, Tintagel and Troilus and Cressida for play. That's one piece by Elgar, Bax and Walton: Britten was in the pool of eligible composers, but none of his recordings managed to get randomly selected for play. It doesn't matter: it's the mere presence of a candidate composer in the exempts.txt that means the time-bar is not applied for this cycle, regardless of whether the candidate makes it through to the recording selection phase.
Now imagine it's 2PM and you ask for another cycle of default selection plays. This time, the stage 1 process selects Elgar, Mahler, Shostakovich, Berg and Bartók. They're all viable candidates (because the time-bar is not applied at stage 1 of the selection process), but this time no-one is in the pool of candidate composers who is also mentioned in the exempts.txt ...so all the composers are now subject to the configured time-bar during the stage 2 selection of candidate recordings. On this occasion, therefore, nothing by Elgar will be considered a viable candidate recording, because his Engima Variations were played starting at 11AM and that now forbid re-selecting anything by him until at least 5PM.
4.0 Summary
Summing up all this mind-numbing detail:
- Composers are selected as candidates without reference to the time-bar or the exemptions, but respecting all other filter considerations
- Twice as many composers are selected as candidates as the 'plays per cycle' parameter is set to
- Recordings selected by all and any of the candidate composers will respect all configured filter considerations (unplayed, maximum duration etc.)
- Recordings by all and any of the candidate composers are subject to the time-bar, unless one of the candidates is explicitly exempted from the time-bar
This can be summed up even more succinctly as: the Version 3.30 default search algorithm still achieves the randomised play of works by all composers equally, but precisely what gets selected and when will be subtly different from what you were used to in prior versions of Giocoso!
[ User Manual Home ] | [ Giocoso Pro Concepts ] | [ Giocoso Pro Menu ]