JakeS

I must say that I don't support all these "personal email sent" solutions without future posts here, so that everyone can see what was the issue and especially the solution...

Hi there. As weird as it sounds - I was working/thinking on the idea, which may or may not be accepted as sane, but I think this couldn't hurt anybody if it could actually be done at least for a small testing purposes... So, as the title says: Virtual desk operating mode. I hope that majority of what I'm proposing here is understood already from that sentence; Detailed description: The desk could boot in so called "Virtual operating mode", (either with just this OS, or boot-selection, or even in-software option to be enabled/disabled... For testing purposes I'd prefer to get beta as clean OS with this function only). This way, the initial settings would be 2 things: Network settings (IP, Gateway, Subnet....), DMX Output settings (Port A, B, C, D -> enable/disable, selection of which universe to be sent at which port, etc...), and a big "OK" button; The next thing you see, is a small label, saying "Searching for main OS...", at which point the desk would be broadcasting! info requests over ethernet protocol; The user in this state is prompted to run a PhantomZeros application on his machine, set up (if not already) a network settings to match those on the console, and run the phantom console of the same type as he has the hardware console in front of him. Once he's done that, if console type matches (based on the info request message received in the PhantomZeros), the Phantom app asks the user if he wants to start synchronizing data between the Phantom and console. After user confirms this by clicking on a beautiful "Start" button, the console and/or Phantom screens show a nice progress bar, which is saying "Synchronizing data. xx% done"; After this is done, the console shows all of the data the Phantom has! Meaning: The submaster screen data are updated with the data of the phantom zeros, so are the palletes, macros, memories... basically everything. But, CAUTION: this is ONLY data shown on the screens of the console, including the VGA screen; Nothing is actually processed by the console, etc.. Note is, that since the consoles obviously have more than enough memory to store data of all submaster pages, memories, palletes etc, this is to be done in initial sync, to avoid using network bandwidth during usage for unnecessary transfers.... Still though, the desk is acting just as interface to the Phantom one; Therefore, every key press, every fader move is sent to the Phantom, which reacts/makes the change as if the desk would be operating normally. The Phantom at the same time processes everything as today the ZerOS on the console does, and sends the OUTPUT DATA (DMX values) in ArtNet or some self-coded if you prefer - format to the console, which is acting only as a DMX node for the Phantom; All values are synced in real-time, so every change on the phantom is reflected to the desk, and vice versa (except for the faders of course, which are non-motorized, but noone cares). This way, all of the resources on the desk are available for 3 things: Processing interface input data (buttons, faders, jog wheels), processing interface output data (LCDs, LED diodes, VGA display) and processing DMX data. The 400MHz AMD inside is more than happy to handle this and keep it of-crashes and delayed. I don't want to go against any programmer or team of Zero88, but am, just out of curiosity, asking to comment with your vote for such option on our ZerOS consoles; The description above is providing all functionality; Right now, just for proof of concept, I ask/please/dare you, to create simple demo version, providing one dmx output to act as node for phantom, and submaster faders and lcd's to be reflected from phantom, and that would be enough just to see what's gonna happen. I know it's making the desk dependable on the external processor, but if we'd at least have a choice, it would be more than amazing. I, for myself, see no troubles having PC next to me, if this is gonna make my console work as it should as now, to be honest, is useless in all aspects, since the LCD refresh is a major issue, the stability is also still a roulette at least for my console, so... I don't know. I'd really like to give it a shot! What do you guys (users) think on this one, and what do you, Jon and other developers think about it? I'm really looking forward for your opinions on this idea.

Hah, just can't get enough of this, but I hope you really don't mind... Another one, which is quite missing most of the time: the "UPS" button -> a few (as many as possible, 30 would be somehow good enough) steps back to whatever changes we've done to the desk - except for the programmer, which can be cleared anyway. That said, overwritting submaster or memory -> "Ups" takes it back as it was. It's basically "Undo" function, and since the Flash (at least in LF and Solution) is 1GB, the ZerOS only takes up to 70MB, and the show file is limited to 342MB anyways, there is plenty of spare space that could be used to store this kind of backup information. Do you think you could implement this?

Now this is great. That "Shift" part was missing to figure out what the function of that "Time" actually was. It's just one bad thing about it - it stays set all the time. :/ Could you maybe do at least something like this: Presing Shift + Time enables it (marks the display) for all time, with the fade time entered, while pressing "time", and entering fade time in the field, on Enter enables it for only one change (either color, position or beamshape).. ? Or at least to have an option to set if the time either resets to zero every time, or stays as is set... ? This would make it better. This is how actually that numpad function on others, like Chamsys works -> numpad number sets fade time for only one action that follows and then sets time back to zero. Of course too bad this isn't implemented on keyboard anyway, the procedure over MFKs is fine but slow, especially if you then need to switch to Colour or any other palletes on MFKs to trigger it.... Still good to kn ow the feature is there! Best, Jake

No, it's not what I meant. Yes, I'm aware how to use fade times in cues, submasters and memories, but it's not breaking further what I was talking about. I haven't expressed correctly: during live show, when you're applying changes to the programmer, like selecting fixtures and applying pallete -> those changes are immediate and sudden, which in some cases works perfect, while in other doesn't, like when you'd want to have smooth change via programmer -> this is where that timing to crossfade/fade the pallete parameters/changes would be more than welcome. I know you can do this via submasters or memories, but in many cases it just happens you don't have everything programmed so you work live, where this option is missing. Basically, it is a buffer holding fade time, which is used for whatever change follows... Thx for the "+" tip. I was missing that part!

Not so sure if it's a bug, and even if it is, it's not any important, but still worth noticing: Does the NumPad always work the opposite than on PC, so that when the light is lit on keyboard, the numpad actually is turned off on the console, and vice versa? I found this behaviour using 3 different Logitech USB keyboards and was confused at first for not having numpad only to find out that it needs to be "off" to actually work... ? Best, Jake

Ok, I got that wrong. I counted as if analog dimmers on faders count as fixtues, but tried that today and found that it's actually 248 fixtures the real limit, not 200. So, yes, you have that right - 10ch per fixture is less than usual to it's up to 2000 very fast. My bad. Few more questions: Is there already that I'm not aware of, or is there an option you could implement the function to change parameters with fading, as most of other consoles have? Such as, pressing number 5 (on either keyboard's numeric pad or on integrated keypad) and selecting color would mean that the desk changes the color to selected fixtures using 5s crossfade time? The same would apply for positions and beamshapes....? I found that option quite useful but not being able to use it on ZerOS consoles. This would be awesome and almost a must-have Next, not so important, yet friendly for those who doesn't have touch screen, being able to use Shift to multiple select groups would be better and faster than having to click with mouse on "And" button each time. If this is possible for by the way in some future release.... Thanks so far. Best, Jake

Ok. Thanks for this info. PS: is there a topic listing all these ZOS bugs and requests, that I haven't been able to find by myself, or is this list unavailable to public? One more -> Due to new fixtures being released, such as all those LED multicolor pars and other actually non-inteligent devices, it is pretty easy to patch the 200 fixtures that are available on the desk. Especially with these LED bars I mentioned before, for example, where each takes up to 3 fixtures for easier operation (as suggested in the other topic ), so having 30 of these bars the desk has 90 fixtures occupied, which is almost half. I know it could be dangerous if more than 200 intelligent fixtures would be used, since you must've had a reason to limit this, but those LED lights doesn't have any special effects, nor pan/tilt etc, so I believe these fixtures are not so hard for the desk to handle. That said, raising the limit for maximum fixtures patched could come handy nowadays. Not that I've ever used up all the space, but got close enough on yesterday's show... I wonder if this is achievable. Sorry for having to deal with my posts.... Thanks Best, Jake

Thanks for replies.

Done. Working as suggested. Thanks for this tip. Now I only wonder why there's the update button then...? Is it that it updates the tagged parameters, however does not remove them if they're untaged? Thanks

Nice thing! Can't wait to hear what you're working on! Good luck and hope to see that soon Ps: Another feature request: Could you maybe implement another option within the patching window, in the window where we set DMX address, so that we'd have another Edit box, (by default set to "0"), where we could enter the dmx offset for patching automatically? Possible scenario: I'm patching Led bars as 3 fixtures, one for modes and other for colors. However, since it's one fixture, it has 11 dmxes in use. I use 1 so called "Master", for addresses from 1 to 5, and then 2 "Slaves" for addresses from 6 to 8 and 9 to 11. However, to patch 10 masters and 20 slaves in order to use 10 of these fixtures, I need to patch every master 1 by 1, so that I can set the address correctly (I'm not going out, just have to press "back" button, and correct the DMX address, but it's still time consuming), and then 2 by 2 slaves, until I have all patched. If I could set some dmx delay in the patching window, for 6, the desk could automatically patch masters like this: 1 to 5, then the next instead on address 6 it would patch on 6 (next free) + 6 (delay) so on 12. Next fixture again on 17 + 6 = 23, etc... This way I'd simply click on 10 MFK's to auto patch 10 of these masters. If you'd take it to the next level, adding option "every x fixtures", it would be perfect, but that's like asking for a hand before you offer me a finger.... However, this way I could set delay to 5 and "every" to 2, and have slaves patched just as they should be within seconds.... ) I know this is not a must have, but could be handy even when patching other fixtures..... Just an idea, though.... Best, Jake

Just a heads up on some mistake I've just seen: At Botex, you added the Strobe 1500, which is cool to have there ( I used to rather have them on analog channels, but it's nice to be able to use Master fader to only lower the intensity running still on high speed, so using as Fixture is more useful in a way. ), and even more awesome is that you thought about the chiped version of it. However, you named them the other way around. The chiped version has 3 channels, while original has 2 channels. Even though it's quite obvious to know, just wanted to point this out, as you implemented this into the fixture library itself, so I think you'd want it to have all as it should be One more thing: I'm using Stairvilles LED bars 252 RGB, which is splitted into 3 parts in selected mode. You implemented that fixture as one fixture, which is cool, however I found it better to have each part as separate fixture, and am running them like this: First fixture is "master", using 5 channels (1+2 for modes/shutter, 3 4 and 5 for 1st color), followed by two "slave" fixtures using only 3 channels (for color only), both of them however having virtual channel Intensity set. I know this takes 3 times more fixtures, but I find it way easier to program things this way, as I'm always using them in 3-segment mode. This way I can just simply select segments as fixtures and set the desired colors and intensities to them. In case you'd find them useful as I did, I'm attaching the fixture file below Ps: Regarding fixture addressing and patching, I've added another comment at another topic about feature request. For the case as I described above, it would be handy to have the ability to set some "Leave x addresses between", so that you could simply click on MFKs to patch several fixtures at once, but instead of simply continuing with dmx addresses just as follows, you could set some break between the fixtures. That way I could patch first all of masters, and later all of slaves, while now I have to do one by one to have DMX set correctly Best, Jake Stairville_led_bar_252_segment.ift

Ok. Good to know. Yes, that was strange, it seems only submasters are affected. Been looking all around and only here this was happening. That second part is true, yes. It would be better to handle millis in the first place, but just wanted to point it out anyways. Thanks for clarifying this. Best, Jake

I think (mostly) I get your point, @iank99. I'll try to make some model for how this might work. There are a few ideas in my head for this one. Although yes, it's true that solving differences between the models isn't easy. But I believe that setting a few points for a mover, so that it has reference of pan and tilt, could make math easy enough to include speed increase with lowering the angle. Also thanks for Sirius info. Will take a look into their model. Ps: the last part is true, especially for moving the desk around and having same scene at different locations. However, I was implying more on simplifying programming positions at current venue, instead of having it on others..

Ok. Will know for further notes. Thank you for looking into this. Looking forward to hear what you found out about it. The rest: I see this on both, external and main lcd on the board. Try selecting the fade time and pressing the backspace key which is on MFK key 4 - top right MFKs. I'm trying to delete the number, not move the cursor. But instead of deleting it, it actually just moves the cursor to the beginning, just as if I would be pressing the left arrow key. I can recreate this even in PhantomZeros. Simply recording 2 step chase using intensity, so that the Fade times are active, and trying to change them, backspace doesn't delete the time. So it needs to be selected and overtyped every time. If you can't recreate this, I can upload the video of it. The numbers changes: Yes, I know what you mean. But, is it really expected that way -> that when at the end of the number, pressing any number always replaces the decimal number, while the second number entered then sets it to 0 again..? It just felt a little strange to me. It is not that the numbers are add to the end; From 0.0, when inserting for ex. 5, it will become 0.5; if inserting 4 then, it wil become 0.54 resulting in 0.0 again. Next number entered will set it back to 0.x, and then 0.xx resulting 0.0 again, etc... -> all of the time these changes happen, I'm simply pressing numbers, no arrows or anything else. Can you confirm this is really expected? Thank you! Best, Jake

Thanks for reply, Jon. I'm learning on Leap Frog at the moment. Thank you for adding all of these thoughts as requests on the list. Can't wait for you to make it live. Anyway, just another thought ran through my head when I was checking the Pan/Tilt grid within the Position window. It doesn't really make much sense to me just yet, especially when selecting multiple fixtures and trying to just move them for specific amount of Pan/Tilt. Instead of moving them for a little, they all get to the position of the pan/tilt values the grid sets, if I understood correctly? So said, the center is 50% / 50% (127/127) for pan and tilt dmx values, so if movers are set to some position on stage, if I try to move them just a little up with the grid, they will actually move to "random" locations, -> referring to the same dmx values. No 1: Would it be possible to use relative position values instead, so that they would actually move for a specific value, instead of TO a specific value of the grid? I believe this would make more sense, at least to me. What's your opinion on this one? No 2: A little more complicated and sophisticated idea, yet quite powerful I think. I hope I can describe it detailed enough for you to imagine what I have in mind: Let's say you keep the grid, and have some button named "Learn" for example; With that button, you "learn" the desk the position of selected moving heads. It would work like this: You would have the grid with a square inside, like if you'd see the football stadium from top view, the full grid would be the whole grass area, and the inner grid would be only the play ground, -> that square inside would actually be the "out" line of the stadium. I hope you get the idea. Anyway, you would put every (or desired) movers to specific location, one by one, or more, depends on the user wishes; By clicking the "Learn" button, and pressing one of the corners of the inner square (play ground border) for example (or simply having the sequence of 4 Learn presses, but it must somehow indicate to the user which corner is active), would record the selected movers positions (pan and tilt values) as that corner; Once the user records at least 3 ( or better 4 I think..), of those Learns - corner positions, they would be stored. This would be reference values for the desk to recalculate all other values inside and outside of that square -> the important part is the inside values. This way, you could set all movers to the same point by choosing the point on the grid; For example imagine situation having that set up on stage -> with this function you could very easily select desirable movers and simply press on the position to move all of them to that point -> for solos, or manual follow on stage, this would be more than awesome. Even outside of the stage, to make some pan/tilt drops and risings, this would be awesome and much more useful than pan/tilt wheels, I think. How sophisticated is it to make something like this implemented? Do you think something like this would be useful? I think this function would make live work so much better.. Looking forward in hearing your opinion. Best, Jake

Hi I'm having issues updating chase steps in submasters chase. I made submasters chase with 10 steps, each should only control intensity, however it seems like I somehow managed to record color pallete within the chase somewhere too. I followed PDF manuals for Solution, but am unable to make it through. I ran the following commands: Cleared the programmer completely; Load -> selected Submaster and Chase step; The step was loaded successfully as I see the output of the step as it is recorded; Fixtures -> I selected fixtures affected; Palletes -> Colour -> deselected the colors with holding clear button and moving the wheels; Afterwards I pressed "Update" button, I selected the "Submasters 2/5 Step 1" and pressed OK. The programmer has cleared afterwards, but the color remained selected within the step. If I try to Load the same (updated) step back into the programmer, the color palletes are selected again. How do I correctly clear/remove the unintentionally selected parameters from steps in chase? Where am I missing something? Thank you! Best, Jake

Hi there. Anyone noticed strange keypad behavior when editing fade times on submasters? Backspace seems to not work, while simply overwriting with numbers acts strange. For example, when selecting fade up time and pressing enter, backspace returns cursor to beginning without deleting the current time. If cursor set at the end, pressing for example "3" changes number from "0.0." to "0.3", while pressing further any other number, for example "2", enters "0.32" which immediately changes to "0.0" afterwards. Is this behavior as expected or a bug? Thank you for your reply in advance. Best, Jake

Hi there. Not sure if it's fine to make a new topic for this or if is there any existing already, so in case there is, point me out please. I just recently began to learn programming with ZerOS desk my cousin got, and am having few future changes wish-list, if it would be possible to change/include. Firstly, is it possible to have max chase speed time increased, to be able to set it over 600 (which is 10Hz, if I'm correct?). Sometimes with brightness/color snaps chase on LED fixtures, it would be very useful to be able to increase the speed. {{ From both points above I would guess that the desk is calculating timing in some second-to-minute alike relation, as speed 60 is 1 second... which I find a little odd. }} Secondly, is it possible to have fade times (and other) corrected, so that it would accept times such as 0.25 as well, instead of only accepting 0.2 or 0.3? If that's not too much to handle for the desk, to calculate milliseconds, it would be awesome. Next thing, is it possible to have color mode selected per fixture instead of default for desk? Having either CMY or RGB makes it a little difficult to handle sometimes, when using both types of fixtures. To be able to show both CMY and RGB, regarding the fixture type, and, in case both are selected, to have it shown on first/second wheel "submenu" (second group of wheel controls), would be much more handy. Further wishes to be added. Thank you for your reply in advance. Best, Jake