The Control menu allows a non-playing Giocoso session to send 'control messages' to a music-playing Giocoso session, giving it instructions such as:
- Please stop playing music once the current recording has finished
- Please stop playing music, immediately
- Please stop playing this recording, but pick something else and start playing that instead
- Please re-play the current recording once it's finished
- Please suspend or pause playback of the current recording
- Please resume playback of the current recording
All these commands can be given by the items on Giocoso's Control menu. However, when Giocoso starts playing music, the entire set of menu options it provides disappears and cannot be accessed -so, there's no way to get to the Control menu from the same Giocoso program that's doing the music playing!
Instead, if you want to control a music-playing Giocoso session, you must open a new Giocoso session (in another terminal) and access the Control menu from there. Once you've issued the control message you wanted, you can close that second session of Giocoso down entirely. You could also just keep it open, if you prefer: the choice is yours. The point is that having once issued a control message, the issuing session doesn't need to stay 'alive' for the message to take effect.
A runtime alternative exists for every item on this menu, too. So, instead of opening a second terminal, launching Giocoso, selecting the Control menu and then typing one of the menu options you can simply launch a new terminal and type commands such as
- giocoso --autostop
- giocoso --terminate
- giocoso --skip
- giocoso --repeat
- giocoso --pause
Hopefully, the menu options and their runtime equivalent commands are self-explanatory and I needn't document them at great length here.
Toggles
I will, however, mention that the menu options (and the runtime equivalents) generally operate as toggles. That is, one use of the menu or one issue of the command switches the feature on and a second switches it off. A third would switch it back on again, and so on.
In other words, say I'm wishing to tell the program to repeat-play whatever is currently playing. I can take Control menu Option 4. A message will appear in the playing session indicating that 'repeat mode' has been engaged. If I take Option 4 a second time, before the recording repeats, the message will disappear, repeat mode will be disengaged and the recording will not repeat when it reaches its conclusion.
Similarly, if I take Control menu Option 5 as a piece of music plays, it will immediately stop playing. But if I take Control menu Option 5 again, it will resume playing from the exact point it had previously reached.
The only options on this menu which don't operate in this 'toggle' fashion are the two which initiate immediate and irrevocable behaviour: terminate and skip. Issue those runtime commands or take Control menu Options 2 or 3 and the music-playing Giocoso session will immediately stop playing all music, or will immediately stop playing the current recording and move on to a new one. There is no going back from those actions, so there's no 'toggle' nature to the commands or the equivalent menu options.
Combinations
I should mention, too, that the options can be combined -but when you do, certain options take precedence over others. For example, you might ask to autostop play after the current recording ends... and then decide, no, I actually need to immediately stop playback of all music. So, you first issue an Autostop command, and then you issue a Terminate one: the terminate one takes precedence over the autostop and triggers an immediate halt to all music playback. The fact you ever issued an autostop request is silently forgotten!
Similarly, if you'd asked for a repeat and then ask for a skip, the skip will take place immediately, and the initial repeat will be forgotten. An autostop will likewise take precedence over a repeat request, no matter in which order you issue the commands.
A pause request, however, is non-destructive. That is, whilst it will take effect immediately, any pending or subsequently-requested autostops or repeats will be respected when playback is resumed.
Consequences
Be aware that a skip request 'consumes' one of your available play selections. That is, suppose you have Giocoso configured to play 10 pieces of music, one after the other. It's now playing the third selection; you request a skip; you will immediately be playing the fourth of your available selections.
For this reason, if you were currently playing the tenth selection and requested a skip, you'd end up terminating all music playback, rather than moving on to playing a new recording, because no eleventh selection is configured to be played.
Skips are not recorded in the plays table at all. That's true also of requests to terminate playback: whatever is currently playing will not be recorded as having been played at all.
Autostops are kinder in this respect: since the currently-playing recording is allowed to complete before music playback terminates, its play is recorded.
Repeats result in multiple entries into the plays table, one for each completed playback. Note that there's no limit to the number of times you can request a repeat: so long as you keep issuing the control command before the current playback ends, Giocoso will keep on playing the same piece of music over and over again, until it hits the limit of currently-configured selection plays.
Some Notes about Pausing Playback
When Giocoso plays music, a 'countdown' timer is displayed in the header of the main screen:
The timer is not the most accurate 'clock' in the world, because it's dependent on your CPU ticking over nicely -and your CPU probably has a lot of non-Giocoso stuff to be getting on with. It therefore 'drifts' and whilst it may say you've played 28 minutes, 27 seconds of a recording that lasts for an hour and four minutes, it's probably more like 28 minutes and 28, 29 or 30 seconds. Periodically, therefore, Giocoso adjusts the clock to reduce the drift back to sub-second levels. For most PCs, most of the time, you're hardly ever going to spot the clock corrections -but on a slower PC (such as a Raspberry Pi), you may occasionally see the 'Played' time jump foward or back a second or two at random, infrequent intervals.
If you pause your music, however, then this clock adjustment mechanism stops dead in its tracks. When the music is resumed, the clock adjustment mechanism doesn't come back on, either (by design, I hasten to add!)
The practical upshot is that if you pause your music playback for a long time, you may well notice that, when playback resumes, the recording ends up terminating several tens of seconds earlier than would seem appropriate: in the case of the above recording, for example, you might see (or hear!) it ending after 1:03:58 of elapsed time. It's not that 14 seconds of play were lost, though: it's just that the counter cannot keep 100% accurate time when compared to a wall-clock once pause mode has been engaged.
Another 'feature' of the pause command is that the countdown timer simply screws up completely if you pause the music past midnight. The computation doesn't understand that 23:59:59 wraps round to 00:00:01 and the maths determining elapsed time and the 'Ending at' clock time goes completely bonkers. This is a known issue, but is one I am unlikely ever to fix as my brain has a hard time with clock arithmetic at the best of times. Trying to make Bash scripts do what my own brain won't do is a bit of a challenge...