How to set "Strobe Mode" to "Closed" / "Open" / "Strobe" ... ?

Hi
I'm coming into EOS via OSC commands, but this topic is the same for command line commands and cues:

In order to change the 'Strobe Mode' (aka 'Shutter Strobe' in ML controls) to Closed or Open or Strobe I have to enter a number. And that number seems to be a raw Dmx value - which differs depending on what fixture I have.
That's why I would rather like to enter a String, like "Closed"/"Open"/"Strobe" - or reference that state in other general means.

Is there any way to do that?

Background: I work with Robe Pointes in venue A - 'Strobe Mode' set to 18 means Closed, 127 means Open and 90 means Strobe. The tour continues and in venue B I work with Ayrton Ghiblis -  25 means Closed, 76 Open and 127 means Strobe. Thus all my fixtures set to Open suddenly start to strobe! Now, I could change my complete programming to these new values. But next venue has DTS Evos .. new values .. 
EOS generalizes many features in a nice way, i.e. for Pan/Tilt I don't need to worry about DMX channels and raw values. How can the same be achieved for the shutter?

Parents
  • I would suggest making Beam Palettes with “By Type” fixtures for each fixture you will be using. That way it is always referencing Beam Palette “X” which would have each fixture’s strobe value. When you change type in patch, it would just reference the value for the new fixture type in that palette.

  • Thanks .

    So, there is no way to directly access these Buttons ("Open", "Strobe" etc) other then clicking?!

    Re Beam Palettes, I thought in a similar direction! Of Beam Palettes "By State", to be updated once every tour stop. "By Type" is an interesting alternative, will ponder.

    Related issue is "Shutter Strobe" range. It also is not standardized (0..100%), instead has arbitrary ranges, sometimes representing Hz rates (i.e. with Robe Pointe, 0 .. 15Hz - ok, cool), sometimes based on raw values (i.e. Robe BMFL, 64..95 - seriously?).
    Any suggestions how to work around this incoherence?


  • The only way around it would be to edit the fixture profile for yourself. Those ranges are all established by the 3rd party company that builds profiles for ETC. when you go into the fixture profile there are 2 columns: DMX Value and User Value. If the user manual provides a Hz range for the strobe, you can change the User Values Min and Max to match the provided range.

    if you do “By Type” it would just save you a little bit of time because if you end up at another venue that has a fixture type you have already used, you would not need to update the palette again. 

  • This incoherence in the fixture library is maddening. I hope this will be addressed soon. The fixture library needs a big overhaul to ged rid of alle the inconsistencies.

  • We can only pass on the information provided by the manufacturer of the fixture.
    The documentation we get varies from "four words scribbled on an envelope" to "detailed 50-page manual".

    Some manufacturers send us or our 3rd party supplier (Carallon) a sample of each fixture so we can measure all the information that's missing or incorrect in the manual, and create the best possible personalities.

    Most fixture manufacturers don't do that, and don't put information like stroke Hz in their manuals.
    In many cases we don't even know which DMX value is "slowest strobe".

    We can only improve these when users like yourself let us know the real numbers, and put pressure on fixture manufacturers to improve their documentation and send us sample fixtures.

  • Thanks for clarifying, Richard. I can totally see these issues esp with exotic fixtures.

    However with the Robe BMFL (compared to Robe's Pointe) and also with the Clay Paky Axcor the issue rather seems that different contributors follow different "philosophies" how to translate the various value-ranges and capabilities of the fixture into faders/values in EOS. There are indeed inconsistencies that would be ace to get fixed. Shutter Strobe from 64 to 95 isn't really intuitive Slight smile

    This I've fixed to 0..10Hz (as per manual) as well as similar issues with Clay Paky Axcors - is there a way to commit edited profiles, so they can be reviewed and)added to the next library update?

  • is there a way to commit edited profiles, so they can be reviewed and)added to the next library update?

    There are a lot of "Bug Fixes" in the Fixture request Forum.

  • Hi Richard, I hear some different things from the industry. Many manufacturers I talk to, complain about the lack of support they get from Carallon (not answering emails or phone calls, taking ages to get the requested fixture out to ETC or other console manufacturers) and ETC themselves referring them to Carallon not willing to deal with the issue themselves. There can be competitive reasons not to describe everything in detail in a manual (counterfeit fixtures or cheap knock-offs are a big problem for companies that have put a lot of R&D into their products)

    Another problem is that not every contributor to the fixture library uses the same logic in translating real world values (or values from a manual) in the same way. The strobe ranges are one example, but there is also quite a few ways in which Color Temperature is represented in the fixture parameters (Color Temperature (percentage or real world values), CTC, White point Set, and in a way CTO and CTB).

    If it is as easy as it is for customers to make a fixture, maybe ETC should choose only to have good, tested, calibrated fixtures in their library and make clean house.

  • That's the way then. Tho I can't figure out how to export a single fixture (in order to post it). Any leads?

  • Just save the showfile.

    If you want to limit it to just that particular fixture, make a new blank show and Merge it in.

    The Merge is the process because you'll often want to bring by-type palettes along and similar.

  • We try not to let the perfect be the enemy of the good - or the sufficient!

    The primary goal is to make the fixture usable. There's a show, it has to work.

    When we don't have any information about the real values, we use percentages.
    When we don't know which end of the range does what, we guess based on knowledge of similar fixtures.

    If a fixture manufacturer chooses not to publish information, then those personalities will have percentages or estimates to ensure the fixture can be controlled at all. That's the cost of not publishing.

    There are quite a few features that are similar in purpose, but behave quite differently so are kept separate. Colour temp control is one major example of that.

    Plus some things that are the way they are because of the weight of History.
    - eg a moving mirror doesn't really have a Pan, but everyone thinks of it that way so that's what it's called.

    And of course, there are always going to be mistakes and misunderstandings that need correcting.

    As to your final line - that's simply never an option. I can hear the screaming already ;)

  • Hi, thanks for your answer. Although I do understand the arguments you bring up, I do not agree with all of them. 
    I think what you are saying might be true for the initial fixture profile, I guess when time has told that a specific fixture is here to stay or it becomes very widespread (an industry standard as some like to call it), these need a little bit more attention.

    Also, I think that the old Strand philosophy of the ‘abstract control model’ still has a lot of value, where all fixtures are presented to the user in the same way as much as possible, no matter what the fixture manufacturer chooses to call things.

    This means a bit more work on ETC’s side to translate and understand how different fixture brands deal with things, in order to make life for the user easier.

  • I'm sorry, you've completely misunderstood.

    Eos will use "real world values" if they are known.

    You've suggested that we refuse to make a personality if we don't know the real world values.
    WholeHog 3 tried that approach, it was an unmitigated disaster.

    The entire industry has learned from their mistake.
    All consoles that are capable of real-world-value control always have "fallback" values and control parameters which are either outright guesses or percentages of the available range of raw DMX values.

    (Also, 'old' Strand never even attempted any of this, so I don't know what you mean by that.)

Reply
  • I'm sorry, you've completely misunderstood.

    Eos will use "real world values" if they are known.

    You've suggested that we refuse to make a personality if we don't know the real world values.
    WholeHog 3 tried that approach, it was an unmitigated disaster.

    The entire industry has learned from their mistake.
    All consoles that are capable of real-world-value control always have "fallback" values and control parameters which are either outright guesses or percentages of the available range of raw DMX values.

    (Also, 'old' Strand never even attempted any of this, so I don't know what you mean by that.)

Children
  • We cannot force a fixture manufacturer to publish data or to send us a sample fixture to test.
    We can only ask them.

    Sometimes they respond immediately, sometimes months later or not at all.
    They have their own commercial pressures.

    Sometimes end users give us detailed information from their experience of using the fixture.

    We can only pass on the information that we have available.

Related