HUMA system: Manual under Construction Runtime Configuration
The HUMAruntime does not provide a user interface to set up its configuration, instead there are a couple of text files situated at HUMA/runtime/res in which you set parameters that then will affect the programs operation in terms of sensors, logging, debugging etc.
affects the general parameters: testline=true/false - if true incoming dynamic signals will be displayed on the top edge of the screen by green (y), orange (x) and blue(all others) bars. Note that these lines are only updated when the software actually reads sensor values. It may therefore happen that these bars seem to stutter, which does not necessarily mean there's something wrong on the input side. Note 2: If your monitor resolution exactly fits your movie size, displaying testlines will result in only the top left quarter of your movie being visible. autolaunch=true/false - if true the program will automatically go to fullscreen presentation mode with the movie whose filepath is marked under autoLoadFile. Latter will be updated whenever you got autolaunch set to false and browse for a moviefile with the upcoming file dialog. log=true/false: directs all application debug and log output to either the cmd prompt (when log = false) or to timestamped files at res/logfiles/MM_DD_HH_MM.txt (when log = true). guarded=true/false. True opens a connection to a little piece of watchdog software that can reanimate a frozen runtime or pull the computer's power plug. Requires additional soft- and hardware.
provides configuration entries for connected sensor hardware. As a HUMAruntime can handle multiple in and outputs (programable per scene), more than one of the sensors may be set to active (true). main sensor: determines the default sensor. This will be active long as you don't activate any other sensor for a particular scene (-> see building scenes). The parameter expected is the name of the desired sensor. The following entries determine separate sensors' configuration. Set all sensors you want to use in a project to true and set their parameters to your needs. Details to follow, most of this is pretty much self explaining.
HUMAruntimes are equipped with a growing number of inputdrivers and interfaces that feed normalized input values to the system and can be activated on a per scene basis. Open standards and flexible interface hardware offer a wide range of possibilities in terms of interface design. Humatic offers individual driver development for custom devices. Find in the following a listing of the modules currently available: OSC (Open Sound Control) a relatively young, widely user defineable, UDP based network protocol that is more and more featured in modern software synthesizers (Reactor, SuperCollider, Max/MSP. a.o.). HUMA uses OSC to connect to the Eyecon motion tracking system on the input side, but can also send OSC and thus for instance talk to the above mentioned programs or Flash clients on the internet via OSC/XML servers. Midi - Dynamic control of parameters via midi controllers, scene addressing via midi notes. Partly user defineable. Implemented on both in- and output side. RS232/422/serial A number of device specific drivers are integrated among which are industrial laserscanners, other optical sensors, some multi in out analogue interfaces and serial switchpacks. HUMAnet - A UDP based network protocol that extends the principles of software internal datatrafic to the network. Enables frame exact synchronization of multiple runtime computers and their intermediate control in a non hierachical manner (no master / slave principles) May also be used to integrate touchscreen based control panels etc. Parallel - Driver for digital joysticks and functionally identical devices. Outputside addressing of parallel switchpacks. Flash/ActionScript - Bidirectional communication with actionscript in integrated Flash media. Enables individual application scripting and design of complex interactivity and causality.