## derived from a three-part email series to the technical ## support department at Chauvet, February 2016 This is a review and analysis of the Chauvet Stage Designer 50, which I've been evaluating under test conditions in the shop. While the basic functions are relatively straightforward, this isn't necessarily a board you would want to hand to a less-experienced production tech and expect completely smooth sailing. There are some nasty subtleties and annoyances, not to mention a few outright bugs, in its operation that can really bite a user in the butt if they aren't quite familiar with them in advance and know what situations to avoid. You will find that various online forums give the manual fairly poor reviews, calling it confusing and badly written. I tend to agree, and I've been comparing the revision 9 against revision 10 to see if any of the problem areas have really been addressed. A lot of information is still missing. It takes a lot of screwing around with the actual product to really understand how it works, some of which causes one to sit there wondering what its designers were thinking. So this is the "annoyances" section. I expect that you will forward this around and bring in the appropriate TECHNICAL resources to respond to these and take the suggestions under serious advisement, because fundamentally you've got a very nice product here and I'd love to see it improved with regard to usability. I would also be happy to put any firmware revisions that emerge to rigorous third-party testing in the lab here. I was told that your development group is not located offshore, so this should make your process a little easier. But what about your documentation group?? How much experience with other lighting boards and the surrounding industry do they collectively have? First thing that's in an operator's face on powering up the board is those incredibly bright red and yellow LEDs. The green ones are dimmer at a more or less acceptable level, but in a darkened booth it is impossible to see past the red or yellow to actually read the silkscreen labeling on the front panel over a fairly large radius. Evidently the LEDs chosen are somewhat mismatched to this application, so either larger dropping resistors for them or different LED components would mitigate that. The user syntax for editing scenes is ridiculous. First, stepping through the chase to find the right point does *not* show which step you're at in the display, which it should. Then, there should be a way to view the *present* level of any channel before deciding to move it up or down; as it comes the only way to see the level is to hold UP or DOWN and start modifying it. The way it should really work, which is how it's done on any number of other products, is that the *slider* can be used to modify values directly which would be far faster than the button syntax. Tapping the bump button could show the level, and moving the slider should "grab" the level once it matches the set value and move it from there. Look at just about anything from Leprecon for an example of the right way to do this. When running in "scene" mode, moving a scene's slider should *not* display the changes as the *channel* that would be there in different modes. How about having it say "SCN" instead of "CH"? Displaying the "beat time" of any recorded timing would be useful as well. What displays right now is totally useless. When percent-mode value display is selected, that should be indicated! Where there's room for a three-digit DMX value, there's also room for a "xx%" notation which would clearly indicate that it's in percent mode. It could run up to 99% and then change to either "100" or "FL%" to show full-up. Or shift the "VALUE" and what comes before it leftward a space or two, and give the level four characters' worth of room. It's not like you need so much room for the channel number anyway. "Add kill" should really be called "solo" like it is on other boards, as that's effectively what it does and that's more standard nomenclature. Also, "blind" and "home" are rather mis-named functions as they mean very different things in the typical theatre environment. How about "enable" and "disable"? Rebinding a channel to an AUX knob, especially in function 2, also disables the blue channel "mimic" LED when it's brought up with the AUX but leaves it bound to the now non-functional slider. The mimic should work along with the AUX instead, and always indicate that *true* channel's output even when it's controlled by the AUX instead of its original slider. If you think about it for a while, there's a lot more you could do with those AUX encoders as a general-purpose input device. Setting levels, patching to more than 48 DMX channels, any number of more sophisticated functions. Dedicating that sort of hardware to seldom-used functionality seems like sort of a waste. The manual, and in fact the product spec and promotional material, is very misleading about there being another set of "pages" under the A/B shift. First off, the word "pages" is confusingly over-used to mean two different things. The A/B channel range shift is commonly called a "bank", and the different sets of scenes/chases/submasters/whatever are traditionally grouped into "pages". *Please* clarify that in the next rev of the manual, if you make NO other changes to it. And there is *not* a complete second set of four scene pages under the "B" bank, as the manual and advertising tries to assert. Running scenes/ chases under the "B" bank appears to give a duplicate set of what's under "A", but with rather confusing behavior that could have an inexperienced operator staring at a brightly lit stage saying "but I pulled everything DOWN!" Besides leaving things held in weird states when switching between A and B, there is at least one outright *bug* in scene/chase operation as regards bank switching. [I'm henceforth refusing to call the A/B channel-range distinction "pages", where "pages" to me means the 1/2/3/4 selection of scene groups. I'll call the 24/48 ranges "banks", as described earlier. While the rev 10 manual has a note about that, why didn't someone simply *fix* the terminology throughout instead of making excuses for a poor choice?] Maybe you already know all about this bug, but on a larger rig it could really screw someone who doesn't expect it... Repro: Put a fixture on DMX address 1, and something else on any other channel. An RGB LED unit starting at 1 is fine as a demo, as it'll have at least channels 1 thru 3. Bring up channel 2 for the green, and record that as a one-step chase aka static scene on lower slider 1. Bring down the original channel and run the scene up and down to make sure it's working. While still in scene mode, switch to bank B. Try that scene 1, and you'll find that channel 1 *also* comes up and you've got red and green lit. To generalize, if a scene is used while switched to bank B, the corresponding channel with the same number as the scene slider also comes up, even if it's not programmed into the scene at all. In fact, there doesn't even need to be a scene on the lower fader at all, the extra upper-row channel comes on if the lower-row scene slider is moved regardless. This is a BUG in operation, and should never happen. As long as that pathological scene-plus-stray-channel condition is run up, leave it up at some level and switch back to bank A. The scene immediately goes out, but then if the slider is moved *at all* it suddenly pops back on at the same level but without the stray channel. Bring it to a different level, and then switch back and forth between A and B. Try going to different levels in each and see what happens as you switch banks. It's the same scene, but semi-persistently left at different levels as banks are switched back and forth. Now, here's the real kicker: with that stray channel 1 still lit, switch to 2-scene preset mode and then back to bank A and then try to get rid of it. The bug evidently has something to do with how the lower sliders are mapped in 2-scene preset mode, artifacts of which still hold on when the board is in scene/chase/submaster mode. The stray channel goes out when moving to "channels" mode but comes right back in any of the other modes, until A or B is swapped to appropriately and the slider wiggled to regain control. The problem appears to have something to do with confusion in slider mapping between scene/chase mode and the upper/lower "crossfade" mode. Play with it a bit -- it's confusing as heck and I'm still not sure I've got the description completely correct here, but it *is* a problem and clearly not an intentional or consistent mode of operation. The workaround is to never run scene/chase mode in bank B, and from this it's clear that there is *not* a total of 8 scene pages available. Whoever first claimed that needs to be held accountable, because it's effed up any number of well-intentioned users out there. One minor annoyance I missed in the first part is that there's no visible indication that a chase is reversed, other than maybe observing the rig's output. This would be easy to add to the display layout, just stick an "R" or maybe a "<" somewhere appropriate -- perhaps in the upper line of text for "all rev" mode, and in the lower line when a specific chase is reversed and its handle is moved. Another minor issue is that the supposed "factory" reset, 1-3-2-3, does not remove AUX programming until the board is power-cycled. There may be other attributes with similar behavior. The workaround here, to start completely fresh, is to 1-3-2-3 and then power-cycle and hope there's no other leftover configuration from before. On the bright side, the AUX encoders are nicely speed-sensitive and invoke an acceleration factor when cranked fast, like we've come to expect from computer mice. As a final note to this part, these days there really isn't much use for a DMX polarity switch anymore as the fixtures that got it wrong are fairly obsolete. People still using such fixtures probably already have their own fistful of "flip" adapters to work around the issue, but would likely run their overall rigs with correct polarity. The switch in the wrong position is mentioned in at least one forum post as having wasted peoples' time. * * * Now after that bruising, here are some of the things I really *love* about this desk besides how the encoders work and the fact that it's one of the very few 48-channel capable units at its price point. Although bank-switching is an extra step, the ability to straightforwardly record scenes across all 48 channels is awesome -- gives the potential to run fairly large theatrical rigs from this thing. With a little forethought and organization of one's interim "composition" submasters, complete looks could easily be built from a relatively small handful of sliders. The "DJ" model of thinking, where every scene is really a sequence, gives a nice opportunity to create the chase steps as a little cue-list which could be played back in a theatrical fashion, just with a little attention to setting fade time before hitting the "step" button. The manual should really emphasize some of this -- the fact that a static scene is really a degenerate chase with one step, and how multi-step chases could be used creatively with slower fade-times for things other than a hoppin' dance floor. And the fact that sequences always start with their first programmed step when brought up off 0 assures a known starting point. Some of this was briefly mentioned in rev 9 of the manual, but apparently removed in revision 10. It's also nice that the *net* output level is what gets recorded in a scene step -- some boards ignore the effect of master faders on a stage look, and just record memories as though the master had been full-up. It's good to know that what I see now is what I'll get later, and it makes setting up that everything-at-10% preheat memory that much easier. The "recorded beat" offers some interesting opportunities. One thing I've found in dancefloor programming is that it's nice to be able to "interleave" chases, e.g. having two running at a 1-second period each but offset by a half-second gives a very nice 120-BPM look where *something* is changing every beat but not necessarily everything at once. Trying to do this with chases bound to the master clock doesn't work, as both chases simply sync up to the main board clock and run in lockstep. But a recorded beat-time in a chase seems to run independently thereafter, so two such chases brought up a half-second apart give the desired "interleave" effect. You'd never know this without trying it, but pointing it out in the manual could get readers thinking about timing versatility. I also like the fact that the slider pots have dust shields. DeOxit and I are old friends, as I've cleaned up my share of old boards gone flakey from crap falling into the slider slots, so it's nice to see some protection supplied against that. While I've been bitching about various misfeatures and problems in this board, don't get me wrong: overall it's a great product, easily capable of running the small-to-medium size shows I find myself involved in. I just want to see its capabilities firmed up and refined in a few areas. * * * This section gets into some more blue-sky suggestions for product improvement going forward. I could easily see this turning into elements of the "Stage Designer 60", but because of the noted deficiencies in the present SD50 implementation I would like to see improvements offered as an upgrade to the existing SD50s in the field with a simple chip swap. Anybody who's familiar with replacing socketed microcontroller ICs should be able to handle that. The electrical characteristics of your DMX interface should be described in greater detail. The 5-pin and 3-pin output jacks are wired directly in parallel, and the 75176 RS485 driver chip feeds the pair without any source termination or biasing circuit. *Tell* owners about that in the manual. Having the two output jacks offers the interesting opportunity to run DMX lines in two different directions and terminate at the end of each of those runs, yielding a "poor man's splitter". How? See my in-depth article on DMX signal characteristics: http://techno-fandom.org/~hobbit/lighting/dmxwave/ and read the part about "bias" carefully. Since the SD50 doesn't bias or source-terminate, it can exist as a transmitting node anywhere along a correctly built physical network. The manual should make sure to emphasize the need to record scene input into that "temporary memory" before saving anything to a scene slider. Rev 9 of the manual made a slightly stronger point about this than rev 10, but since users in the theatrical market are more used to direct recording, they are likely to omit the extra keypress needed and try to record a visible stage look directly to a scene and then wonder why it didn't take. Either that or make it possible to directly record a look to scene memory, and assume it's a one-step static scene and just save it as such. The AUX knobs appear to be a reasonable equivalent to channel park. Once a slider is redirected to an AUX, it seems to be completely isolated from normal channel operations including being recorded in scenes or being influenced by the "dark" button. That's a nice feature, because if a user wants to just put a channel someplace and not worry about it changing or getting spuriously recorded in memories, that works for them. However, the blue mimic also needs to follow the appropriate control, e.g. track the setting of the AUX control and thus the real-life output rather than the [now useless] original slider position. Channel bump buttons are not subject to the global fade-time, but scene bumps are. Is this intentional? It's arguably inconsistent. When composing looks/scenes that involve switching A/B banks to bring in different components, the fader behavior is a little squirrely. If, for example, I'm in "channels" mode and bring up channel 1, and then want to bring in channel 25 as well, I'll swap to bank B. As soon as I move fader 1 *at all* the new channel pops on at the level wherever the fader is. This is not how most boards work -- what would be more industry-consistent would be having to move the fader to match the *existing* level of what it's presently bound to, e.g. dropping to 0 and then bringing the new channel up from there. In other words, a fader should always need to be moved to a matching level of whatever it's controlling to before "grabbing" the level to change it rather than immediately setting an arbitrary level on a little bit of movement. Please consider changing this behavior to what many more operators out there would expect. Why does the desk have an extra unlabeled button, stated only as something for "future development"? And why does a button labeled "park" set the single vs. mix chase mode, rather than anything resembling a true "park" function? Not exactly intuitive. In the broader context, what *are* the future development plans for this board, and why did the present state of the implementation get out the door with these obvious dangling not-yet-quite-implemented-right features? Did the person who wrote the original code for the board part ways with your company, leaving those behind having to come up with klunky workarounds for functionality that was never really finished? From what little I know about product development cycles, that's what this feels like -- a half-done prototype that has a lot more potential. Be totally honest with any comments in this area, as I'm probably not the only customer wondering along similar lines. If it's relatively easy to do, how about turning that unused button into a direct A/B bank swap, without the need to hold RECORD down? That would be a sensible change, and make the RECORD button less likely to be the first thing to wear out due to heavy usage because it's needed to enable and switch so many other things. Such a fix would ideally be accompanied by cleaned-up A/B functionality free of the stray-channel bugs noted before. In addition to 1568, 1323, 666, 777, 888, etc and the MIDI stuff, what are the other "easter eggs" and passwords and whatnot defined in this thing? I'd like the complete list, please, including anything in the running code that isn't in the manual with a full description. Is the DMX frame you transmit hard-limited to 48 slots? It seems like it would take minimal work to let the board talk to a full DMX universe, but then you'd have to design in some concept of patching. Again, creative use of those rotary encoders could help here -- please think about that. If you're worried about refresh speed, you could make transmitted frames only be as long as they need to be to accomodate the configured setup -- the spec says you can end a frame wherever you want, really. Ability to softpatch more than one DMX slot to a channel would also be useful, and done all the time to gang up disparate units onto one slider. Again, I hope that this can get in front of the right in-depth technical eyeballs and contribute to making a greatly improved product down the road. Maybe I'm envisioning a $500 or so board instead of a $200 board, but that would still undercut some of the *less* capable consoles on the market! I'd like to be on your "A-list" for firmware upgrade beta-tests in the field if that's possible, because having the foregoing fixes and improvements under my own fingers would make my job and workflow that much easier. Anyone reading this who's been on the ground at a gig can surely understand that. My own experience has touched a broad range of gear, from little 8-channel "scene setter" boards to large theatre desks and Hogs and Eos/Ion, so I'm pretty familiar with programming and operational efficiency. If you poke around that same techno-fandom website a bit under "~hobbit/" instead of the link given above, you'll find a few other reviews and articles on lighting gear. I expect that some rework of these messages and my related notes will eventually turn into another one of those, if for no other reason than to help out users of existing SD50 desks. Thanks for listening/reading, I hope it all helps. _H*