Hello There, Guest! Login Register
Fader output max.



17-11-2017, 09:35 AM #1
Hans Offline Member ***
Posts:38 Threads:11 Joined:Oct 2017
Hi,

When I start up a saved show, all my programmed faders are rised up to 100% ( not  fysical, but the supper screenbar, shows in blue 100%), the output still remains zero.
I can only used a programmed fader, when I rise up the fader to 100% and then slide it back to 0, after that it will working normaly. 
What goes wrong?

28-11-2017, 12:38 PM #2
WesleyHouben Offline Administrator *******
Posts:70 Threads:8 Joined:Aug 2017
(17-11-2017, 09:35 AM)Hans Wrote:  Hi,

When I start up a saved show, all my programmed faders are rised up to 100% ( not  fysical, but the supper screenbar, shows in blue 100%), the output still remains zero.
I can only used a programmed fader, when I rise up the fader to 100% and then slide it back to 0, after that it will working normaly. 
What goes wrong?
Hi Hans,

Have you tried running all faders down before you shutdown the desk. Im currently not behind a chimp but i think
the console remembers de last fader position before shut down. 

Cheers,

With kind regards,

Wesley 

28-11-2017, 10:25 PM #3
Hans Offline Member ***
Posts:38 Threads:11 Joined:Oct 2017
(28-11-2017, 12:38 PM)WesleyHouben Wrote:  
(17-11-2017, 09:35 AM)Hans Wrote:  Hi,

When I start up a saved show, all my programmed faders are rised up to 100% ( not  fysical, but the supper screenbar, shows in blue 100%), the output still remains zero.
I can only used a programmed fader, when I rise up the fader to 100% and then slide it back to 0, after that it will working normaly. 
What goes wrong?
Hi Hans,

Have you tried running all faders down before you shutdown the desk. Im currently not behind a chimp but i think
the console remembers de last fader position before shut down. 

Cheers,
Yes I did, before I shut down the console, I set all the used faders to zero/off. 
But when I switched the console on again, all the faders raised to 100% again, so I had to raise up the faders en slide them down to 0, They are not fysical raised to 100% and the output remains also 0.

15-12-2017, 01:06 PM #4
Angelo Offline Moderator *****
Posts:30 Threads:17 Joined:Aug 2017
A Fader executes a Cue to use the Dimmer function (Fader Option -> Auto-start)..when the Chimp is closed down all the Cue's are OFF.

On Start-Up all Cue's are off and have to get a GO, so you have to pull down the faders to initiate a GO commando.

16-01-2018, 05:58 PM #5
PragmaLab Offline Newbie *
Posts:2 Threads:0 Joined:Jan 2018
(15-12-2017, 01:06 PM)Angelo Wrote:  A Fader executes a Cue to use the Dimmer function (Fader Option -> Auto-start)..when the Chimp is closed down all the Cue's are OFF.

On Start-Up all Cue's are off and have to get a GO, so you have to pull down the faders to initiate a GO commando.
We have exact the same problem (100% at startup) and have reported this at Highlite last summer already. They acknowledge that this is undesired behaviour in the scenario that your fysical fader has a dimmer function. Due to the 100%, you can never start the first cue in the list without the dimmer going to full. First you need bring the fader to full, then bring it back to 0 and the 100% becomes 0%. Only then, you can give a GO (start first cue in the cuelist and use the fader to control the dimmer). 

We have 40 pages in a show and each page has some 8 cuelists. Before the show, we need to:
1) go to every page and
2) touch every fader that has a cuelist attached to bring the 100% back to 0%

Only then we can run a show and use the GO buttons for the cuelists. This is unworkable and this issue needs be be fixed in the next release.

Please note that not a single setting (like auto start or whatever) will solve this problem. It is designed behaviour but it is very undesired (at least for theater purposes where a fader in fact is always  the dimmer channel for the corresponding cuelist.). 

And no, the desk does not remember the last fader position at shutdown.
And yes, the cues are off at shutdown, but the 'intentsity' is set to 100% at startup, regardless of the fader position.

Can somebody keep us posted on the progress on this issue? This behaviour is really annoying in our case. Thanks

Rob

11-09-2020, 01:42 PM #6
denishessberger Offline Senior Member ****
Posts:135 Threads:4 Joined:Aug 2018
Thats technically not a bug but expected behavior at the moment. We already have this on our to-do list, 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.
But be assured your feedback is heard Smile

08-11-2020, 03:51 PM #7
PragmaLab Offline Newbie *
Posts:2 Threads:0 Joined:Jan 2018
"But be assured your feedback is heard Smile "

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

09-11-2020, 02:33 PM #8
denishessberger Offline Senior Member ****
Posts:135 Threads:4 Joined:Aug 2018
(08-11-2020, 03:51 PM)PragmaLab Wrote:  "But be assured your feedback is heard Smile "

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.
Quote:[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






Forum Jump:


Users browsing this thread:1 Guest(s)