• Date
    David Buffham
  • Date
  • Replies 6 replies
  • Subscribers 185 subscribers
  • Views 6625 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.

Parents
  • 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

     

Reply
  • 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

     

Children
Related

www.etcconnect.com