• Date
    David Buffham
  • Date
  • Replies 6 replies
  • Subscribers 185 subscribers
  • Views 6623 views
  • Users 0 members are here

EOS handling of fixture timing channels


Are there any plans in the future to enhance the way that EOS handles fixture timing channels? As far as I can tell at the moment, the only way to apply a value to a timing channel is via the command line - which requires carrying around or memorising a mapping table of DMX values to time values - it's not even settable by encoder using default profiles. (though I guess I could create customised ones?)

The reason I'm so keen on timing channels is that they overcome DMX limitations, particularly for fixtures with 8-bit attributes. For example, take a VL2000 spot which has 8-bit control of color wheel and gobo wheel. There are only 18 DMX values separating adjacent colors or gobos - therefore a slow fade between 2 adjacent colours or gobos is unacceptably jerky. Whereas by using a timing channel the same change can be handled by the fixture extremely smoothly.

In this respect Virtuoso is great in that it abstracts timing channels from the user completely. If a fixture supports timing channels and all attributes covered by a timing channel have the same time, the desk will set the timing channel automatically and snap the attributes to their new values. This works when playing a cue forward or backwards, and also when attributes change in effects. So as a user you don't even have to think about the timing channels; just set the attribute times and the console takes care of the rest. This also means that when you set a 10 second colour change on a VL2000, say, that timing value is displayed in cue data and you know how long the cue will take. On EOS, I have to set the colour change time to 0 and the colour change timing channel to DMX 50 - but this means on the playback displays the colour is showing as taking 0 seconds when in fact it is programmed to take 10.

So from my point of view it'd be nice to see something similar in EOS; even though I've been able to manually use the timing channels with EOS it hasn't been nearly as elegant as on our old desk.

  • Hi David

     

    Unfortunately I’m not sure there is an easy way around this and this is why everyone loves running old Vari-lites from a vari-lite desk because the desk does all the hard work for you.

     

    As a strand programmer for a long time I may be able to help a bit.

     

    What you can do is record palettes that just contains the timing information (using the fillers may make this a bit quicker) and label them up as 1 sec, 2 sec, 3 sec, etc etc. This will save time in the long run as you can just add these palettes when you need them. This will help you see a time if you look at each channel and not just DMX values.

     

    What does help with older VL’s is set the timing channels to full as this smoothes out the DMX a lot. I’ve not tried this on colour wheels though moving one colour, but this works great on pan and tilt and the colours on VL5’s.

     

    I always run the timing channels at full when programming and for the first few shows and then if I need to use the timing channels I make snap part cue so I can just label that part with the live move time.

     

    As Anne worked on the Virtuoso she may have a few tricks up her sleeves for the future, but this is how we get around the timing channels with VL’s on a strand.

     

    Hope this helps a little.

     

    Nick



    [edited by: Nick Simmons at 4:01 PM (GMT -6) on Fri, Sep 28 2007] [edited by: Nick Simmons at 4:00 PM (GMT -6) on Fri, Sep 28 2007] [edited by: Nick Simmons at 3:59 PM (GMT -6) on Fri, Sep 28 2007]
  • in reply to Nick Simmons

    Thanks Nick - the palette idea for creating timing channel shortcuts is a good one.

    I wouldn't say that it just applied to the 'older' (i.e. Series 300?) Vari-Lites, though, I particularly use timing channels on VL2000s/VL2500s. Its the 8-bit colour & gobo wheels that cause the problem with these fixtures. The lights are good enough to fade between adjacent colours / gobos, but they do need timing channels to make it clean.

    Incidentally I noticed last week that the desk was defaulting the timing channels on the VL5Arcs to 255 - which I can understand why now after what you've said above.

    Cheers,

    David

     

  • Hi David.... just so you know, we are looking at changes to the way luminaire timing is applied.   It's been on the list for sometime, but keeps getting bumped by other priorities.   We are going to extract it from parameter data, set it and display it in the same way the discrete timing is applied.  This should cause it to work much closer to the way you are used to using it with Virtuoso.

    It's on the list for 1.4 (March '08).  I'm hoping it doesn't get postponed again, because it will also make the displays much easier to work with....

    a
  • in reply to Anne Valentino

    Bringing back a really old thread here. Has there been any more discussion about making timing channels more user-friendly? I just finished programming a show where I needed to use timing channels quite a lot, and it really would be convenient to be able to adjust timing directly instead of needing to go through a conversion table. I ended up just recording a bunch of presets for all my fixtures with all their timing channels at specific values (based on the advice of someone here), but it was a pretty roundabout way of doing it, and if I needed something I hadn't yet recorded (like 2.5 or 3.5 seconds), it was back to the tables.

    I don't know anything at all about writing console software, but it seems to me like this wouldn't be too difficult to integrate - instead of having the encoders adjust timing values from 0-255, just have each movement go from 1sec (DMX 5) to 2sec (DMX 10) and so on, then obviously allow fine adjustment to the DMX value. My sincerest apologies if this is actually way more complex than I imagine it being. But is this something we can perhaps add back into the queue?

  • in reply to rochem

    We do still have plans to handle timing channels differently.  It is a bit more complex than it might appear, as anything that involves manipulation of the library tends to be.  :-)    This is targeted for 2012, as the developer who will work on this project (which will take some time to implement and probably more time to test) has a few more critical tasks on his list before he'll be able to put his attention toward it.      But it most certainly in the queue!!!!

    Thanks much!

    a

     

Related

www.etcconnect.com