Arri SkyPanel S60-C Ultimate Mode 30 how to on an up to date Ion

Probably best to build a new profile from scratch and give each parameter range names that are easy for you to remember what each does.

hello, has there been a solution to this fixture profile?

hello, has there been a solution to this fixture profile?

my solution for mode 30 was to build separate profiles depending on what mode you want to use (HSI, gel, etc), and setting a fixed value for the 'mode selector channel'. Then have some macro's to switch between profiles as you go.

That’s awesome but can we please fix skypanel mode 30? Somehow the Blackout app has figured out mode 30 but ETC has not. I understand ETC outsources their profile building but this doesn’t seem to work at all.

Can you explain what you mean by:

gloebell said:

this doesn’t seem to work at all.

Is it that the fixture profile doesn't work to control the fixture or is it that it doesn't work the way you think it should to control the fixture?

Mode 30 is unique in that a complex fixture with multiple modes of operation that you would normally set on the fixture itself on any other fixture type are now selectable via an address value on the channel. Therefore, because the console doesn't have any way to assume what each address of the fixture is going to be doing at any given moment, it has to try to store the data for the outputs based on the mode you have selected in that instance while leaving open the possibility that you may change your mind about how the fixture operates in the very next record target.

Unfortunately, Eos (and indeed many consoles, kudos to Blackout) wasn't designed for the possibility that the function of each address of the entire fixture definition could change based on a single address change cue to cue. Complicating that, the robust color controls built into Eos are reliant on knowing certain things about the fixture's definition (such as the gamut as it maps to parameters) when the profile is patched into the show. That type of data retrieval is done on patch because it is programmatically very costly in processing and could potentially be very messy if you were changing cue to cue (consider for example a cross-fade that repatches your show and where would that repatch happen and when exactly during the crossfade should it load the new data and what happened if you stopped the playback of the cue - which dataset should be loaded and which should have control?)

There are definitely ways that we can try to improve this, and, believe me, they are on the list. Right now, unfortunately, it is not a simple nor quick fix and it requires substantial development time as well as reconsidering how the console stores and plays back data which is not something that is done lightly.

While that work is considered, perhaps you can fill me in on something about the use case of Ultimate Mode 30 as I've always seen it more as a gimmick. In what circumstances would you need to change the operating mode of a fixture on the fly during a running show without having the time to repatch the fixture (presuming that you could use RDM for the remote changing of the fixture's mode to avoid the need for direct physical access)?