Hi,
First of all I would like to thank you for all the hard work you have put into the software so far, it is by far the best control software I have used.
I would find it useful that when a slider on the virtual console is set to level mode, that it could be set to act like a motorised fader - e.g. if a function is running that uses the fixture that the slider is linked to, the slider is in a position relative to the current output value, if that makes sense?
My thinking behind this is quite often during shows I quite often need to make tweaks to lighting on the fly, e.g. being able to fade out/change the level of individual lights (mainly generic fixtures), so I tend to set up sliders in a frame in a similar format to conventional desk, however currently it tends to jump as the slider is not set to the current output value. Having the ability to do this would make it easy to increase/decrease the brightness of a lamp.
Another thing I thought, would it be possible to embed a dmx output box into the virtual console, in a similar way to a frame, where it can be collapsed, but easily found?
I would love to help out with the project, but alas I don't know QT4, however when I get a few spare hours I plan to sit down and create a load of fixture identities to add to the project.
Many Thanks
Chris
Motorized faders
-
Jano Svitok
LIVE FADERS: I also thought about this (also with regard to XYPad and moving heads). It would be handy to adjust the positions in operate mode. On the other hand, there may be situations where you don't want the fader to move (i.e. you want it to keep its position). For example, for HTP channels, you set a channel to a value, then run some function and you want the channel to return back when the function stops.
DMX OUTPUT: [DMX Studio](http://xoomer.virgilio.it/dmx_studio_64/) has very handy [widget](http://xoomer.virgilio.it/dmx_studio_64 ... age310.jpg) to display DMX values on the desk - it shouldn't be hard to implement it.
HELP & QT4: If you know C++, for start you may get by with little knowledge of Qt, some basic principles (what are [the signals and slots](http://qt-project.org/doc/qt-4.8/signalsandslots.html), maybe [QObject](http://qt-project.org/doc/qt-4.8/qobject.html), and [QTestLib](http://qt-project.org/doc/qt-4.8/qtestlib-manual.html)) and the rest is just reading [the reference](http://qt-project.org/doc/qt-4.8/) and learning the missing bits as you encounter them.
DMX OUTPUT: [DMX Studio](http://xoomer.virgilio.it/dmx_studio_64/) has very handy [widget](http://xoomer.virgilio.it/dmx_studio_64 ... age310.jpg) to display DMX values on the desk - it shouldn't be hard to implement it.
HELP & QT4: If you know C++, for start you may get by with little knowledge of Qt, some basic principles (what are [the signals and slots](http://qt-project.org/doc/qt-4.8/signalsandslots.html), maybe [QObject](http://qt-project.org/doc/qt-4.8/qobject.html), and [QTestLib](http://qt-project.org/doc/qt-4.8/qtestlib-manual.html)) and the rest is just reading [the reference](http://qt-project.org/doc/qt-4.8/) and learning the missing bits as you encounter them.
-
chrisjfarrell
With regards to live faders I thought the same, I was thinking maybe having a switch on the individual slider which would allow you to set it to be live or not.
Sadly I'm primarily a PHP developer, but have a little C++ knowledge - when I get a moment I'll brush up my skills a bit, and hopefully I can then be of some help.
Sadly I'm primarily a PHP developer, but have a little C++ knowledge - when I get a moment I'll brush up my skills a bit, and hopefully I can then be of some help.
-
James Elliott
Oh, gee, I had been assuming the virtual console worked this way (my current, much more simplistic, lighting software, DMXIS, does so) and had been looking to extend this capability over OSC to the iPad control surfaces I have been building in TouchOSC. But you’re saying that when oscillators, etc., are driving channels, this is not reflected in the positions of faders or XY pads within the app itself? I would definitely want this capability.
-
Massimo Callegari
I don't know if my mind is twisted, but here's the first scenario I think of:
- Slider #1 assigned to R+G+B channels of a group of fixtures
- Slider #2 assigned to R channels of the same group of fixtures
How is it possible to determine what happens to #1 if I change #2 ?
Also, if #1 has RGB Click & Go enabled, it becomes really hard to "motorize" it to a "make sense" value.
- Slider #1 assigned to R+G+B channels of a group of fixtures
- Slider #2 assigned to R channels of the same group of fixtures
How is it possible to determine what happens to #1 if I change #2 ?
Also, if #1 has RGB Click & Go enabled, it becomes really hard to "motorize" it to a "make sense" value.
-
chrisjfarrell
I was more thinking that it should be 1 way, e.g. slider 1 changing slider 2, but not vice versa. i.e. I was thinking that the functionality should be from functions affecting sliders in level mode (effectively following the dmx output for the associated channel), but not in any other scenario. As you quite rightly put, I cannot see how it would work in reverse.
Maybe jump to the point than actually have the slider animate to the point might be easier once the channel hasn't had any changes within a period?
I'm not QT developer, so I'm not certain how difficult it would be.
Maybe jump to the point than actually have the slider animate to the point might be easier once the channel hasn't had any changes within a period?
I'm not QT developer, so I'm not certain how difficult it would be.
-
James Elliott
Ah! I had not considered the possibility of a slider being mapped to more than one DMX channel, because DMXIS, which I am coming from, has no such level of abstraction. Still, I think there is an ok answer, because the reason the user may want to push motorized sliders is to manually tweak settings in an ongoing show. For example, to nudge the position of one of my moving-head spots, I really need to be able to see where it is now before I drag the X-Y pad.
So if the motorized slider #1 in your example gets “pushed” to a position that is the average of the RGB values that it is controlling, you will be able to see it moving in a way which makes conceptual sense when slider #2 is moved, and if you nudge it yourself, it would assign all the RGB values to the new positions, but it would be starting from a position that is closer to “reality” than if it had not been “motorized” at all.
But I am more concerned about controls that control a single DMX channel, and more concerned with being able to manipulate them via OSC, so that I can use my lovely multi-touch control surface layouts within TouchOSC on the iPad to tweak the show as it runs. And even that is a ways off, after I learn a lot more about this exciting software.
So if the motorized slider #1 in your example gets “pushed” to a position that is the average of the RGB values that it is controlling, you will be able to see it moving in a way which makes conceptual sense when slider #2 is moved, and if you nudge it yourself, it would assign all the RGB values to the new positions, but it would be starting from a position that is closer to “reality” than if it had not been “motorized” at all.
But I am more concerned about controls that control a single DMX channel, and more concerned with being able to manipulate them via OSC, so that I can use my lovely multi-touch control surface layouts within TouchOSC on the iPad to tweak the show as it runs. And even that is a ways off, after I learn a lot more about this exciting software.
-
tony schuite
this could be interesting, single channel midi/osc feedback.
what if we would add this to the simple desk:
the simple desk is layed out kind of link a midi control interface (it has pages of a fixed number of faders). The faders on the simple desk could have a midi note defined to it, including feedback. When in live mode, the simple desk already adjusts to each individual DMX value when a scene or chaser is active, so no reprogramming of QLC+ would be needed on this part.
Now the tricky part (imho) would be to allow the simple desk to overrule a set dmx value of the active scene or chaser. I think I suggested the following in a different topic as well. There I suggested that when you change the slider to the active DMX value it would overtake that specific value. Some lighting consoles actually function that way.
As for motorized faders this would be a little more difficult. because of the feedback that QLC+ would give, the faders would get stuck.
In that case a different option would also be a solution. What about an overrule button on the simple desk of each of the faders? Might even be easier to implement. press the overrule button, either in the software or on your control interface with an assigned midi action. change the value of the slider. With motorized faders this would be perfect since the fader is already in the active position, you can move it any way you like.
just my two cents
what if we would add this to the simple desk:
the simple desk is layed out kind of link a midi control interface (it has pages of a fixed number of faders). The faders on the simple desk could have a midi note defined to it, including feedback. When in live mode, the simple desk already adjusts to each individual DMX value when a scene or chaser is active, so no reprogramming of QLC+ would be needed on this part.
Now the tricky part (imho) would be to allow the simple desk to overrule a set dmx value of the active scene or chaser. I think I suggested the following in a different topic as well. There I suggested that when you change the slider to the active DMX value it would overtake that specific value. Some lighting consoles actually function that way.
As for motorized faders this would be a little more difficult. because of the feedback that QLC+ would give, the faders would get stuck.
In that case a different option would also be a solution. What about an overrule button on the simple desk of each of the faders? Might even be easier to implement. press the overrule button, either in the software or on your control interface with an assigned midi action. change the value of the slider. With motorized faders this would be perfect since the fader is already in the active position, you can move it any way you like.
just my two cents
-
em-maps
First, thanks for the software! I heard about it earlier this week and I've been enjoying learning it. I have run the current version on both OSX and Windows 7 with great success. And I have created a few definitions that I will post.
Most of the above programming discussion is beyond me, but I would like to agree with what Jano and James say about the X-Y pad. It would be excellent if the pad updated in real time so we could adjust movers from their current position.
Most of the above programming discussion is beyond me, but I would like to agree with what Jano and James say about the X-Y pad. It would be excellent if the pad updated in real time so we could adjust movers from their current position.