Well golly -- I didn't really do anything. I set up a Raspberry Pi with the RPi version of ST to see if the Scheduler worked on it. (The RPi version suffers from the same text entry issue I have with the plain-vanilla Linux version which I posted about in the Bugs subforum, so one needs to be very careful entering text or use the webGUI which doesn't have the issue.) I followed the example syntax, gave complete pathing to the target Presets and turned on the Scheduler and it just worked. So I went back to the Linux one I am using on air and did everything the same way, and it also works. I have some trialing to do on air now to confirm.
About the name of the active preset not changing, that's apparently by design. HvZ wrote to me, saying "Yes, the name of the preset doesn't change - and that's on purpose. What the scheduler is intended for is to just change a few settings, for example the aggressiveness of the compressors or the AGC drive. You _can_ make it load full presets but that will often cause audible glitches when switching between presets. So our advise is to just include a few settings that you want to change and keep the files empty otherwise. And if used like that, it makes sense that the preset name isn't updated. (We also don't reset values that aren't present in the file, which we do for normal preset loading)."
At the moment I am loading full presets on schedule so I'll have to listen to see whether that's going be cause an issue for listeners. Not having the name of the active preset change doesn't give an indication that anything has changed, but the Scheduler page does show which preset is active.
So tl;dr -- my error, Scheduler does work on the Linux & Raspberry Pi version, I expected the name of the active preset at the top of the GUI to change but it doesn't and that's intentional. Loading presets on air may cause audible glitching.
|