Howdy. So this doesn't seem like it's worth implementing as a standard feature in QLC+, as I can imagine it is possible to achieve with scripting (which is where my ability level is useless) but here is something that would be useful, particularly in my current test environment which is using QLC+ to drive a home automation / lighting scenario.
Basically, my thinking is that there would be a set of button on the Virtual Console to control the overall lighting level. So there are different colour presets, and instead of having to create different brightness presets for each (Blue Wash, Blue Wash @ 50%, Blue Wash @ 25% etc.) there are just a row of buttons up the top such as 100%, 75% 50% etc.
The idea would be that when these are pressed, a slow fade of the grand master ocurrs to the corresponding level.
Now I"m pretty sure this can't be implemented using standard QLC+ feature set, but anyone got any ideas about doing it via a script? Maybe the crossfade time should be set by a widget in the VC...
Automated Grand Master levels
I just realised that this probably makes more sense to do with a Submaster fader...
So basically what we're talking about is a script function that smoothly changes the value of a submaster fader....
So basically what we're talking about is a script function that smoothly changes the value of a submaster fader....
Well i'm slowly edging my way there. Hopefully someone has a solution. I had an idea to create a 'fixture' that is just basically a single dimmer channel, and somehow linking this fixture's output to the submaster slider/knob. Then I can create a chase that fades different values of this fixture, which in turn would speak to the submaster, which in turn would alter the level of all the channels the submaster controls...
Is there an easy way of creating this connection between a fixture's output and a submaster, without creating all sorts of silly inputs and outputs between universes?
Or another way of putting it - instead of having a slider controlled by an 'external input', is it possible to have it's value controlled by an 'internal input' ? ie. DMX or fixture intensity?
Is there an easy way of creating this connection between a fixture's output and a submaster, without creating all sorts of silly inputs and outputs between universes?
Or another way of putting it - instead of having a slider controlled by an 'external input', is it possible to have it's value controlled by an 'internal input' ? ie. DMX or fixture intensity?
Hi FactorFilms and other qlc users,
I had the idea a while back that it would be useful if a submaster slider could be replaced by a button associated with these parameters:
a) a level for the submaster
b) fade in and out times to reach that level and return to zero
You could then select all the submaster levels you need by putting a series of such buttons in a solo frame, which in turn would be inside the frame controlled by the submaster.
Personally, I would find this feature very useful for automating the fading in and out of running chases.
If sets of the above parameters could then be assembled like Scenes in a Chaser and the resulting structure run from a button, I believe this would get the result you want while staying more in keeping with the overall logic of qlcplus.
I had the idea a while back that it would be useful if a submaster slider could be replaced by a button associated with these parameters:
a) a level for the submaster
b) fade in and out times to reach that level and return to zero
You could then select all the submaster levels you need by putting a series of such buttons in a solo frame, which in turn would be inside the frame controlled by the submaster.
Personally, I would find this feature very useful for automating the fading in and out of running chases.
If sets of the above parameters could then be assembled like Scenes in a Chaser and the resulting structure run from a button, I believe this would get the result you want while staying more in keeping with the overall logic of qlcplus.
Here I've made a little video mockup to show the functionality that I'm talking about.
[[embed url=http://www.youtube.com/watch?v=4mKpU7lt4WY]]
[[embed url=http://www.youtube.com/watch?v=4mKpU7lt4WY]]
Yes, indeed it would be useful.
However you can currently achieve something similar if your fixtures have a separate intensity channel. Check out the attached file.
However you can currently achieve something similar if your fixtures have a separate intensity channel. Check out the attached file.
- Attachments
-
- Automated%20Grand%20Master%20levels.qxw
- (3.87 KiB) Downloaded 288 times
Hmmm that is a nice solution. Unfortunately none of the fixtures I'm using have an intensity channel (they are just simple 3 channel RGB LED drivers).
I wonder if there is a way of creating an intensity channel, purely in software, for a standard 3 channel fixture. So it's like a submaster of its own, that basically just acts on the RGB channels before they are sent out as DMX. That would be a way of solving this whole problem. Then the implantation that you've done would work also for 3 channel sources.
I wonder if there is a way of creating an intensity channel, purely in software, for a standard 3 channel fixture. So it's like a submaster of its own, that basically just acts on the RGB channels before they are sent out as DMX. That would be a way of solving this whole problem. Then the implantation that you've done would work also for 3 channel sources.
Hi,
I have been looking at this and came up with a dummy fixture outputting on OSC, with the same channel as an input.
The input is used as an automation for the sub Master.
https://www.youtube.com/watch?v=0Sp-dlT ... e=youtu.be
I have been looking at this and came up with a dummy fixture outputting on OSC, with the same channel as an input.
The input is used as an automation for the sub Master.
https://www.youtube.com/watch?v=0Sp-dlT ... e=youtu.be
the "virtual dimmer" has been requested [in this post](https://sourceforge.net/p/qlcplus/discu ... /6ea2acce/)
Ok, but remember the magic is in the osc routing.
- Attachments
-
- SubMasterAuto.qxw
- (12.55 KiB) Downloaded 169 times
Ahhh that's the kind of 'input/output loop' I was trying to create!
So I've implemented it, but there is a weird bug where the submaster stops acting on the scene buttons, causing a 'jump' in the levels when it's pressed. Here's my project file.
You'll have to play with the input outputs to get it working. Basically Universe 1 is your actual DMX output. Universe 4 needs to loop back on itself (So input = port #9990, output = YOUR.IP:9990)
It's a bit of an inelegant solution even if it does work, especially when imagining moving the project across onto a Raspberry Pi (which is exactly the scenario of my 'home automation' test environment).
So I've implemented it, but there is a weird bug where the submaster stops acting on the scene buttons, causing a 'jump' in the levels when it's pressed. Here's my project file.
You'll have to play with the input outputs to get it working. Basically Universe 1 is your actual DMX output. Universe 4 needs to loop back on itself (So input = port #9990, output = YOUR.IP:9990)
It's a bit of an inelegant solution even if it does work, especially when imagining moving the project across onto a Raspberry Pi (which is exactly the scenario of my 'home automation' test environment).
- Attachments
-
- SubMaster%20Control.qxw
- (3.92 KiB) Downloaded 185 times
Hi,
I'm having problems getting the bug to replicate. What do you have to do to get the problem, also what version are you running / OS.
It might me that I don't see it as I am only watching the DMX Monitor.
I'm having problems getting the bug to replicate. What do you have to do to get the problem, also what version are you running / OS.
It might me that I don't see it as I am only watching the DMX Monitor.
Yeah it's hard to spot when watching the levels. I imagine it will work on any system, but I'm running 4.8.3 on Max OSX.
It seems to happen when you have a colour preset already running, and then you make a level adjustment to it.
I've made a simplified project so it's easier to spot the problem. It's like the intensity adjustment corrupts the values of the function.
Try this:
Click on 100% and Red 100%. All good so far.
Then click on Blue 100%. Crossfades like a gem.
Then click 50%. Maybe things start getting weird now?
If not then click back to Red 100%. Should crossfade from blue @ 128 to red @ 128. But it will either only get to 64, or there will be a jump before the fade starts.
And then if you click back to 100% it probably won't go all the way back to 255.
To get the functions back at their proper intensity (as directed by the submaster) you need to click them off and on again.
It seems to happen when you have a colour preset already running, and then you make a level adjustment to it.
I've made a simplified project so it's easier to spot the problem. It's like the intensity adjustment corrupts the values of the function.
Try this:
Click on 100% and Red 100%. All good so far.
Then click on Blue 100%. Crossfades like a gem.
Then click 50%. Maybe things start getting weird now?
If not then click back to Red 100%. Should crossfade from blue @ 128 to red @ 128. But it will either only get to 64, or there will be a jump before the fade starts.
And then if you click back to 100% it probably won't go all the way back to 255.
To get the functions back at their proper intensity (as directed by the submaster) you need to click them off and on again.
- Attachments
-
- SubMasterBugProblem.qxw
- (15.1 KiB) Downloaded 116 times
Found It
On the "Warm wash" + "Blue Wash" even though the Adjust function intensity is disabled it is affecting the output. Temporally enable it and wind it all the way to 100%.
That seems to sort it.
This seems to be a problem with the sub-master as it was having the same problem when manually adjusting the slider.
On the "Warm wash" + "Blue Wash" even though the Adjust function intensity is disabled it is affecting the output. Temporally enable it and wind it all the way to 100%.
That seems to sort it.
This seems to be a problem with the sub-master as it was having the same problem when manually adjusting the slider.
Nicely done! That's solved it thank you.
I still think this whole OSC Loop thing is incredibly inelegant - there really should be a way of routing internally, rather than having to route via the network. Now I have to work out how to carry across this OSC nonsense to the Raspberry Pi!
I still think this whole OSC Loop thing is incredibly inelegant - there really should be a way of routing internally, rather than having to route via the network. Now I have to work out how to carry across this OSC nonsense to the Raspberry Pi!
Keep in mind though that a "virtual dimmer" that adjusts intensity levels of three RGB channels is technically VERY different from a REAL intensity channel that adjusts the level of the fixture that is set to a specific RGB color. If you adjust all three channels of RGB independently in a linear way to fade up or down, what will happen is that the light will, as it adjusts in intensity, also change color in a predictable but often odd series of ways (depending on what the RGB levels you are fading to all. If you set an RGB level to a specific value, and then adjust the intensity of the lights, you SHOULD get a smooth fade over the luminance range of the color you have chosen (from black to the color but with the color always the same, much as would happen with a real lighting fixture and a specific gel).
In the old school theater days, you would have two lighting fixtures, one with one color gel and the other with a different color gel (typically "cool" and "warm" but the actual color choices can be anything) and you fade BETWEEN the fixtures, fading one up and the other down.
With RGB color changers, we can replace two fixtures with one (since the single fixture can take on any color) but we end up with this other "color changing" issue that happens when we modify RGB values as a surrogate for modifying intesity.
I expect that some high-end fixtures some day (if this isn't true already) may do something about this problem of cross-fading between two different actual colors by implementing a DUAL-HEAD fixture, i.e., one with TWO lights built into the same fixture, each with its own RGB channels. Then you could do what you REALLY want to do which is turn on one head at some color value, then set the color of the dimmed out head, then cross fade between the two heads, and when you want to go to a third color, do this again but in the reverse direction. If the light were REALLY intelligent, it would do this automatically.
Just me $.20...
In the old school theater days, you would have two lighting fixtures, one with one color gel and the other with a different color gel (typically "cool" and "warm" but the actual color choices can be anything) and you fade BETWEEN the fixtures, fading one up and the other down.
With RGB color changers, we can replace two fixtures with one (since the single fixture can take on any color) but we end up with this other "color changing" issue that happens when we modify RGB values as a surrogate for modifying intesity.
I expect that some high-end fixtures some day (if this isn't true already) may do something about this problem of cross-fading between two different actual colors by implementing a DUAL-HEAD fixture, i.e., one with TWO lights built into the same fixture, each with its own RGB channels. Then you could do what you REALLY want to do which is turn on one head at some color value, then set the color of the dimmed out head, then cross fade between the two heads, and when you want to go to a third color, do this again but in the reverse direction. If the light were REALLY intelligent, it would do this automatically.
Just me $.20...
Also keep in mind that the intensity channel of many inexpensive LED fixtures isn't really intensity at all, but just adjusts the levels of the RGB channel LEDs proportionately. So the light has its own "virtual dimmer" built in as a channel, but it still makes a hash of the colors when you use it.