Ion Encoders Plus Shift? Why?

I'm with you on this. Not a fan of this change.The encoders seem more erratic than ever now. Every time I grabbed a shutter I'd spin it one way, it would ever so briefly go the opposite way then go the way I wanted it to, resulting in me always thinking I was turning it the wrong way, I wasn't, and then correcting and essentially playing pingpong with the shutter until I realized what was going on.

Jason, we are not aware of any issues with shutters as reported.  Can you tell me what fixtures you are seeing this on and what your encoder settings are?   You can either post here or email me.  Would also be good to know what hardware you are on.  We will take a look. 

Thanks,

Anne

 

Anne,

NOTE: This post won't be as finely tuned as the one that I was composing when the forum went down all of a sudden early this morning.

All of the 8-Bit attributes that are mapped to encoders are totally wacky if you don't push the shift key. Essentially, I have to push the sift key any time I want to use an encoder. Otherwise, the results are as follows:

• City Theatrical DMX Iris overshoots
• Scrollers overshoot
• all shutters overshoot
• hue and saturation  control of led fixtures overshoots
• control of files, folders, effects, parameters and other features of Arkaos MediaMaster fixture mode is impossible.
• in short, control of any 8-bit parameter is difficult

With just a few exceptions, (colour selection on Altman SpectraCyc, and shutter control on Mac 250 Entours) the only fixture parameters in my inventory that I controlare 16-bit are Pan/Tilt.

Was the intent to have to use the shift key for every action requiring an encoder? I can see a case for it on pan and tilt, and other 16-bit attributes, but it makes using my Ion encoders for anything else a real pain. I don't need fine control over an 8-bit attribute, but the way the console works now, I need two hands for every action involving an encoder to use my Ion. Aside from Pan/Tilt,

I can understand that some people have requested it be this way, but for those of us who don't need the user experience to be the same over the entire line of consoles, you have just made our lives more difficult. I don't deal with any of the other consoles in the lineup. We only have the one console.

Busking on my Ion is now an exercise in futility as I used to be able to use my free hand to operate subs and faders while using the encoders. Now I have no free hand as it is having to hold down the shift key so that my movers don't just swing around seemingly at random.

To a man, all of my staff wants to revert to an earlier version of the software so that we can have some level of control back. If this is to be the default mode of operation for the consoles, can we at least have an option to keep control on the encoders they way it was? I can see that it might be useful for encoders to behave like this for folks that have days and weeks of programming time to get a show up, but I usually have only a few hours. 5 minutes per number to program a big dance recital is the norm. 3 or four hours to program a musical or play is considered a luxury. The need for the shift key has created havoc for the last few shows that I have tried to program. I was finally to the point where things were second nature on programming my Ion, and now I have to face a paradigm shift in how to use the encoders.

With the only adjustment being percentage degrees per rotation, I simply can't get the control I need for my encoders. setting the percentage at 10% (the minimum I am able to set), my movers still go shooting around like crazy. I hope that in the very near future we can get an optional setting in the software to let us decide how we want to set up our encoders.

Thanks!

Hi Charles,

I'm really confused by the behaviour you're suggesting. I can't see how these changes could result in overshoot unless I'm not understanding what you mean by that. If you specify your percentage and degrees to a low value it should take a whole rotation of the encoder to move it that amount.

If you're controlling parameters via 8-bit anyway you're always going to get steppiness, that's the nature of 8-bit control.

Far from taking away from your functionality the addition of Shift has actually allowed functionality on Ion which didn't exist before. I know this seems like a new thing to you now, but some of us have been using this mode for nearly 2 years now and I can tell you it has made control significantly more efficient and predictable. Please stick with it, it is better!

As far as consistency across consoles goes, it's really important where possible to ensure that all of the devices in the Eos family operate consistently, that doesn't just help those who use multiple devices, it helps support, training and makes software less complex and easier to use.

If you are seeing genuine bugs with your encoder controls then these will be addressed by ETC.

Cheers

Dan

Dan,

I am not seeing steppiness, I am seeing fixtures and parameters being overcontrolled by the encoders unless I use the shift key.  I am not using 8-bit parameters by choice, the fixtures we have in our inventory simply don't support 16-bit control over anything except pan/tilt (except for the fixtures I named in my post).

If I am controlling my DMX irises with the percentage control set to 10 and the degree control set to 1, if I move the iris size encoder even a few clicks without using the shift key, it will either go smaller or larger than I intend. In other words, when I stop moving the encoder, the iris keeps moving. I am getting the same behaviour with shutters and colour selection on several different fixtures.

I am seeing my media server (Arkaos MediaMaster) encoder controls rendered useless without the use of the shift key. If I don't use the shift key, any time I try to select a folder, file, effect, or parameter the encoder causes the control to increment in an amount that exceeds what I expect. The controls on MediaMaster are designed to use 255 discreet levels of control per parameter. Requiring me to hold down an additional key when using the encoders does not simplify my use of the console. 

Regardless of what you personally think, I don't think the new change counts as an improvement for they way I have been programming my shows. The control I had over my fixtures before the change worked for me in every situation. I was able to get the fixture pointed where I wanted them, and I was able to get the colours, iris sizes and files and folders that I wanted selected without having to resort to the use of an extra control. 

I used to be able to busk a show by using the pan/tilt encoders at the same time in order to follow a performer around the stage with a moving fixture with more control over the fixture's movement that I was able to achieve with a trackball. I can't do that anymore.

I don't know how I can put this any more simply: By requiring the use of an additional control (i.e. the Shift key) to achieve what I was able to do before without it, you have not simplified or improved my situation. You have added an additional layer of complexity to my console.

Yes, you may find it to be the cat's pyjamas, but I find it to be irritating. My staff finds it to be irritating, and several colleagues that I have spoken to find it to be irritating. I completely understand that it is useful to have super fine control over 16-bit controls, however, all of the encoders now move in levels that are coarser than 1 level out of 255 per detent on the wheel regardless of whether the parameter they are controlling is 8-bit or 16-bit. This is the case even if I set the encoders to the totally ridiculous setting of 10% and 1 Degree per rotation. Certainly a 16-bit feature encoder should have a coarse/fine toggle, but there is no need for that on an 8-bit parameter. What I am asking for is a setting on the encoders where one detent is 1 increment out of 255 without using the Shift key like it was before the change. 

I would welcome your explanation on how this change is better in my situation. Tell me what it is that I am missing, because I simply don't see how any of this is an improvement for me.

Thanks! 

Hi Charles,

I totally appreciate the issues you're having, I'm not belittling those at all. There are some things that can be done to resolve those without reverting to the previous behaviour however. There are always going to be edge cases and certain scenarios which don't work for certain people, and it's not always possible to have options for everything or else we'd end up with a console that is totally useless to everyone. ETC work very hard to consider how changes impact users and there are a large group involved who work with the console in various ways to feedback early in the development process.

What you are missing is actually the possibilities that are opened up by this change which will be coming down the line. Sometimes things have to change to allow improvements and new features. Adding an option to revert to previous behaviour would mean that those new improvements can't work for you. That said I totally get that this change has not made the way you operate easier, in fact it's introduced a number of challenges.

That said I'm not seeing any of these issue on Gio encoders, so I'm sure ETC will look into this further.

Best

Dan

 

 

Hi Charles,

I totally appreciate the issues you're having, I'm not belittling those at all. There are some things that can be done to resolve those without reverting to the previous behaviour however. There are always going to be edge cases and certain scenarios which don't work for certain people, and it's not always possible to have options for everything or else we'd end up with a console that is totally useless to everyone. ETC work very hard to consider how changes impact users and there are a large group involved who work with the console in various ways to feedback early in the development process.

What you are missing is actually the possibilities that are opened up by this change which will be coming down the line. Sometimes things have to change to allow improvements and new features. Adding an option to revert to previous behaviour would mean that those new improvements can't work for you. That said I totally get that this change has not made the way you operate easier, in fact it's introduced a number of challenges.

That said I'm not seeing any of these issue on Gio encoders, so I'm sure ETC will look into this further.

Best

Dan