HUMA system: Manual under Construction Runtime Configuration, Sensor Overview

The HUMAruntime does not provide a user interface to set up its configuration, instead you use HUMAtagger to setup the runtime scenario for your project. Most of the configuration data is project specific - like what sensors or interfaces to use, how to finetune them etc. and is saved with the project. Some parameters though are machine specific and will apply to all projects played on that machine (examples include the input testlines, logging behaviour and last but not least the autostartoptions and filepaths). All configuration is done under:

-> Edit -> Runtime setup

When opened the following screen appears:

The machine tab (not shown here) sets the machine specific parameters:

testline - if active 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 - 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 inactive and browse for a moviefile with the upcoming file dialog. The path is not editable here

log - directs all application debug and log output to either the cmd prompt (when inactive) or to timestamped files at res/runtime/logfiles/MM_DD_HH_MM.txt (whenactive).

main tab - sets global project parameters.

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).

sensing - a general sensitivity adjustment parameter

autoShutDown & shutDownTime - does anybody know ? When this is active HUMA will shut the machine the runtime is running on down at the specified time. We use this System in unattended setups...

autoReboot & bootInterval - does anybody know ? When this is active HUMA will reboot the machine the runtime is running on at the specified intervals. Some people (especially Mac Users) just don't feel good when they can't reboot their computer once an hour ...So here is a feelgood automatism


The separate sensor tabs provide configuration entries for the build in sensor drivers. As a HUMAruntime can handle multiple in and outputs (programable per scene), more than one of the sensors may be set to active. Active sensor's tabs will be highlighted in red

All input devices - so called "sensors" - feed normalized input values to the system and can be activated on a per scene basis. You can programm your project using the mouse and then switch to a laserscanner or motion tracking system by a mouseclick. 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 implemented:

Mouse - (or any Windows mouse derivate like Graphics tablets, trackballs etc.) The "sensor" thats mostly used during programming. HUMA reads in x y coordinates and the scrollwheel as dynamic streams x,y & a . Mousebuttons trigger "Button" Events that you can assign actions to. How many buttons you have and how exactly they're numbered depends on your device. Usually you will have Button1 - left and Button3 - right.

Midi - Dynamic control of parameters via midi controllers, scene addressing or action triggering via midi notes. Partly user defineable. Implemented on both in- and output side. In and Outports are separately adjustable.

DMX - this is a driver for the Cinetix USB DMX 512 Control & Generator boxes (www.cinetix.de). it will let you control HUMA from any DMX device (Lightdesk, Showrecorder etc.) as well as enable HUMA to control DMX gear like dimmers, moving lights, motor controllers etc. An implementation of ArtisticLiscence's ArtNet DMX via Ethernet protocol may follow.
After installing device drivers for the virtual USB serial port look into Windows Device Manager to see what port number it has assigned and insert that into $dmx_serialport.
Some words on the general concept of HUMA's DMX implementation:
dmx data is transmitted in so called slots. There are max. 512 slots per DMX adapter. A DMX receiver defines an offset value into these 512 slots and then reacts upon as many slots as it wants to handle starting from this offset.
HUMA handles the first slot as a scene setting remote - you can select up to 255 scenes with the value coming in on slot nr %slotOffset
slots %slotOffset+1 to %slotOffset+5 are handled as dynamic datastreams y,x,a,b,c
slots %slotOffset+6 to %slotOffset+6+nrButtons are interpreted digitally: when the value becomes greater than 255/2 a BUTTON_DOWN Message with ID slot - (slotOffset+6) will be generated. When it drops below 255/2 a BUTTON_UP message with said ID will be generated.
The total number of DMX slots occupied by HUMA thus is 6+nrButtons.
For example you may have a 16 channel washlight on slots 1-16, then comes HUMA with %slotOffset set to 17 and %nrButtons set to 8 (total 14). So you could address your next dimmer or scanner from dmx slot 31 onward.

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 mainly uses OSC to connect to the HUMAtracker 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.

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.

Beside the above mentioned sensors that mostly fall back on industry standard protocols, Huma can load 3rd party io-extensions at runtime. You may call that plug-ins. To make you're own plug-in, you need to write some java code, be able to compile it, etc. It's not trivial, but in the end it's not such a big deal. Contact us to get a SDK Version

And:
This option is not only there for the sake of having a plugin mechanism. It first came up, because the number of integrated custom and very custom drivers became just too big. So today there are the standards fixly implemented and the non standards or less often used standards are provided as user sensors. Your HUMA copy should bring at least some of these, maybe more. Find them at res/runtime/userClasses/sensors. The user sensor tabs in the Tagger's runtime configuration pages will list what is there.

DXInput - a driver for any Direct Input compatible gamecontroller like joysticks, stiring wheels, plastic Kalashnikovs etc. This uses a DXI-java wrapper by Dipl.Ing Joerg Plewe - www.hardcode.de. Please see the supplied files in the DXInput folder for installation and liscense information.
HUMA reads in x y (& z) coordinates as dynamic streams x,y & a . Controllerbuttons trigger "Button" Events that you can assign actions to. How many buttons you have and how exactly they're numbered depends on your device.

MAXLink - this uses the new option in MAX/MSP 4.5 to write externals in java. In the end this makes one of those max objects with two ins and two outs, where the ins let you send dynamic and static data to HUMA, while the outs spit out those received from HUMA. You will need to read the Max documentation to get this going. It's also not really optimized yet, because my Max trial has expired and I'm not going to buy that program... ;-)

LOOPSensor - driver for Cinetix LoopIO boxes, both midi and rs232 versions (www.cinetix.de). These are widely spread, but no longer manufactured. There is a fixly implemented version for the newer rs232 and USB versions.

QTAudioIn, Echo_in etc. - some drivers that just read in audio and generate sensor data from the envelopes etc.