HUMA: Manual under Construction Introduction

HUMA is about interactive video, sometimes also called hypervideo. When you think of interactive video you probably think of web multimedia, but that is not exactly what we mean (allthough HUMA can also help you a lot in creating just that). HUMA's main purpose is to provide the tools needed to solve the technical issues in both creating navigateable video with no visual cuts and taking it away from small computerdisplays into the room, where it is then made accessible by other interfacing devices than the mouse: mostly sensory systems like motion tracking cameras, laser scanners etc, but also non standard haptical devices. A lot of terms have come abroad to describe the endresult: interactive environment, reactive video etc. and a lot more probably will. HUMA has grown from artistical projects and is constantly developed along the needs of artists that use it in their projects. The common vision throughout these projects has been to use the imagery and content of running movies as an interface to their extended content, which can be made instantly available by the backing realtime reediting system that the software offers. HUMA supplies you with both the sampleplayer and the sequencer logic you will need for such projects and may thus be used as the technical basis for projects that deal with lots of apects of interactive and realtime manipulated media: ranging from simple VJing tasks to digital story telling. 
Having said that, it should be clear that a HUMA project is not a readily edited movie, but more an assembly of media samples, loosely bound together in so called scenes - one of the software's key organisation principals - and connected by paths laid out by the author. This may look something like this (giving only a tiny excerpt of a structure that can grow to enormous complexity when the number of scenes grows):

A HUMAmovie consists of scenes as any other movie does, the difference is: HUMA scenes are not lined up on after the other, but may follow each other in any possible order, be repeated and modified during presentation. HUMA has no mastertrack or general timeline that lines up the various samples, but allows to create new combinations of timeline fragments and paths through its scenes on every run. This is achieved by keeping all sequencing information sceneindividual: all playback parameters, in- and output devices and interactive functionality may change with every scene. Combined with a flexible linking architecture - every scene can under programable conditions switch a not really limited number of followup scenes - one can create evolving movie spaces, that users may interactively experience. Along with the build in support for a wide range of communication protocols and integrated drivers for dedicated sensor hardware this makes HUMA the tool for the creation of interactive media installations and environments.





The whole HUMA architecture consists of three separate pieces of software: First there is the authoring tool, called HUMAtagger. On presentation its the HUMAruntime that will play the project and beside those two main components there is a little interfaceless server application - HUMAserver - which is only needed when multiple runtimes are to be connected to a networked system.



Background: HUMA is based upon Apple's Quicktime technology. You may only be familiar with Quicktime as a web browser plug-in or as a small mediaplayer application, but it is in fact the media engine behind a whole lot of video- and audio editing applications and other multimedia savy software - almost any on the Macintosh and quite a few on Windows. While Quicktime may not be the spearheading pioneer in supporting modern video codecs and (related with that) may be beaten in terms of performance by other media APIs it has a number of advantages, that made it the foundation of HUMA: First of all Quicktime has an incredibly flexible file format (which has shortly become the basic for the mpg4 specification), that HUMA makes wide use of - a HUMA project is basically a .mov file packed with metadata. Second Quicktime's diversity in the support of media formats it can play and display is simply unbeatable and third there is a solid foundation of interactive features and some incredibly widely thought underlying concepts build into the Quicktime API that HUMA partly uses, partly builds upon - it is because of that, that - allthough the greater part of what makes up HUMA is very custom - you may also use the HUMAtagger as a general Quicktime editor and especially as an editing tool for interactive web video. The Manual will mark program features that can be used to create stuff playable in the standard Quicktime player and plug-in where they are covered.


Important note:
This manual is currently undergoing basic renovation. You will recognize new and up to date files by the screenshots. The older ones may not show the current state of the software and give false information at points. They are left in here for now as they may still explain some of the basics.