[fixed 2.1] Fader output max.

[denishessberger]

"But be assured your feedback is heard  "

after 2.5 (!) years the only reply on this (yes) bug, is that it is designed behaviour and that we should not worry about the idea that our feedback is lost.

During these 2.5 years, I have

• mentioned this problem 4 times to Highlite engineers/support in person (exhibitons) 
  
• phoned a couple of times about this annoying behaviour of the Chimp with Highlite support
  
• updated the Chimp firmware to keep up with changes and bugfixes: no result
  

Your answer seems not related to this issue:

"but storing fader values and running playbacks is rather challenging (as we'd need to store the order they were started in as well, as well as all current cue numbers, etc), so I have no ETA."

Where's the need to store the order they were started ? Just make sure that playback fader values always follow the physical fader when entering a (new) page. Don't put the fader value to 100% upon entering a page while the physical fader is at 0%

or at least make this an option... Still we need to enter > 40 pages before starting a show and touch each fader to get rid of the 100%. Stupid and annoying as you can imagine.

Thanks

Hi there,

I understand your frustration about this issue, however there are a few things I'd like to mention:

This issue is in the feature request list for a long time, yet it was only reported as problematic by 3 people. So, indeed your feedback is heard.

Saving the Fader Levels in the showfile is on this list for quite a while, including a request to save the whole playback state - as these are tied together in the software, it would make sense for us to implement the full package at once (saving fader levels + playback state), which is also the thing where we'd need to save the order of which cuelists have been started as well (the order affects how the end result will look like). 

Whenever we decide what to do for a release we look at the issues most frequently reported or wished for and assess their priority and complexity. We usually group things together into sensefull groups of how things are built internally - hence, for example, when we started working on multicell we for example added absolute effects and a few other requests (like mutual release groups) as they are basically all in the same place internally in the source code.

[color=#000000][size=medium][font=Times]Just make sure that playback fader values [/font][/size][/color][color=#000000][size=medium][font=Times]always [/font][/size][/color][color=#000000][size=medium][font=Times]follow the physical fader when entering a (new) page. Don't put the fader value to 100% upon entering a page while the physical fader is at 0%[/font][/size][/color]

This, without motorized faders is very problematic, since for many users this would mean that switching a page means that the values output from this page will automatically set to the physical fader values, which may result in undesired output changes.

The whole issue is rather tricky, however I would like you to give me a little tour through your showfile, maybe there are things that could be changed for your showfile to be organized in a way so that this issue is less apparent.

Again, I can only say the feedback is heard, and its sitting together with about 200 other requests on the feature list. If we were to add all these features and all upcoming requests into a software release, we would actually never be able to release it as development time for some of the things is really long.

Overall, I assume that "saving fader values / playback state" is about 1 month of work - so as you can see we always have to do some limbo, in delivering in a timely manner, while still assuring a stable release.

Best,
Denis