You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

05-configuration.rst 3.9KB

3 years ago
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879
  1. .. _studio-configuration:
  2. Configuration Manager
  3. =====================
  4. In this section, we review a component common to the whole |Brand| software platform: the **configuration manager**. We start with this component as we will mention several times in this document how specific behavior can be changed according to this configuration manager.
  5. The |Brand| Configuration Manager is a software component in charge of configuring |Brand| applications and modules according to the user's wishes. Configuration settings are saved in a configuration file, which is loaded at application startup. This file uses a simple syntax, where configuration tokens are listed and given a value. You can check all the configuration tokens in |AuthTool| (Menu Edit/Preferences).
  6. Configuration Files
  7. -------------------
  8. |Brand| comes with **a default configuration file** (``share/openvibe/kernel/openvibe.conf``), automatically loaded at startup. This file lists configuration tokens used by the applications.
  9. Users can edit **a personal configuration file** in order to customize their |Brand| software platform, by overwriting existing token or declaring new ones. In order to do so, create a file named ``openvibe-workspace.conf`` in the folder next to the scenarios you are running. This file will impact all scenarios next to it.
  10. Syntax
  11. ------
  12. A configuration file basically looks like successive ``token = value`` statements.
  13. For example, the application can retrieve its root path (|Brand| installation path) from the Path_Root variable. The path is expressed relative to the execution directory bin, so the root path is simply:
  14. .. code-block:: ini
  15. Path_Root = ..
  16. Leading and tailing spaces are allowed, and are removed automatically:
  17. .. code-block:: ini
  18. Path_Root = ..
  19. Comments may be stored on their own lines. They begin after the ``#`` character:
  20. .. code-block:: ini
  21. #this is a valid comment
  22. Path_Root = ..
  23. Lines ending with a ``\`` character continue to the next line, the last ``\`` character of a line is automatically removed by the parser. Note that ``\`` is used as an escape character. To write a path, you should use ``/``:
  24. .. code::
  25. #this is a line that extends\
  26. to the next line
  27. Path_Root = ..
  28. Tokens declared anywhere in the configuration file may be used as values for other tokens. The syntax to be used is: ``${token}``
  29. For example, the binaries path may be declared as such:
  30. .. code-block:: ini
  31. Path_Root = ..
  32. Path_Bin = ${Path_Root}/bin
  33. Configuration files can include other configuration files thanks to a simple syntax:
  34. .. code-block:: ini
  35. Include = path/to/my/config/file.conf
  36. All tokens are read sequentially, and thus can be overwritten during the process.
  37. Existing Tokens
  38. ---------------
  39. Several tokens such as *Path_Root* and *Path_Bin* are defined in the default configuration file, and can be overwritten in user-defined configuration files. The token *Player_ScenarioDirectory* is useful when designing a scenario. This token is changed as the path of the scenario when playing it. This is useful to load a file in the same folder as your current scenario. To have the complete list of these tokens, and their values, you can open the window **Preferences**.
  40. Defining and Using Custom Tokens
  41. --------------------------------
  42. Defining your own token can be very useful as you can use them afterwards everywhere in |Brand|. For example, you can define a token ``LowPassFrequency = 40``. You can then use it as a setting in several temporal filters (``${LowPassFrequency}``). Changing the token value will automatically change the filtering frequency in every temporal filter at once, which can be very handy: modification is global and switching from one frequency to another is fast and easy.
  43. We will describe a concrete example that illustrates the use of custom configuration tokens, in paragraph "Appendix A: Using Configuration Tokens to Setup an Experiment Environment".