All the Realizer its configuration files are located inside the application bundle. Browse the bundle its contents by "right clicking" on the Realizer icon and selection "Show Package Contents" from the popup menu. All configuration files are in XML and can at this moment only be edited by hand. N.B. Editing XML should be done very carefully, because invalid XML might make the Realizer fail to launch.
"osc" :
specifies at which UDP port the Realizer receives "Open Sound Control" . Read here, open sound control, how OSC is implemented in the Realizer.
"control" :
specifies which TCP/IP port Realizer clients can connect to for XML communication. Have a look at the full specification of the Realizer protocol.
"output" :
Is used to specify a list of settings for subsequent image outputs. The "nr" attribute specifies which output is concerned, outputs get numbered in order of their creation , the "nr" specified as "x" contains the settings for any unspecified output numbers. In other words, it is specified here what kind of output gets created each time a module of type ImageOutput is instanciated.
Considering the settings listed above, the first output will be a window sized 640x480 at position (100,100) in your screen, the second output will be a window of the same size at position (500,500), and so on....
At this moment the only implemented kind of image output is "window". In the future it will be possible to output to streams and files.
In a multi-user environment each user should then be able to decide indepently what to do with each output.
"size" :
Specifies the default size of image buffers. Modules that generate image content (BGColor) should do this at the size specified here. Also the "Image Compositor" module renders its output at this size. In general the values here should be the same as the values for your main image output (Window).
"maxfps" :
Specifies the maximum amount of frames per second. Can be used as a frame rate limiter to reduce the amount processor usage. In general rendering at speeds higher then the refresh rate or your monitor makes no sense.
"device" :
Specifies what audio hardware the Realizer should look for. When the device cannot be found, the Realizer will use "Built-in Audio" as its output.
"samplerate" :
Specifies the prefered samplerate. When the hardware doesn't support this sample rate, the device its default sample rate will be used.
"buffersize" :
Specifies the prefered buffersize, When the hardware doesn't support this buffer size, the device its default buffer size will be used.
"channels" :
One audio output is considered to be a stereo output. Each time an audio output module gets created, the "next" two channels of the hardware will be mapped to that module automatically.
Later on a system for mapping outputs, similar to that of the image outputs, will be implemented.
Inside the Resources map you'll find a map named "osc-module" , which contains definitions for OSC receving modules. You can define your own OSC receiving module here. OSC modules are the only modules that can be defined by just adding an XML definition, without writing code, since they are all mostly the same. You can make your own to be able to receive OSC from a specific device or just to create your own address space.
The easiest way to do this is by copying an existing definition, for example "my_osc-mod.xml" and renaming the file to the "your_osc_mod.xml" . Then open the file in an text editor , like BBedit or TextEdit, it will look like this:
First replace the module its type "my_osc_mod" by "your_osc_mod" . Then define an "attribute" element for each OSC message you want to receive. The my_osc_mod module receives at four different addresses, but you can define as many as you want as long as their names are unique and of course the address must meet the syntax for OSC addresses. Put the exact OSC message in "default" and define in "name" to which output the data should be mapped. Finally make sure you define an "output" element for each "attribute" element. The "name" specified here must match the name of the according attribute.
You will now be able to send osc to the specified addresses and when you will instanciate the module it will output the values through the right outputs ... duh.
Sending xml messages via telnet can be considered as the lowest level interface to the realizer. Although it is a very user unfriendly interface it proves itself handy for "debug" purposes, because all response messages of the realizer are directly visible. The next listing shows an example telnet session to a realizer running on "the same" machine:
