PC-based controllers - bad and ugly, but do they have to be?

[kev-no1987]

I think it depends on the situation you are using the system in. I like using PC based desk for nightclub lighting because with the push of 3 to 5 buttons I can call up any programme on any fixture, so a console based system wont be great for that type of work because unlike most other situation in a nightclub you dont know what style of music is getting played next so you have to make rapid judgement on what to do there and then so not only do you have do operate a sometimes rather large rig you also have to have some LD ablity to look and see excatly what you wont the area to look like but also beaware of what programmes are ready to run next.

 

 

That is why I prefer PC sytems rather than cosoles. altho I prefer having faders and buttons in front of most of the time I have had to learn to get uswed not having this.I also forgot to mention that it an ALS Enigma that we use to run the rigs, its a bit old now but a bloody fantasic piece of gear for the situation it is used in.

[Zak]

I do intend to support arbitrary MIDI and DMX inputs for control. Many in the industry seem interested in milking their products for as much money as they can by making them incompatible with anything made elsewhere. I'm more interested in making a product that's easy to integrate with things customers already own. Personally, all I need for input is a dozen or so faders and flash buttons; everything else, I can run off the keyboard. Of course, I'm not everyone, so any kind of input device I can support reasonably easily will be.

[jfitzpat]

The precision on the Enttec interface I'm planning to use for development is .025s, but I want higher internal precision for the software to make sure long, repeated sequences don't get out of sync. My current timing loop works quite well; it's very good at .01s, and manages to keep the average time correct at .001s, though the timing of some individual events is off at that level of precision. It will be interesting to see if it holds up when I actually hook it up to lights.

 

I'm sorry, you lost me. The Entec limit is DMX. They run slightly slower than the spec allows for all channels (we run shortened packets when a universe isn't full for lower latency (ie, faster response to control changes)).

 

If you calculate data faster than the core packet rate you will generally get jitter in the essentially 'quantized' results. Looping also seems like an odd test. We worried about precision in a lot of other ways. For example, you pre-program an entire spectacular to time code, then the onsite playback is 1% off in speed. The SMPTE trigger points move accordingly, but most systems don't do a true lock, that is, fade times, movement generation, etc. do not shift 1% to match. You can actually see this with some media, so we did a true lock. That is actually hard to do in software alone, since sub .001 second timing adjustments are hard to do (10 mS granularity for PTS is common on a modern desktop OS). This, and channel density is why, we ended up doing our own interfaces at all.

 

Most of your wish list looks pretty familiar. The color stuff is on everyone's, but is surprisingly hard to do well, particularly if you commit to open fixture template support.

 

As far as tactile surfaces and milking money, I again don't follow you. Systems that are simulations of consoles tend to use the same wings - why not? That is how the system is designed and what the interface is coded for. Systems looking to be affordable, like us, accept things like DMX and MIDI (we even have an open API so you can implement other control inputs). Sure, you can argue everyone is crap and you will set the industry straight, but don't think that tactile input will set you apart - besides, there are some disadvantages to generic tactile input. We do occassionally get requests for a custom 'wing'.

 

Good Luck,

-jjf

[Zak]

I'm sorry, you lost me. The Entec limit is DMX. They run slightly slower than the spec allows for all channels (we run shortened packets when a universe isn't full for lower latency (ie, faster response to control changes)).

 

If you calculate data faster than the core packet rate you will generally get jitter in the essentially 'quantized' results. Looping also seems like an odd test.

I don't think it's so odd considering that a chase sequence is a loop with events that need to occur at regular intervals. One of my test loops simulated strobing a set of LED color changers, changing colors at one interval and flashing at a different interval. Of course, it may turn out that I'm crazy, which I expect I'll discover when actually try programming and running shows with my software.

Most of your wish list looks pretty familiar. The color stuff is on everyone's, but is surprisingly hard to do well, particularly if you commit to open fixture template support.

As with most features, simply adding the feature is easy but doing it well is hard. I think color matching is the kind of feature that has to degrade gracefully so that users can add their own fixtures. It's easy to put in a list of DMX channels but hard to develop a color profile. Open fixture templates could be supplemented by generic color profiles - it's not perfect, but it's better than nothing.

As far as tactile surfaces and milking money, I again don't follow you. Systems that are simulations of consoles tend to use the same wings - why not? That is how the system is designed and what the interface is coded for. Systems looking to be affordable, like us, accept things like DMX and MIDI (we even have an open API so you can implement other control inputs). Sure, you can argue everyone is crap and you will set the industry straight, but don't think that tactile input will set you apart - besides, there are some disadvantages to generic tactile input. We do occassionally get requests for a custom 'wing'.

I'm not saying generic input isn't common or that I'm going to do anything different with it. Several people said things to the effect of "please support generic input" and I said I would. I'm not sure about setting the industry straight, but I do feel that I can make a product to fill a niche that isn't being well-served by current products. I might just be trying to move high-end features in to a lower price range, which sounds like a good product strategy to me.

[jfitzpat]

I don't think it's so odd considering that a chase sequence is a loop with events that need to occur at regular intervals. One of my test loops simulated strobing a set of LED color changers, changing colors at one interval and flashing at a different interval. Of course, it may turn out that I'm crazy, which I expect I'll discover when actually try programming and running shows with my software.

 

It struck me as a tad odd because it didn't seem to be either a weak area for existing systems or a practical way to program many things. Let's face it, live performance is seldom machine consistant in presentation. Also, no matter what time granularity you pick you will almost certainly not allow a 100% match with every external time base. The normal approach is to be close and resync on changes. Typically, the things that suffer from apparent timing imprecision are downbeat changes, etc., not repetition.

 

The issue with time matching is pretty simple to understand. Look at it this way, 1/100th doesn't give you any better sync resolution unless your data update rate is 1/100th. In other words, if you ran a timer at .01, but only calculated new data every 10 counts, your ability to be in sync would be seriously impaired.

 

OK, now you are generating new DMX data 100 times per second, but it can only be transmitted to the fixtures 44 times per second (a LOT less if you are using an Enttec "Open DMX" adapter, but let's assume you bought the 'pro'). Now, take a piece of graph paper and draw the two timelines. Even experiment with different 1/100th 'counts' (chase speeds). The net result is what one would expect whenever the data update rate is higher than the data packet rate in a real time system, you get dropped and delayed changes - which makes the lights 'stutter' at some speeds.

 

I'm not saying generic input isn't common or that I'm going to do anything different with it.

 

My bad, having "Many in the industry seem interested in milking their products for as much money as they can by making them incompatible with anything made elsewhere." as your next sentence (in a topic titled "bad and ugly") led me astray... :D

 

ut I do feel that I can make a product to fill a niche that isn't being well-served by current products. I might just be trying to move high-end features in to a lower price range, which sounds like a good product strategy to me.

 

You'd get no disagreement from me. We've followed a 4x capacity for 1/2 price strategy from day one. Higher prices with dongles for keys just doesn't seem sustainable (with LJ and the bottom feeder ripoffs as an example). Also, my first response suggested locating a niche and serving it better.

 

Believe it or not, I'm happy to support other's development efforts. On this forum I've helped folks with everything from split dipless fading math, to interrupt handlers for an AVR. And if you are doing this for fun, I'd say knock yourself out, but have continued to refer to it as a commercial venture. My point is that a decent, full featured, controller is about a man year of engineering investment (give or take). If your business model is the belief that all existing products are "bad and ugly" and will continue to be so during your development cycle, or that no one has every considered faster chases and run into the practical limits of DMX, you may be looking at some disappointment. Then again, everything great has probably had nay sayers, so...

 

Good Luck,

-jjf

[Hambone]

There is SO much scope for software creativity nowadays! I use Ableton Live to sequence and DJ quadraphonic audio (2 decks, 4 loops, live percussion), VJ video to projectors, and control 31 DMX lighting fixtures (laser, 2 scanners, 8 washes, 4 blinders, 4 strobes, 12 LED PARs), a hazer, and two remote PTZ cameras and a visualiser fed into Arkaos. Audio, video, and lighting are all done with one computer.

 

The choice of inexpensive controllers is huge. I'm using a Yamaha 01v and DD-55c, Behringer BCR2000 and FCB1010, and Faderfox LX-2. (A Lemur is imminent!)

 

All lighting (and video and audio) control is tempo-related - NOT time-related. One sequence started will still be in perfect sync 32 measures later, even with tempo changes. LED chases, scanner/laser panning and tilting, etc - in fact, all audio, lighting, and video - always stay in perfect sync irrespective of Live's tempo. Tempo goes down - chases automatically slow down, and video frame rate slows down. Tempo goes up - laser panning speeds up, video frame rate speeds up for frame-perfect sync. A lot of the same CC curves, values, and loops are used for audio, video, and lighting, so they all stay tightly choreographed and in perfect sync. Negative track delays compensate for all levels of latency to keep everything tight.

 

Many of the MIDI controller buttons perform more than one function. I have a library of CC curves, loops, and values that I drew in Live to program the lights, video, and audio. Those curves and values are combined into various drag 'n drop Live sets that are either sequenced or triggered live. Using Live's MIDI effects, virtual MIDI buses and Follow Actions makes audio, video, and lighting as manual or automatic as you like.

 

Some of the lighting sets include Arkaos video so, for example, setting all color washes to red also sets the Arkaos hue effect to red, a 32nd-note snare roll fires the strobes, runs LED uplighters around the room, and toggles the Arkaos negative effect, all precisely on the snare hits, or at the end of a phrase, the blinders and uplighters flash and do a 4-beat fade-out, an alpha-masked nuclear explosion fires on the screens over live video feed, and an audio thunder-type sound effect is triggered.

 

And it can all be sequenced, or played live. I can drag one Live clip into Live, launch the scene with a single button, and all audio, video, cameras, and lighting will do the entire track by themselves (great for a pee break!)

 

You're only limited by your imagination, the inability to let go of the "that's the way we've always done it" attitude, and the realisation that inexpensive, off-the-shelf budget software and hardware can be very capable, even in the hands of an untrained amateur, with a bit of lateral thinking.

 

And with a Lemur and multiple pages of labelled buttons, faders, switches, knobs, etc, all laid out the way I want it, it's going to be even more powerful.

 

Edit: Sorry... got a bit off-topic there, but the point I was trying to make is that software-based hardware control for lighting/audio/video/whatever can be whatever you want it to be. Work your way, rather than somebody else's idea of how you want to work.

[Zak]

It struck me as a tad odd because it didn't seem to be either a weak area for existing systems or a practical way to program many things. Let's face it, live performance is seldom machine consistant in presentation. Also, no matter what time granularity you pick you will almost certainly not allow a 100% match with every external time base. The normal approach is to be close and resync on changes. Typically, the things that suffer from apparent timing imprecision are downbeat changes, etc., not repetition.

With electronic music, it's not uncommon to have some or all of the percussion on a backing track, which has perfectly consistent timing. I'm not sure if it's an important feature for anyone else, but I want to be able to make chase sequences with exactly the same speed.

The issue with time matching is pretty simple to understand. Look at it this way, 1/100th doesn't give you any better sync resolution unless your data update rate is 1/100th. In other words, if you ran a timer at .01, but only calculated new data every 10 counts, your ability to be in sync would be seriously impaired.

 

OK, now you are generating new DMX data 100 times per second, but it can only be transmitted to the fixtures 44 times per second (a LOT less if you are using an Enttec "Open DMX" adapter, but let's assume you bought the 'pro'). Now, take a piece of graph paper and draw the two timelines. Even experiment with different 1/100th 'counts' (chase speeds). The net result is what one would expect whenever the data update rate is higher than the data packet rate in a real time system, you get dropped and delayed changes - which makes the lights 'stutter' at some speeds.

It sounds like you've tried this before. It's entirely possible that I might have to set the interval to 1/40 sec, but I'm going to play with 1/100 for a while before I make that decision. I'll be doing a lot of my testing with Colorkinetics LED panels, which respond quickly enough that any timing problems should make themselves obvious. I did buy the Enttec Pro interface - it seemed like the best option for the money.

You'd get no disagreement from me. We've followed a 4x capacity for 1/2 price strategy from day one. Higher prices with dongles for keys just doesn't seem sustainable (with LJ and the bottom feeder ripoffs as an example). Also, my first response suggested locating a niche and serving it better.

 

Believe it or not, I'm happy to support other's development efforts. On this forum I've helped folks with everything from split dipless fading math, to interrupt handlers for an AVR. And if you are doing this for fun, I'd say knock yourself out, but have continued to refer to it as a commercial venture. My point is that a decent, full featured, controller is about a man year of engineering investment (give or take). If your business model is the belief that all existing products are "bad and ugly" and will continue to be so during your development cycle, or that no one has every considered faster chases and run into the practical limits of DMX, you may be looking at some disappointment. Then again, everything great has probably had nay sayers, so...

 

Good Luck,

-jjf

It's for my own use first; it will become a product if I think it's good enough. I don't expect it to be easy - I've used quite a few controllers and dislike most of them. Making something that satisfies me will probably be harder than making something I can sell. Pointing out potential problems, both technical and business is actually very helpful. Thanks for the input - please feel free to offer more if anything comes to mind.

[Hambone]

With electronic music, it's not uncommon to have some or all of the percussion on a backing track, which has perfectly consistent timing. I'm not sure if it's an important feature for anyone else, but I want to be able to make chase sequences with exactly the same speed.

That's VERY imporant to me. Not only do chases need to be precisely timed, but ALL lighting, video and audio, too. A four-beat laser pan needs to be a four-beat laser pan, whether the tempo is 80 or 200bpm. Washes and video effects that pulse and ease-out on beats 2 and 4 of each measure need to always do so, irrespective of tempo. An audio looped dropped into the rear of room PA must be precisely in sync with the FOH main mix. Video frame rates must track tempo changes precisely, as a lot of the video is choreographed tightly with the audio and lighting.

 

That's exactly why I use a fully-customisable and flexible MIDI-sync tempo-based and NOT a rigid time-based solution. With OSC replacing MIDI's 7-bit resolution, bandwidth, and latency restrictions, it's going to get even better.

[Nick512]

Check out the avo d4 pc system.. runs on any computer with a USB port and windows XP.

 

It has the same power as the D4 Elite and Vision but is a pc based controller.. it has 2 optional USB components too...

 

1 A USB Fader Panel with Flying playback faders which can be quickly swapped to any fader/swap/flash bank anywhere on the desk and the chase/ cue list control.

 

2 A USB DMX/Timcode rack mount unit. Spits out 8 Universes of DMX and reads Midi Time-code. (not required if you want to output data over artnet)

 

The software itself has a very nice built in virtual desk panel.. very handy. I run this on a motion computing LE1600 tablet pc as a tech/second backup.. it copes very well. its handy being able to wander around the stage wirelessly focusing lights where you need them with the full show on hand to test cues.. then just upload the show back to main desk...

 

Avo D4 Pilot System

[jfitzpat]

With electronic music, it's not uncommon to have some or all of the percussion on a backing track, which has perfectly consistent timing. I'm not sure if it's an important feature for anyone else, but I want to be able to make chase sequences with exactly the same speed.

 

Ah, tedious and repetitive lighting to match tedious and repetitive music! Now I see... :D

 

Seriously, I'm still not sure I see your problem (or solution). Most drum machines work in BPMs. 270 BPM is 4.5 beats per second, or 0.22222222222222222222.... seconds per beat. Using .01 seconds, your closest interval is .22, or approxmiately 272.73 BPM. If you lean towards looping, over discrete triggering, you'll still drift over time.

 

-jjf

[Zak]

Ah, tedious and repetitive lighting to match tedious and repetitive music! Now I see... :D

Where do you live? If we have a show nearby, I would strongly encourage you to come and decide for yourself if anything about it is tedious and repetitive. I know a lot of electronic bands are tedious, but I don't really care as long as they buy my product. :D

Seriously, I'm still not sure I see your problem (or solution). Most drum machines work in BPMs. 270 BPM is 4.5 beats per second, or 0.22222222222222222222.... seconds per beat. Using .01 seconds, your closest interval is .22, or approxmiately 272.73 BPM. If you lean towards looping, over discrete triggering, you'll still drift over time.

My solution, at this point is to have the timing loop resync by comparing the step count to the BPM value and the clock. MIDI and audio triggering will almost certainly make it in before I release anything as a product, but right now I'm just getting the basics right. My DMX interface should arrive tomorrow, so I'll be able to see how well this works in practice.

[Hambone]

I realize I'm the ignorant amateur here, but why does timing resolution matter? Do desks work in seconds, and not BPM?

 

I can set any tempo, and everything stays perfectly in sync. A loop can run indefinitely, even with wild tempo changes, and still be in perfect sync. No drift. No retriggering necessary. A 4-beat pan/fade-out/etc automatically takes 2 seconds at 120bpm, and 4 seconds at 60bpm, etc. All timings stay tied to the tempo, even during tempo changes.

 

Maybe I'm missing something... I've probably got just enough information to be dangerous! :D

[Zak]

I realize I'm the ignorant amateur here, but why does timing resolution matter? Do desks work in seconds, and not BPM?

Some only use seconds. Some support both. I've never seen a desk that used only BPM for timing, but there's probably one out there somewhere. Some display the output in both, but have fairly limited resolution (e.g. you can have 120 bpm (0.5s) or 109 bpm[0] (0.55s) but nothing between).

 

[0] It will say 109. 0.55s is actually 109.091, and I'm guessing that's what's really being used.

[jfitzpat]

Maybe I'm missing something... I've probably got just enough information to be dangerous! :D

 

Because you are driving everything off one source. The issue is 'looping' based on an internal timebase against an arbitrary external source. A good example would be to try to set a modern drum machine to match an old LP, even on a track that was originally laid down against a click track it is often impossible to get it exactly right. That is because there were inherent timing errors at several steps in the tape->master->LP->record player system.

 

My understanding is that you construct a library of time independant sections (you may create them all at 120 BPM, but you do not nec. play them that way). As long as everything is driven by the same timing master, it should stay in relative sync. You may recall that I've long suggested that you consider triggering a lighting system via MIDI, instead of driving DMX from MIDI via a direct conversion. However, the only reasons behind this suggestion are ease of editing, access to all possible DMX values, and avoiding MIDI bandwidth choking (the baud rate is 31K vs. 250K and the messages are three times longer). The timing from the MIDI system is generally close enough, and there are no accumulative errors.

 

The core issue being discussed is that Zak contends that looping is too course on existing boards (nominally using 1/20th and 1/30th of a second type resolutions). He thinks that 1/100th of a second is going to be vastly superior. I contend that there are two problems with this. First, 1/100th still won't exactly match external time bases much of the time, that is, looping will still have inherent drift - the tightest possible lighting will remain individual triggerred events. Second, he will run into the inherent problems that occur when data update rate exceeds data transmission rate. If you are generating DMX packets 100 times per second and transmitting them 44 times a second, you are going to get aliasing at higher 'chase' speeds, as well as jitter in things like automatic movement generation.

 

-jjf

[Hambone]

How would linear/exponential/ease-in/ease-out/etc CC curves for pan/tilt/fades/etc stay timed using a MIDI-triggered DMX desk or Bluelite? Everything is perfectly compensated for now the way I'm doing it now. Would a DMX desk or DMX software speed up or slow down internal curves depending on an incoming MIDI tempo?