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! 

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

 

 

If the other suggestions aren't working for you, you might want to try this out:

Copy, then edit your fixtures, making all the attributes you want to be, uh, shiftless on your encoders 16-bit, then clear out the low channel value in the profile (Just select the DMX channel it assigns in the low value column when you switch to 16-bit, and press delete. Done.) - essentially, you're making that attribute "always coarse". Then just repatch those channels with the new fixture profile.

It may not make a bit of difference, but it may bypass the need (or capability) of using shift for any fine adjustments, and shouldn't affect channel counts.

Is it a little fiddly? Yes. But it will, I think, change the console behaviour back to what you're preferring without needing to revert to an earlier version of the OS. I'm not at a console right now to check that for a certainty, though.

Hope that works for you. Please let me know if you try it and what the results were, just in case I need to do it at some point myself.

Cheers,

Jonathan

 

Charles, we understand the issue with media server management.  There are a couple of approaches we can take - and are discussing which would be most appropriate.

In the meantime, we are not aware of any issues with fixtures overshooting or parameters, such as shutters, moving incorrectly.   I spoke with a couple of programmers yesterday who have been using these controls on Ion for a couple of years.   The only time they've seen a parameter overshoot is when the fixture is causing this - and you'd have seen the same issue with the acceleration code.  

If you can let us know what devices you've seen this on (manufacturer/model) we can check with an output viewer to make sure the data is being curtailed properly.   

Thanks much.

Anne

 

Anne,

If you can sort out my media server issue, then we will have sorted out the biggest problem. I have reached the point with a lot of trial and error where I can "almost" control the media server, but at the expense of having the control of my moving lights very sluggish.

We have been having several issues, and have had some luck starting fresh with a clean slate, purging the system of  old profiles and creating a totally new show file. We've never had to resort to such measures before, as we have always built each new production on top of our default file. Obviously, we ended up behind the 8 ball.

Thanks!

hmm... can you elaborate on the issues that are making you purge and start again?   

And I see you did give us a fixture list.  We can check the data output against that and let you know if we see anything odd.  

And if anyone can report about shuttering issues, identification of the unit would be great.

Thanks much!

Anne

 

Anne,

The main issue behind starting from a clean slate was a factor both of the effects of the software upgrade and some overdue housekeeping on our part.

The issues that I have stated above are what we have been experiencing. A lack of control of fixtures without using the shift key. When the encoders are set so that control of moving lights pan and tilt is somewhat reasonable, then control of other parameters is nigh on impossible.

And I guess I just don't have a grasp of how large venues like the National Theatre in the UK are programming, as here in my tiny 400 seat venue with my handful of movers I have never needed the exacting level of control over fixtures that is provided by using the shift key. The encoders in acceleration mode worked for me for years. I would move a fixture where I needed it. set its colour and gobo and other attributes and away we went.

What confuses me, and perhaps you can explain, is, why if the current setting was an option before, can't the old setting be an option now? Dan said that this change will lead to exciting new features down the road, but will these features make any difference to users like me who rather than being on the bleeding edge of technology are stuck in healing scab (or perhaps even old scar mode in the case of our 518s) mode?

Charles, there are two different encoder settings.  You have % per revolution and degrees per revolution (pan/tilt).   setting degrees per revolution should not impact anything other than pan/tilt.

Can you send me your show file, with the channel/parameter you are struggling with.  That will include your encoder settings.  We may be able to offer suggestions.

The acceleration code was really unpredictable.  It was something users complained about for years.    That was the driver behind the change.  

Thanks much!

Anne