DMX control program: It's time.

[jumpjet]

So, the Enttec USB to DMX dongle has been out for over a year now, and still, I haven't found a decent program that takes advantage of it.

Unless anyone has any suggestions of an ongoing project I can help with, I will write my own. There are many features I find lacking with almost every board, and especially with those that are free.

With a free, open-source console that runs on windows or linux, any school or NPO could be up and running for under $100 bucks if they could get their hands on a computer.

What I am looking for from this community is a list of features that you would like to see. My intention is to make it modular, so that you can run it in various modes depending on your needs. Please list both features that you have seen other places, and those you haven't.


Features that I want:
Runs on Windows and Linux.
Compatible with the Enttec USB-DMX dongle
Unlimited channels
Unlimited dimmers (limited by the number of USB-DMX converters)

Simple mode and expert mode (Simple mode being several buttons that have preset scenes that would be used for band concerts, simple presentations, etc.)
Module for 2-scene preset
Module for recorded cues
Module for submaster pages
Listening from DMX devices for feedback.
Audio triggering of cues/chase
Tap rate for cues/chase
A better macro language (variables, for/next and do/while loops)
Show/scene timer (for comparison of what was shorter/longer between runs)
Record lockout
Ability to record show separate from settings, on multiple removable media options (Floppy, Hard drive, usb key)
undo function
Moving lights capability (similar to Hog, but there are some issues I have with that as well)
Tracking or non-tracking
USB output to control other devices/computer(for instance, to trigger a powerpoint slide in a cue)
Control via keyboard, mouse, joystick, trackball.
Ability to add new DMX controlled items via downloadable libraries
Intelligent control for odd DMX items like fog, hoists, etc.(Hoists would show speed, feet decended/remaining. Fog could show volume, chiller fan speed, etc.)

I'm not sure what kind of data is reported back from dimmer racks, but it would be handy to be able to parse that data as well. I believe sensor+ connect allows you to retrieve data through a cat-5 cable...

It seems that the true power of a program comes many times from plugins that are written by the community. I would like this to be included as a feature as well.



Extra goodies
-------------
Video Input
Metering of audio mix
Timecode smpte
Remote control via ethernet
Expandability to remote stations including video output, go/keypad, Remote lockout from master.

It would be interesting to experiment with an algorithm that based on where lights are, and how they have to be oriented to hit the same spot on stage, the computer could determine what the other lights have to do to hit the same spot. This would eliminate the need to record positions, merely tell the instruments where on stage you need light.

[jumpjet]

One other thing I would like to implement would be a skinning feature that would allow you to have various themes that emulate popular consoles in look and function.

My concern is where this might impact copyright infringement.

All thoughts are appreciated.

[soundman]

Have you looked at magic q by chamsys? the link is http://www.chamsys.co.uk/ It is what I use when I get a chance. My experince is limited to a few hours in real world stuff but I have played around with it offline with capture quite a bit.

[koncept]

keep me informed, i would be very interested in the final and would be glad to help with the programming if it is in a language i am semi familar with.

[jfitzpat]

Originally Posted by jumpjet

With a free, open-source console that runs on windows or linux, any school or NPO could be up and running for under $100 bucks if they could get their hands on a computer.

We certainly share your sentiment. Entry level for us is <$300 (though that does include DMX in, for tactile input from existing controllers and a SMPTE generator/reader) and that can still be a struggle for some schools.

Speaking as a commercial vendor I think that the two reasons you aren't seeing a lot of killer products for the Enttec are:

a) Implementing the functionality of a major console is a much bigger project than it first seems - especially good support for intelligent fixtures

b) The Enttec dongle itself

Project size is neither here nor there, but man-years do go into some controllers. That is hard to do by one person as a hobby and, once the project relies on a loose collaborative group, you get the extra overhead of working by consensus. This can make a big project take awhile.

As far as the dongle, the real issue is the division of labor. The dongle is cheap, but uses a serial/USB chip. This makes it appear as a 250 Kbit UART com port under, say, Windows. This both creates some unnecessary end-to-end data delays and it also puts some additional CPU overhead on a non RTOS platform.

The dongle is, I believe, also half-duplex, so while it might be possible to support RDM with some additional resistors, it does not lend itself well to simultaneous control output and data input.

At least one hobbiest has created his own variation of the dongle which is an in and an out. We still could not use it because of our latency, total channel density, and data update rates (ex. we wanted a higher than usual data rate to support smoother control of video/media servers) but, like the Enttec, a small system could certainly be built on it.

He started (I think) in '04 and has been trying to get a collective effort going. He has a 'wiki' for specifications (with links to his overall project) here.

Originally Posted by jumpjet

It would be interesting to experiment with an algorithm that based on where lights are, and how they have to be oriented to hit the same spot on stage, the computer could determine what the other lights have to do to hit the same spot. This would eliminate the need to record positions, merely tell the instruments where on stage you need light.

You might consider supporting CITP, the open protocol from Capture (www.capturesweden.com). If use the selection protocol and accept DMX in both directions (like we do), you get a very integrated user experience. You can then use the 'focus' tool to point and click on the stage.

Of course, Capture is a commercial product. But CITP is open and other vendors have talked about supporting it. Also, you could start a seperate open source visualization effort and use CITP (one benefit is that it allows you to run on either the same machine or seperate machines - doing good visualization can be very CPU intensive so it is sometimes nice to have the jobs split).

Good Luck!
-jjf

[jumpjet]

Thanks for the input guys!

jjf, I have a few questions for you. The issues that you refer to with the dongle: Does that refer to the open source dongle, or the USBPRO version?

I'd like to undertake the project without significant limitations, like the speed.
What speed is acceptable for the video/media servers. I believe that the pro version supports up to 40 Hz.

On the website, it says that the pro version has:
# 1 Input & 1 Output connector (there is only one DMX port though)
# RDM (talkback) compatible
Will talk at any comm's speed, compatible with any system for which the FTDI chip has drivers (Windows, OSX, Linux..)


Hrm....

[jfitzpat]

Originally Posted by jumpjet

Thanks for the input guys!

jjf, I have a few questions for you. The issues that you refer to with the dongle: Does that refer to the open source dongle, or the USBPRO version?

I'd like to undertake the project without significant limitations, like the speed.
What speed is acceptable for the video/media servers. I believe that the pro version supports up to 40 Hz.

On the website, it says that the pro version has:
# 1 Input & 1 Output connector (there is only one DMX port though)
# RDM (talkback) compatible
Will talk at any comm's speed, compatible with any system for which the FTDI chip has drivers (Windows, OSX, Linux..)


Hrm....

With DMX systems there are really three speeds to consider:

Packet Rate
Data Update Rate
End to End Latency

The first speed is limited by the standard and varies based on the number of channels. The connection is a 250 Kbit UART stream and each channel takes 11 bits (1 start, 8 data, 2 stop). So each channel takes 44 uS (0.000044 seconds) to transmit. But not all 512 channels need to be sent. So, if you send 32 channels, the data is transmited in about 1.4 mS (0.001408 seconds). If you send 512 channels, it takes about 22.5 mS (0.022528 seconds).

In addition to the channel bytes there a serial 'break', a required 'mark-after-break', and a one byte start code (typically zero). So each DMX packet requires another 140 uS (0.000140 seconds) of transmission time. So, adding this in to our transmission times we get a max packet rate for 32 channels of about 646 times per second and a max packet rate for 512 channels of about 44 Hz.

Good controllers *always* send DMX packets at the max possible rate for the number of channels used because DMX packets *HAVE NO ERROR CHECKING*.

Bit errors are pretty much unavoidable, so always transmitting at the fastest possible packet rate cuts down the amount of time dimmers and fixtures are responding to bad data. In other words, transmitting faster does not effect the incidence rate of bit errors, but it does diminish how long bit errors are displayed on stage. If a 0 becomes a 128 (one bit error), and the update rate is hundreds of times per second, a dimmer flash will not be normally seen. If you are only sending packets 12-15 times per second, a dimmer flash will typically be visible to the audience.

It is hard for Enttec based products to send at the max speed for 512 channels, let alone 128 or 256 primarily because packets and framing are done in application space on a non-RTOS system. This is probably not a big deal for a small rig, especially if it is running a fairly spastic dance floor. But it is a real concern with larger rigs (more cabling and electrical noise to generate errors) and situations where the audience is focused on a specific point.

Data Update Rate is how often a controller generates new data for the DMX packets being sent. Think about it in terms of a 3 second dimmer fade. If you calculate new data twice a second, a fade from full on to off would take take 6 'steps' in our fade - no illusion of a continuous fade to the human eye. If you generated new data 15 times a second, the fade would occur in 45 steps and to the casual user would look fairly smooth, since about 12 Hz is the average human perception rate.

However, most good desks for intelligent fixtures use data update rates in the 20-25 Hz range. This is because there is no standard for motor speed channels, so instead of adjusting an instrument's own speed control, motors are left at 'full speed' and the consoles generate more steps to generate smooth moves at various speeds (humans seem more velocity perceptive than intensity perceptive).

However, unlike a motorized head, media servers tend to move images, etc. 'instantly' (no mechanical dampening). So we selected an update rate of 30 Hz to accomodate the faster 29.97 video frame rate here in the US. This makes console generated movement smoother in generated video (ex. flying a logo around a video screen).

The big problem most Enttec based products have isn't that the data update rate is too slow (though the ones we have looked at all seem to be pretty slow), but that the update rate varies considerably based on workload. Ideally, generated movement and fades should not get 'jerkier' because a user opened another Window, etc. Again, a small rig, 8 bit fixtures instead of 16 bit pan/tilt, less scrutiny, etc. the less this matters.

End to End latency is the interval of time from when the user inputs something and the output is reflected on the DMX stream. Data packet rate (described above) plays a role, since you can't get new data to a fixture until the old data is done being sent, so the Enttec products already take a bit of a hit. But they also get a hit from the additional overhead of using, say, the Windows COMM stack. It isn't that the extra buffering and copying of data take that much time (though every little bit adds up), but that the que system makes the latency 'dither'. In other words, if a board is a bit slow - but consistantly slow, a good operator will compensate without even really thinking about it. But if response time varies, a good operator will sense the responsiveness as being poor even if the average latency is relatively low.

Again, how-good-is-good-enough varies. We have a user who splits laser tables off to seperate universes (fewer channels, higher DMX packet rate) when they want to 'play beams' live in a large space. That particular operator believes that there is a qualitive difference in cutting the 1/44th second 'dither' inherent in a 512 channel DMX stream to a 1/600th second (or whatever) dither when it comes to his live beams in an arena setting.

None of this means that you can't do a decent controller with the Enttec adapters. Just that there are reasons why the 'clone' products based on it have more channel, fixture, and etc. limits than the originals.

Good Luck,
-jjf

[Pie4Weebl]

wow this sounds pretty cool, make sure to keep us posted on what progress you make.

[jfitzpat]

Originally Posted by Pie4Weebl

wow this sounds pretty cool, make sure to keep us posted on what progress you make.

Well, we've been shipping for a couple of years...

-jjf

[jumpjet]

You raise some great points!

First, the issue of the packet rate. If I understand you correctly, this is an issue inherent with the operating system. I wonder if increasing the priority of the application would help at all in windows or linux based environments.

Another possible solution would be to get an open-source RTOS that is compatible with i386 processors. This way, it could be crated up with the program on a boot disk. No installations, no muss, no fuss.

The data update rate might be ok. On the Enttec website, they quote the "refresh rate" which I'm going out on a limb here and hoping is the data update rate. They say on the pro version it is 40hz. I wonder how much the rate varies based on workload, and how much it can be minimized.

I can't speak to end-to-end latency, and can only hope that it is minimal...

I also can't plan for too long consistantly without coding SOMETHING. So without further ado, the very first preliminary barebones of this project.