Jump to content
Vari-Lite Controls Support Forum

nbaldwin

Regulars
  • Posts

    40
  • Joined

  • Last visited

Everything posted by nbaldwin

  1. As per the title, anyone recommend a reasonably priced touch-screen monitor for a Leapfrog 96? Thanks, Neil
  2. Hello all, Does anyone know if there are any training courses dealing with basic servicing of Martin lights? I know places like Stage Electrics do servicing work on them but I'm just talking about general disassembly, cleaning, fault finding as it's prohibitively expensive for us to have to send lights off. We are able to partly disassembly and clean but beyond that we can't do much more. Thanks, Neil
  3. That's a real shame. Basically I programmed a load of cues in a show and then realised I'd loaded the wrong show Coincidentally I spotted this in the release notes for 7.9.6 - "ASCII showfile importing". What does that do?
  4. (Leapfrog 96, ZerOS 7.9.5) Is it possible to copy Cues from one Show file to another via the console? Or failing that, is it possible to do it with a text editor or such? This feature would really, really help me out over the next two weeks! Cheers, Neil
  5. Doh! Found it almost the second after I pressed "Submit" - it's the default saved value for that fixture, in case anybody else was wondering. Neil
  6. I'm sure I've read this somewhere but for the life of me I can't find it: what does it mean when one or more fixture parameters (intensity) is coloured yellow in the programmer/output window? Neil
  7. Apologies Edward, I was on holiday for the summer. Will pick this up again once I have the chance. Neil
  8. I think there is something more fundamental going on with saving any type of cues. This week I started programming a new show from scratch. I started off by just working on some position setups and saving them as temporary cues as I progressed (probably my own quirky way of working). For example, I'd position a couple of sections of movers then when I was happy I'd save the Cue (snapshot). Then I'd Clear and work on positioning other sections of movers and then save a new Cue (not snapshot). So what I'd assume would happen is if I playback the first Cue and then the second Cue, all of the movers I programmed would be in position. Strangely, and frustratingly, this wasn't happening reliably. Some movers that had been programmed in the second Cue would remain in their home positions. I literally repeated this over and over and the behavior was the same: inconsistency in what was being saved into the Cue. I then resorted to manually forcing a Snapshot save for each saved Cue and that was working. Not ideal but at least I was making progress. Then I started 'updating' some of the saved Cues by continuing programming then forcing an overwrite (the actual Update button I've never really trusted). Oddly this method also started showing signs of programmed fixtures not recalling correctly even though they previously did before I'd overwritten them. Finally I found the only reliable method of saving updated Cues was to force Snapshot and save as an entirely new Cue. There's definitely something weird going on. The thing is I can't understand why I'm only really noticing this behavior now after updating to 7.9.4 about 12 months ago. Possibly this is because old shows (we mainly reuse shows and modify) seem to 'convert' OK but creating stuff from scratch (which doesn't happen often) is when all the problems start. Apologies for the long text, trying to add as much detail in the hope that it triggers something.
  9. Just checking back in to see if there's been any updates to the thread.
  10. Just to add a bit more detail. I thought I'd see what a CSV dump of my Playback looked like. I'm not saying I can make total sense of it but from importing it into Excel there is definitely a value for every parameter of every fixture written in there, despite the fact that the single cue should only contain Position and Effects settings for 5 of our movers.
  11. Yeah, same I'm I right in thinking they're away at some show at the moment?
  12. Thanks Kevin. Reading your post does make me think we share a similar problem i.e. parameters getting recording into cues (or elsewhere) when they shouldn't be (or shouldn't be expected to be). I've got an even weirder discovery from this morning. I loaded quite an old show that I knew had working submasters (that work ontop of other cues). Once the OS had converted the old show (from back when submasters were submasters), the converted Playbacks actually work as expected (for example, I have several that just set the colour of all the movers to a single colour, red, blue, green etc. and these work fine without affecting position, effects etc.) but if I try to program the same Playback from scratch they don't work and instead seem to contain position/effects information too where I don't want it.
  13. OK just checked. When I set the movers position and press record, the default options are "'Tagged Parameters" and then "Intensity" and "Position" (these are marked red, the rest are marked blue). When I then set the movers colour and press record the save options are "Tagged Parameters" and "Colour" (marked red, the rest marked blue). This is what I would expect but the playback behaviour would suggest that all parameters are being recorded regardless of which are marked red.
  14. Thanks. I'm away from the desk at the moment but I'm 99.9% sure that when I'm recording the FX/Colour to a Playback it shows the correct recording parameters. I'm always careful to look at what parameters have been tagged in the Output window before recording and it's always a single parameter type. I will investigate more tomorrow.
  15. Hi Edward, We might be getting somewhere after your last reply. The Master playback wasn't set to HTP Master (i think it was setup LTP). Changing it has definitely had an effect though it doesn't seem to be entirely working. I homed all of our movers and then saved that as a Master Playback cue. I selected a row of the movers and set them to a figure-of-8 moving pattern. I then assigned this to a Playback and now raising the Playback fader does indeed start and stop the effect/movement of those programmed. All good so far! I then wondered if I could combine that with another Playback but this time use it to change the colour of the selected movers. By itself, the Playback that controls the colour works but if I trigger the previous Playback (the one that makes the movers move), raising the Playback that sets the colours makes the movers go back to their home positions and stop moving (colour changes though). I then tried another test by changing the position of some of the other movers and saving that as a Master cue. Now when I raise the Playback with the movement effect, the Playback works in terms of making those programmed movers move but it also sets the position of all the other movers meaning the positions etc. of all the fixtures must be stored in that one Playback? I hope that makes sense: in short, we don't seem to be able to combine two (or more) Playbacks, even though the only thing stored in each of them according to the tagged parameters is FX on one and Colour on the other (all with the same row of moving fixtures). Neil Edit: I tried saving to the Playbacks using "Snapshot" and "All Parameters" but the behaviour isn't any different. It's as though it always saves everything regardless of what mode you save in and what parameters are tagged. Edit 2: I forgot to add that we are not on the very latest ZerOS. We're on 7.9.4.7 Edit 3: I just updated to 7.9.5 but the behaviour is the same.
  16. Thank Edward. We followed your advice and still could not get it working. Scenario: Saved a lighting state in playback 0 with all of our movers homed (100 intensity). The four floor LED parcans are set to 0 intensity in this cue. Cleared the programmer. Brought up the intensity of the 4 parcans to 100. Checked the output window to see only the 4 parcans were tagged. Saved this state onto a playback. Cleared the programmer again. Move the fader, nothing happens. Output window shows 0 for the parcan intensity and a grey box appears around the parameter. This is with the playback setup to trigger on raise, release on lower, move on dark turned off, fader mode set to HTP Master. The only thing we could make happen was by setting the fader mode to either of the LTP modes. But instead of just fading the 4 parcans, the fader faded the intensity of the parcans and the entire rig of movers from 0 to 100 intensity. We abandoned it for the show as we were getting more frustrated than enlightened! The only thing that I could possibly think of: does it depend on the operating mode of the desk? We almost always run in non-tracking mode. Neil
  17. Since updating our LF96 to ZerOS (the number isn't in front of me but we've gone from old submasters to new Playbacks) we are still not able to program even the most simple functions such as intensity fade onto the playback faders. It works with our generics but won't work with either our Mac 250s/550s or our LED parcans (RGBA). I don't know if we are fundamentally not 'getting' how the new playback faders work or something is just wrong. For example. If we home all of our Mac movers so that they are all in their home positions with full intensity, then pull down the intensity of them all to 0 and save that as a cue in playback 0, if we then (after Clearing) select the movers again, bring their intensity to max and then save this state onto a playback, we're expecting to be able to control the intensity of all of our movers with the playback fader. This does not happen. Even though you can see in the Output window that the intensity parameters have been tagged for saving (at 100), when you move the playback fader all that happens is that the 0 intensity stays at 0 but has a light grey box around it. I presume that's telling us something but we have no clue what. And more importantly, we don't know how to resolve that so that it does what we expect (fade the movers intensity between 0 and 100). We've had this problem ever since updating (probably a year ago) and have literally stopped using Playbacks except for Chases, which do work fine. Any hints, tips or pointers in the right direction would be a huge, huge help right now. We'd setup some parcan uplighters for a show this weekend hoping to put the RGB controls on playbacks for some quick way to make some colour variations on the fly but after a frustrating rehearsal last night when we just couldn't get it working (as described above) we gave up with playbacks. Again. Thanks, Neil
  18. We received a donor LF96 (partly damaged, no longer used) that I've harvested spare parts from including the main PCB (the one with the CF slot). We have a LF48 that has a damaged VGA socket so was hoping to swap out it's main PCB for the donor LF96 one. 1) I'm assuming that they're the same PCB? 2) Is there anything I should do prior to swapping regarding backing up the LF48? Obviously all of our show data is saved but what about the fixtures? If I just put the CF card from the 48 into the 96 PCB when I swap them, will all of our fixture data be on there and load OK? Thanks, Neil
  19. Since updating to the latest ZeroS beta I don't seem to be able to find the lamp hours reset function. Has it moved or am I going daft?
  20. We've just replaced a bunch of MAC 250 lamps and a couple of fixtures are flickering (Leapfrog 96 console). Is this anything to do with 'Rig Sync' that I've read about and if so where do we find that setting on our console? Thanks Neil
  21. Is this actually possible? We've got an iPad using the official app which works (via wireless router) but so far we've struggled to get anything working (Q-Lab->router->LF96). We've got the LF96 getting DHCP address from the router and interrogating the router shows up two IP addresses for the LF96 (same MAC address) - is that correct? Will the LF96 just accept OSC messages or are we missing a component? Thanks, Neil
  22. Is the MFK sub-board compatible with both the Leapfrog 98 and 48? We have one fairly tired LF96 console that has a few sticky MFKs but we also have a fairly under-used LF48. I tried swapping the MFK sub board from the 48 to the 96 but while the keys themselves seemed to work, the display above them was blank. The two consoles are running different OS/firmware (the 48 has an older firmware, the 96 has the latest Beta) - could it just be a matter of updating the 48 and *then* swapping the MFK board? Thanks, Neil
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.