Field Desk Front View
Field Desk Rear View
4 * Milennium 4KW , Space Cannon; single on ScanCo, focus on Goldelse
12* Focus , Space Cannon; single on ScanCo Extension, focus on Siegessäule Body
both © www.techno.de
4* Black Devil , Space Cannon; paired on ScanCo, focus on DJ Towers
8* Target , Space Cannon; paired on ScanCo, focus on DJ Towers
There were a lot more fixtures, some speakers and cameras which are not part of this documentation. Contact loveparade.net if you need more information.
with usb on board, Mac OS 9.2, USB-DMX Device and MPW for production
mentioned software is written by Hado
The USB-DMX Device is new, the main goal was to see if the Device runs with a Mac over a longer show.
Therefore the first point was to do a setup where a bombed Mac will not halt the show cause the desks' data is not sent out. The cabeling shown in the above picture shows how to set up safely.
In this way the USB-DMX device is the first sender on the line. So there arise two ways of controlling the lighting. In first the user may send DMX data from the Mac. Guess, if nothing is set in the transmitter the device happiely sends out all 0 frames. The USB-DMX device sends out the full frame rate. The second way is to use the first transmitter on the DMX bus to trigger remote events on following DMX devices. This was used.
Then the data is routed thru the ScanCo Extension, which may change all values and if merges its output htp into the data stream.
Same happens in the following ScanCo. This routing could be done similar with all desks that support a DMXin.
.Display Live ends in drawing from pointer needing offscreen
.Manipulate ends in driver extension doing control after start ta and changes limited in input frame and sending mem as result
.Limit ends in control run in driver and pasting frame data into txmem
Above notes be will explained later in detail. Basically the main application does nothing else then finding the driver in the system and accessing private data of that driver. For experts : USB drivers are typeof 'ndrv' creator 'usbd'. This fragment exports a symbol named 'apicmds' which you can FindSymbol() in the system zone.
With these accessors the application can manipulate almost everything in the driver. The application source is available here. The USBDMX works like a dongle (connect it to run).
First you can set in the mode menu if the driver runs in copymode. Which means that the received DMX data is copied to the transmitter and transmitted there. This read/copy/write cycle can run up to 64 Hz, while the maximum dmx cycles can be 44.11 Hz. So if you want to do other processing between reding in and sending you can do.
You also may set the startcode of transmitter and receiver which gives the possibility to transform incoming data to another startcode. Also the number of sent channels on the transmitter can be adjusted.
Notable is the following : You may not start without connected USBDMX, but then you can unplug the device and replug it without problems. The application does not bomb cause the applications process has also a valid connection to the drivers' code fragment. When the device is reconnected the cfm manager does not load a new copy of that fragment - but the usb id counts up one. When you quit the app the fragment gets unloaded by the system and needs to be loaded again by the UIM from usb manager cause the app starts only if the fragment is findable. A stub fragment to run without attached device is not available from me. In this way it is not neccessary to install all notifications.
Special : Morse
taken from http://www.vectorbd.com/bfd/license/stmorse.lzh
As a special for the parades' spirit I invented a function in the application that sends out morse code on a channel.
Instead of using a sound information carrier the Milenniums focussing the Goldelse were turned on and off accordingly so that the information was carried out by the light being on/off.
If you look at the source code you can see how trivial that is. I got some older (dr gem) source for encoding morse and adopted it to MPW C++. Instead of generating a tone on/off i poke 0/255 to the last channel of the transmitted dmx channels. (i.e. Ch. 512)
Then I set the ScanCos to allow dmx remote and assigned a brightness master to Ch. 512. So it was possible to push a flash button on the desk with the Mac. Or to be more precise : Trigger a brightness master to go to full. The application source is available here.
So when send morse code is choosen from the Specials menu the Mac starts to alter a special DMX channel in the USB-DMX transmitter which goes thru all propieterian control desks - which in turn react accordingly to their remote control setup.
What you invent here is just limited by your coding knowledge.
Other possiblilities seen from the lighting designer point are matrix pictures as seen for example in older AC/DC videos. You rigg a line of bars and try to display text or something like this. (Take a look at blinkenlights.de for your inspiration) So you just drop a picture onto the window and according to the pixels in the picture the application calculates them down to your dmx. A more sophisticated version may do the same thing with cmy systems.
Let's say it this way : Cause of obvious reasons noone really invented the functionality of lighting desks on a PC. Especially the data encoding (in the raw setup you have a keyboard and a mouse) is always getting a problem. On the other hand -if you're able to code- it is no problem to write very special functions like morse or range limits. As long as you keep in mind that these things are _handmade_ and usually for one show. In this point you incorprate the USB DMX as your lab device, measuring also, into your dmx and do these special functions there. As always the User Interface (aka Windows, Controls, Buttons) is much more work than doing the raw functional code.
Especially while the Mac machine also can play streamed audio and video while doing DMX. To start things like that only a few lines of code are needed; To start it with a button a lot more lines of code are needed.
.powerfailure safe pic
.software / system failure safe in way of dmx512
In the lab setup the Mac was used as an very expensive DMX tester with an colour display. To see what is sent out. This means that you are free to run the application to see a real DMX window or use the other setup where you receive data and manipulate it and write it out again. In this setup you cannot send remote signals to the desks cause you receive the desks' data and send it out again.
.powerfailure safe easy one
.mac display flickers not drawing offscreen, necc seen for seperating that function from wne loop, mpthreading to time costly
This application does the drawing during the wne-loop. Of course you may invent it under carbon with a timer; It runs fine in the lab style where drawing inside this window is done from the wne-loop completely ignoring update events. When you have to draw the whole picture anyway do it right from the event loop, cause bracketing with BeginUpdate()/EndUpdate() needs inval'led update regions. This works, too. But wastes more cycles.
Doing the drawing from an mp task or seperate thread is not very clever cause you cannot control the current graphics port.
.counting dmx frames is funny
.processing speed would last for lookuptables and other stuff in gui, processing
Which is in fact the point not to display the dmx values and instead lookup in a library what text name this channel would have (iris of devicetype of manufacturer).
.compress dmx frames (nochange) valuable for sending
.statistics fps on machine, on device, accfunctioncalls
1206806-1106160= 100646 Frames / 44.11 Hz = 2281,7048288 Sekunden / 60 = 38,028413814 Minuten
This should be within the tolerance that the Scanco does not transmit at 44.11 Hz which would be as fast as the USB-DMX device. Losing 100000 frames in 7.5 hrs is not worth mentioning it. The Wholehog 2 was measured at another show with 30Hz. And 30Hz last for TV.
1206806 Frames / 44.11 = /60 = /60 = 7,5997254339 hrs, good working day for an operator
.Limit in driver as extenion in some way
The limiting can done more safely in the driver _after copying_ from rxmem. Cause a user can write into txmem also there wouldn't be a limit in all cases. Doing it in the driver preserves limit to be the last operation before sending.
.Lookup after patching to onelistperdevicewithtokens
This is an appl task. You have 512 values and in some structured list with variable length items text to draw instead of the value.
.Lock,Park in driver outchannels
Instead of Limiting locking (aka parking) prevents from a change. As seen in the Milennium setup locking is limiting to one value.
.intelligent Merge , more devices , setpriority in driver machine,processor,device input
Ends up in the driver looking up in tables what to do. Also there are Ethernet devices available that do the same like the USBDMX in various other flavours.
.Tabletitles / Channeltitels in display win
The same for colums and rows title like the above lookup after patching
The fourth dimension is the time. This applies to almost all coding. What time and at what time in the machine does this code run.
As a DMX display the mac is fine. It's much more convinient to have both universes (in/out) in one 800*600 window then to page thru DMX in a DMX tester.
The system itself is working. It may be able to replace a lighting desk - but whatfore. It's much more interesting (and also an old Mac way) of enhancing lab devices. With a PC you may control much more convinient then with fixed accessoire devices in the DMX bus. Limiting with an min/max range is easy which means that you once limit movement channels behind the desk and can run your saved shows cause when the movement comes to a forbidden range the PC limits that value. Visible feedback could be done, too.
Realizing special effects has got much easier now - as seen with the morse function.
Photos (c) Hado Hein, Berlin, Fed.Rep. of Germany, 2002 except where otherwise stated.