-
Notifications
You must be signed in to change notification settings - Fork 0
03. App Configuration
FYI, if you use the Windows installer (it's an executable starting with version 4.0), the "mandatory" concerns are automatically addressed, and option settings are all you may wish to consider.
Overall configuration data is stored in a file named mhh.conf. For obvious reasons, you have to modify configuration so that the program can find the various visualization files. The Windows installer will set these paths for you. For manual installation, or to add custom content, set the path values listed below under the [windows] section at the end of the config file.
VisualizerPathPlaylistPathTexturePathFXPath
You can also list multiple paths (separated by a semicolon for Windows or a colon for Linux). If you use the Volt's Laboratory content distributed with the program on the release page, you should specify a shared library path after the visualizer and FX paths. The configs from that repo share general-purpose shader library files.
If you simply unzip the release archive into a directory, the program will read mhh.conf from the ConfigFiles template directory (relative to the location of the executable). As explained above, note that mhh.conf is not usable "out of the box" since it doesn't point to your content (visualization) config files. You can edit the configuration and leave it there, but unzipping any later releases will overwrite that file (which means you'll lose anything you customized).
IMPORTANT: The recommendation is to manually copy that
mhh.confto the application's top-level directory, which is the default place the application looks for a config file. Release archives never include a config file in the top-level directory, so your version of config will be untouched by you or the installer overwriting the current version with a newer release. The latest installer also tries to upgrade any top-level-directorymhh.confwith new settings, although you may want to review the file after an update, especially if you're a hands-on type who has made config changes.
You will also see mhh.debug.conf in the config template directory. You can disregard this, as the name suggests, it's for developer usage. The contents may change at any time, it's mostly uncommented, and it may reference unreleased features. It is loaded when a debugger is attached (ie. running the program from Visual Studio). It gets installed simply because it's part of the code repository for my convenience (and safekeeping).
Another option for configuration is to create an environment variable named monkey-hi-hat-config pointing to the directory location of a configuration file, or the complete pathname to a specific configuration file, which can be stored anywhere the application can access. If the environment variable exists, this is the first location the program checks for a file. During an update, the installer will not look for or modify config files referenced by an environment variable.
To recap, the config path search sequence is:
- The environment variable
monkey-hi-hat-config(directory or full pathname) - Application top-level directory (the preferred option)
- Application
ConfigFilesubdirectory (the least-preferred option)
Comments in the mhh.conf file documents all currently-available settings. It is reasonably self-explanatory, but generally it contains things like file locations, startup modes, and audio device information. Some information is listed twice according to whether it is running under Windows or Linux.
The UnsecuredPort option defaults to 0 when the setting is not specified, which disables listening on a network port. However, the provided mhh.conf file actually sets this to 50001, which is the default value expected by the monkey-droid GUI application. Although the name "unsecured" might sound a bit alarming, this is just to remind people that the application should never be exposed to public networks.
The Windows HideConsoleAtStartup and HideConsoleInStandby options don't work correctly with the newer Windows Terminal application. Microsoft has spent several years debating a fix across multiple threads (latest issue), so hopefully they'll address this soon.