The EAR Production Suite is a set of VST® plugins and tools for producing immersive and personalizable audio content suitable for any Next Generation Audio codec. It is based on the Audio Definition Model (ITU-R BS.2076) and the ITU ADM Renderer (ITU-R BS.2127) and enables monitoring on any ITU-R BS.2051 loudspeaker configuration.
A simple update checker which gets https://ear-production-suite.ebu.io/version_info.json - newly implemented on website. This supplies data about the latest version and is used to populate the main webpage too. We parse the JSON and compare against the version that's running. We might inform user depending on the result and how the check was invoked (should be silent?). The version we have last notified the user of is store in an xml file and compared against the next time we get update information. This is so we don't repeatedly remind the user of the same update during automatic checks on start-up.
Update check can be run 2 ways;
On startup if the user hasn't disabled it - we store this preference in a xml file. By default we will do a check on startup (e.g, when settings file doesn't exist, such as first run). However, if the settings file doesn't exist but also isn't writable, we do not check. This is because if the settings file is not writable, we don't want to inconvenience the user by doing something they're unable to disable. The user can change their startup check preference from the REAPER Extensions menu, which simply writes to the preferences file.
An update check on startup has a timeout of only 1 sec so as to not hold up REAPER loading too much (because we have to do this on main thread, explained later).
An update check on startup will show a dialog if a new version is available that we have not previously told the user about. It will not inform the user if the GET request fails or times out, or if no update is available (version online is <= this version).
Manually through an option in the REAPER Extensions menu.
A manual update check has a timeout of only 3 seconds.
A manual update check will show a dialog if a new version is available regardless of whether we have previously told the user about it. It will also inform the user if the GET request fails or times out, or if no update is available.
History is a bit back-and-forth because;
I started implementing with libjson and winapi/curl for http, but then realised we could just do it much more neatly with JUCE (and reduce dependencies)
I started going down the route of threading but realised macos can't spawn dialog boxes from anything other than the main thread, so we have to hold the main thread until we're done (because we lose control of the main thread as soon as our entry function completes). Now instead I just use main thread and an appropriate timeout (built in to JUCE URL).
There are some changes to unrelated components such as properties_file.hpp used by the plugins, and binaural_monitoring_plugin_processor.cpp - this is just because it was a good opportunity to pull these preferences files in to the same common directory as the update preferences.
A simple update checker which gets https://ear-production-suite.ebu.io/version_info.json - newly implemented on website. This supplies data about the latest version and is used to populate the main webpage too. We parse the JSON and compare against the version that's running. We might inform user depending on the result and how the check was invoked (should be silent?). The version we have last notified the user of is store in an xml file and compared against the next time we get update information. This is so we don't repeatedly remind the user of the same update during automatic checks on start-up.
Update check can be run 2 ways;
History is a bit back-and-forth because;
There are some changes to unrelated components such as
properties_file.hpp
used by the plugins, andbinaural_monitoring_plugin_processor.cpp
- this is just because it was a good opportunity to pull these preferences files in to the same common directory as the update preferences.Need to test on Linux!