Posts: 7
Threads: 0
Joined: Jan 2018
10-09-2021, 08:44 PM
(This post was last modified: 10-09-2021, 08:44 PM by PragmaLab.)
Dear Denis (1 'n' , sorry for that -
),
thanks for your explanation. Setting the fader value
in the cuelist while
external controls (executor, fader) will control the cuelist to me seems not the best way to deal with fader values (for each fader type). In this case, you need to store 100% or else the executors will fail.This same 100% that is stored in each cuelist is a pain in the ass when entering a page since starting the cuelist will set intensity to 100% while my physcial fader is at zero.
Due to the choice of storing the fader-values inside the cuelist, in stead of making them dependant of the (external) controls that control the behaviour of the cuelist, indeed seems to cause our problem. Solving it is not easy (as you pointed out several times) since a design choice like this has severe implications.
One thing is not entirely clear to me (despite of your attempts to explain what exactly the problem is): if the fader values are stored for each fader type (as you point out), why not offer the option to set the default per fadertype? Allow 100% for executors and 0% for physical faders
thanks for keeping up with me
kind regards,
Rob
Posts: 369
Threads: 10
Joined: Aug 2018
The issue with that the Cuelist itself does not know anything about faders or executors - it only knows it’s own values.
This has indeed been a design choice at the beginning and as it turns out a rather bad one (especially in this specific case) and I am not sure wether we’ll ever be able to change that in the current generation of consoles.
I‘ll discuss that internally with the developers, but obviously I can’t make any promises.
Posts: 7
Threads: 0
Joined: Jan 2018
10-09-2021, 10:37 PM
(This post was last modified: 10-09-2021, 10:38 PM by PragmaLab.)
The issue with that the Cuelist itself does not know anything about faders or executors - it only knows it’s own values.
I really, really do not understand your issue. The whole idea is that a cuelist stores tons of values for all kind of channels, but the intensity channels (dimmer) are overruled by the fader that controls the intensity.That's the whole and main purpose of a sub fader isn't it?
This has indeed been a design choice at the beginning and as it turns out a rather bad one (especially in this specific case) and I am not sure wether we’ll ever be able to change that in the current generation of consoles.
what exactly is it your are telling me after 4 years waiting for this issue to be addressed? That the design choice is indeed really bad I already knew. But of course this can be addressed, if you can set the default to 100%, you can also set the default to 0% for sub faders as used in cuelists. The chimp is the only console that has this flaw, I've never encountered it in any other console
I‘ll discuss that internally with the developers, but obviously I can’t make any promises.
Not asking for promises, I'm asking for fixing bad design choices as a service to users of your consoles. Great all these 'wizard sheets' and new features that were introduced during the last four years. Decent submaster behaviour should be priority imho
Posts: 369
Threads: 10
Joined: Aug 2018
29-09-2021, 12:47 PM
(This post was last modified: 29-09-2021, 01:03 PM by denishessberger.)
(10-09-2021, 10:37 PM)PragmaLab Wrote: The issue with that the Cuelist itself does not know anything about faders or executors - it only knows it’s own values.
I really, really do not understand your issue. The whole idea is that a cuelist stores tons of values for all kind of channels, but the intensity channels (dimmer) are overruled by the fader that controls the intensity.That's the whole and main purpose of a sub fader isn't it?
As I explained above the fader-level for the dimmer is stored in the cuelist itself (this is not the value of the dimmer attribute of a fixture, but rather the value you set with a fader). Adding a default 0% option is easy, but this also means that a cuelist assigned to an executor button will have its internal "fader" dimmer value set to 0%, hence it will not output anything.
(10-09-2021, 10:37 PM)PragmaLab Wrote: This has indeed been a design choice at the beginning and as it turns out a rather bad one (especially in this specific case) and I am not sure wether we’ll ever be able to change that in the current generation of consoles.
what exactly is it your are telling me after 4 years waiting for this issue to be addressed? That the design choice is indeed really bad I already knew. But of course this can be addressed, if you can set the default to 100%, you can also set the default to 0% for sub faders as used in cuelists. The chimp is the only console that has this flaw, I've never encountered it in any other console
I already outlined the implications that a change like this has on cuelists assigned to executors (or magic sheet) in this thread and the issue itself is far bigger and work intense than just changing the default value.
(10-09-2021, 10:37 PM)PragmaLab Wrote: I‘ll discuss that internally with the developers, but obviously I can’t make any promises.
Not asking for promises, I'm asking for fixing bad design choices as a service to users of your consoles. Great all these 'wizard sheets' and new features that were introduced during the last four years. Decent submaster behaviour should be priority imho
I really understand your frustration concerning this issue, but to be fair (as it is a fundamental issue in the code base; as explained above). I agree, decent Submaster behaviour should be a priority, but so should be fixing many other bugs (some of them which are affecting far more users)
The way to address this would be to move all sub-fader settings and cuelist state itself to the faders / executors making them far more than just a "remote control" of a fader, as then the fader is basically being played back rather then the cuelist. Afaik, this change means rewriting about 80% of the consoles core and structure, and thus I do not see it happening for the current generation of consoles.
Posts: 369
Threads: 10
Joined: Aug 2018
The upcoming version 2.1 will save the fader values in the showfile.
Posts: 7
Threads: 0
Joined: Jan 2018
(04-04-2022, 10:50 PM)denishessberger Wrote: The upcoming version 2.1 will save the fader values in the showfile.
Dear Dennis. Thas is indeed VERY good news. Off course I tried the 2.1 version to see if our annoying problem was fixed.
I opened an existing show, saved it under a different name. Applied 0% to all cuelists in the fisrt pages of our show (enter page, touch fader to change the 100% to 0%) and saved the show. I expected the 0% to be saved in de the showfile.
Software version is 1.2. What am I doing wrong here? Need I start a new show?
Thanks for your time and answers
kind regards
Rob
Posts: 7
Threads: 0
Joined: Jan 2018
(24-06-2022, 09:44 PM)more then year has passed since my last post and still no reply from Dennis. I guess the remark that the issue was solved in 2.1 was just a wish, not a tested improvementPragmaLab Wrote: (04-04-2022, 10:50 PM)denishessberger Wrote: The upcoming version 2.1 will save the fader values in the showfile.
Dear Dennis. Thas is indeed VERY good news. Off course I tried the 2.1 version to see if our annoying problem was fixed.
I opened an existing show, saved it under a different name. Applied 0% to all cuelists in the fisrt pages of our show (enter page, touch fader to change the 100% to 0%) and saved the show. I expected the 0% to be saved in de the showfile.
Software version is 1.2. What am I doing wrong here? Need I start a new show?
Thanks for your time and answers
kind regards
Rob
