Led Scroller Free Download
Roselia Filarecki
I'm trying to use scroller to restore the position of a table after a full clear().add().draw() cycle. I've found that if I do not use animation on scroller.toPosition(), the scrollbar will jump to the proper position but the table will appear empty. Any mouse interaction after that causes the table to render properly again. This is using client-side data.
I've narrowed it down. Scroller fails to to render only when you're jumping to the exact same position you were previously at prior to the draw() call. This surfaced for me because I'm using a custom search box that snaps your scroll position to a certain row without hiding the rest of the rows in the table. Since I was already at the exact row position, the draw/toPosition sequence was causing a rendering fail. Note that if you animate to the position, scroller will re-buffer it. Also, once you've clicked reload twice and the data has disappeared, scrolling manually will force it to re-render.
I'm starting to program my first show after installing 1.3.0, and I've got a few questions dealing with scrollers. Not sure this shouldn't be on a thread somewhere else, but I'm still new to the forum so bear with me...
First, is there a way to edit the text that shows up on the encoder touch screen for the scroller strings? For example, I don't really need to know that my scroller is in 'skelton exotic sangria', especially since that doesn't all fit in the space available, and it doesn't wrap. That means I see 'kelton exotic sang' with half the 'k' cut off. Ultimately, I'd like there to be a way for me to edit what shows up in that space for each frame, and I don't see one so far. It would be more useful, for me at least, to see a frame number and/or the color number (Fr 30 - R39) instead.
Also, is there a way to invert the scroller values specifically? We're using Revolutions with different strings, and one of the strings we've had around forever. Unfortunately, it's backwards. The strings were either built backwards, or installed backwards every time they have been used. On our old O2, this is a quick fix. Just profile the channel for the scrollers so that full and out are reversed, and that's that. I'm not finding a similar way to resolve the situation on the Eos. For programming, I'll just be using color palettes, and I suppose I could just build a new string in the board, not to mention getting the strings reversed physically in the fixtures, but I feel there must be a simple fix in the board for this that I'm not seeing.
Finally, I discovered this morning that when the manual says "It is recommended that you use the patch by channel display when working with moving lights or other multi-parameter devices." they ain't kidding. I spent ten minutes frantically looking through the manual and trying to figure out why I couldn't select a string for the scrollers I was patching. Apparently, you can only do this in patch by channel view. You just get an error if you try it in address view. Not sure if this is a designed behavior, or if I found a bug, but there it is.
I'm sure there are many different ways to get around your problem. If I was in your situation, I'd probably prefer to install the scroll the same way as the rest. If for some reason this is not possible, or you wanted to keep it inverted to the rest, then I'd probably make a new scroll for the one "inverted" scroller, and then make colour pallets with all scrollers in the same colours. From there you can label the CP's with the colour numbers (eg R85, L201, etc) and if you go into setup, under desk settings there is an option "show reference labels" (or something to that effect). If you enable this, when you put your lamps into colour pallets, instead of showing (CP1) or (CP12) etc, it will show the label you gave the pallet (L201) or (R85) etc.
Patching them- I learned the same lesson the same way, except it probably took longer than ten minutes. Being brought up to patch by dimmer it seemed more intuitive to do the same for the scrollers. I've come to grasp the concept though. All of your scrollers are Revolutions, but the different srings become different attributes of the Channels. OK, let's say I accept the concept.
Personally, I gave up on using the encoders for scrollers other than for recording Palettes. The "create your own string on the encoder" feature is super cool but I don't find it very useful if it isn't reflected on the Live screen. You'd have to call up each channel or group to see what frame it is in. With Color Palettes and Show Reference Labels enabled, you can label them whatever and have them attached to your channels on the Live screen. (Be sure to have Parameter- Color selected for display.) It's more work, but as the board stands, I would think that's your best bet.
I recently had cause to revisit the scrollers on encoders thing. I realized that during these dance school recitals, I have no designer whining about seeing what frame a light is in. I simply have to pick a color fast and move on. We have two sets of 26 frame scrollers. In order to avoid using 52 Direct Selects for discreet Color Palettes we use one set of palettes for both, labeled as Frame #. Then we are constantly referring to two sheets of paper to decipher the gel colors. I was very pleased to rediscover that once I built my custom scroll I was able to use the Color Picker. Just pick any point on the spectrum and it automatically takes you to the nearest available match on your scroll. Though I still think it won't be of much use when working for designers who starve for info, I can foresee myself using it more in the future. Here are a few questions and notes:
When I built the scroll and put it on the encoder, the touch screen buttons (non-expanded) said Min and Max. Is there a reason that can't be Next and Last? It caused me a lot of unintended scroller runs.
Calibrating a scroller only adjusts the snap points for NEXT/LAST on the encoder. You find that the scroller value onscreen is different after calibrating then before, therefore all color palettes need to be updated with the new DMX values. If your encoded does not have NEXT/LAST try using Wybron Coloram2 for a scroller type. I believe the custom values are stored on a per string type basis. Per unit is more than we can expect. I create a new string for each batch of strings, even if the frames are the same.
As far a patching scrollers, or any other non-conventionals, I want the interesting part (ie Wybron Coloram2 etc) to be part 1, so that when I'm in Live Table packed I see "Coloram2....." instead of "dimmer" above the table. I switch to Patch by Address after all non-dimmer patching is done, as these dimmer addresses will be safely added to additional parts. I try to organize patch to make maximum use of NEXT / LAST as the console keyboard seems to lend itself to typos.
I reserve Color Palettes 1 to 20...etc for color frame based scrollers. CP 1 = Frame one, and so one. We also have CXI's, so CP 101 - 184 is taken directly from the CXI colormix manual. I notice the Color Picker is timid about taking parameters to their maximum value, so we have palettes for Max Red, Blue, Green etc.
To preserve palette info from show to show, I don't start a show from scratch, but just delete show channels cues, designer's groups and presets. It's important to keep one channel of each color change type to preserve the palettes. I have 1001 = Coloram2, 1002 = CXI, 1003 = VL1k 1004 = VL3500,1005=autoyoke w/scroller, and so on. You should deep clear after deleting all this as I have noticed what could be called artifacts in the tombstone display, most likely from corrupt persistent memory.
After installing a new string, I patch 3 or 4 of the scrollers into 1001 (to get a consensus) and then calibrate them in the boardroom, if possible, writing down the values for archive purposes. In blind spreadsheet I set the values for 1001 in CP-1 and so on, not by typing it in but by using the NEXT/LAST on the encoded (encoder expanded mode is helpful here). Why? Because the console will fetch up the Hue/Saturation value for that gel as well as the DMX value. I can copy the Hue/Sats to my CMY mixers to get, if not a perfect match, at least a starting point (VL's suck at mixing color).
With mixers I notice that I'll get Hue/Sat greyed out or the physical parameters (scroller,scroller2,C M Y etx), but not both. This is to avoid a chicken vs egg situation (and a crash). With scrollers especially CXI's you want to fade by the physical parameter not HUE/SAT, which is what the color picker gives you. To shift the emphasis I would type chan 1002 scroller scroller2 @ + 0 ENTER. When this is done the console calculates new values for the greyed out parameters. The formulas are lossy so you can't flip back without data corruption, which means going back to the color picker gel library to start over.
When I select a scroller channel the console will convert the DMX screen value the correct gel name on the encoder screen, which is the second reason you should go to the trouble of building a custom scroll type. I did have a network glitch once which caused the console to drop the scroller info, but since I had the correct DMX in palettes I was able to proceed thru tech anyway.
One of my scroller groups is 21 thru 31. They are all patched as Wybron coloram II's with the same custom scoll profile. They are all in the same Frame 1. If I call the whole group, I get Min and Max on the Encoder. What's particularly vexing is that the is a picture of the next and last frame above the words min and max (all the way through the string.) It makes it very easy to press the Min or Max button, hoping for Next or Last, thus running the full length of the scroll unintentionally.
The only way I get MIN/MAX on this version is if the first channel in the selection is not a frame based scroller (ie dimmer or CXI or VL) . I can't get pictures over them though. Scrambling the patch and even mixing types didn't affect it, although a ETC tech told me that patch order may have affected palettes a few version back. Consistancy never hurts. You should indicate the version your running since each version is another spin of the wheel.
760c119bf3