[fixed 2.1] Fader output max. - Printable Version +- Highlite Forum (https://forum.highlite.com) +-- Forum: Infinity Chimp (https://forum.highlite.com/forumdisplay.php?fid=46) +--- Forum: Chimp Bug Reports (https://forum.highlite.com/forumdisplay.php?fid=37) +--- Thread: [fixed 2.1] Fader output max. (/showthread.php?tid=54) Pages:
1
2
|
RE: Fader output max. - PragmaLab - 10-09-2021 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 RE: Fader output max. - denishessberger - 10-09-2021 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. RE: Fader output max. - PragmaLab - 10-09-2021 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 RE: Fader output max. - denishessberger - 29-09-2021 (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. 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.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. 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. RE: Fader output max. - denishessberger - 04-04-2022 The upcoming version 2.1 will save the fader values in the showfile. RE: Fader output max. - PragmaLab - 24-06-2022 (04-04-2022, 10:50 PM)denishessberger Wrote: The upcoming version 2.1 will save the fader values in the showfile. RE: Fader output max. - PragmaLab - 21-07-2023 (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. |