Great project!
Just want to tell you both that I follow this with great interest.
The X32 is a nice gamechanger and Im thinking about buying one for our small stage, in which all lights are run by LXConsole.
X32 as a control surface?
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
The X32 really is an amazing mixer. Being able to use it together with QLab to control our 16 wireless mics - along with a bunch of other inputs - has unlocked their potential for us.
And if we can also use it as a control surface to set the lights and then use LXConsole + QLab to run them...I will be very, very happy!
And if we can also use it as a control surface to set the lights and then use LXConsole + QLab to run them...I will be very, very happy!
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
I was able to test the newest version of LXConsole with the X32 this morning.
And it is a huge improvement. LXConsole is able to run cues smoothly, and they appear to work fine.
A couple of issues though:
(1) The issue of "contention" for control of the faders remains. I cannot easily control the faders once the cue is complete. This, of course, is completely predictable - once the cue is complete, both LXConsole and the X32 are trying to control the fader. I wonder if it might be best if LXConsole - at least when it is working with the X32 - ONLY controlled the faders when it was running cues. Is there a reason that I can't see why it should work otherwise?
(2) A smaller issue (and perhaps no issue at all) is that, is I do wrestle the fader to a new location after the cue is complete, when the next cue runs, LXConsole does not "snap" the fader to the original location and then move it to to target levels. It simply begins where is now is and move it to the new level over the duration of the fader. Of course, that may be how is is supposed to work! But I was surprised.
I really appreciate your willingness to work with me on this. And I apologize for my lack of knowledge about how traditional lighting consoles work. I think that if I knew that better, I could be more helpful!
But thank you.
And it is a huge improvement. LXConsole is able to run cues smoothly, and they appear to work fine.
A couple of issues though:
(1) The issue of "contention" for control of the faders remains. I cannot easily control the faders once the cue is complete. This, of course, is completely predictable - once the cue is complete, both LXConsole and the X32 are trying to control the fader. I wonder if it might be best if LXConsole - at least when it is working with the X32 - ONLY controlled the faders when it was running cues. Is there a reason that I can't see why it should work otherwise?
(2) A smaller issue (and perhaps no issue at all) is that, is I do wrestle the fader to a new location after the cue is complete, when the next cue runs, LXConsole does not "snap" the fader to the original location and then move it to to target levels. It simply begins where is now is and move it to the new level over the duration of the fader. Of course, that may be how is is supposed to work! But I was surprised.
I really appreciate your willingness to work with me on this. And I apologize for my lack of knowledge about how traditional lighting consoles work. I think that if I knew that better, I could be more helpful!
But thank you.
There is now a new build (8908.2) that has a "Playback Only" preference for sending MIDI control changes linked through actions to individual channel levels.
It is preferable that remotely linked faders are synchronized to reflect the state of channels in LXConsole. Channels always fade from their current level to whatever level is defined in the cue being played. So, hopefully, remote faders are already at the same level as LXConsole's channels' live state and therefore don't jump at the start of a cue. With "playback only", there is no guarantee that this will be the case as a level can change in LXConsole and it will not be sent out via MIDI except when a cue is being run. If the fader and the live channel level are not the same, the fader will jump to the channel level when the cue is started.
It is preferable that remotely linked faders are synchronized to reflect the state of channels in LXConsole. Channels always fade from their current level to whatever level is defined in the cue being played. So, hopefully, remote faders are already at the same level as LXConsole's channels' live state and therefore don't jump at the start of a cue. With "playback only", there is no guarantee that this will be the case as a level can change in LXConsole and it will not be sent out via MIDI except when a cue is being run. If the fader and the live channel level are not the same, the fader will jump to the channel level when the cue is started.
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
Wow! The latest build (8908.2) - with "Playback Only" enabled - works beautifully!
In Live mode, cues fade smoothly to the new values, and I can easily adjust the values using the faders on the X32 once the cue is has run to completion.
One small point: If the faders on the X32 are is a position which is different than what LXConsole expects at the start of a cue, they still do not "jump" to the start position of the cue when the cue is run. Instead, they fade slowly from their current position to the proper ending value over the time of the cue. So, if fader 2 should begin at 0% but is actually set on the X32 at 50%, and the cue fades channel 2 to 100%, the fader does not jump from 50% to 0% and then fader to 100%. It simply moves from 50% to 100%.
I'm fine with that. But I wanted to make sure that you know what is what is happening!
Thank you very much!
In Live mode, cues fade smoothly to the new values, and I can easily adjust the values using the faders on the X32 once the cue is has run to completion.
One small point: If the faders on the X32 are is a position which is different than what LXConsole expects at the start of a cue, they still do not "jump" to the start position of the cue when the cue is run. Instead, they fade slowly from their current position to the proper ending value over the time of the cue. So, if fader 2 should begin at 0% but is actually set on the X32 at 50%, and the cue fades channel 2 to 100%, the fader does not jump from 50% to 0% and then fader to 100%. It simply moves from 50% to 100%.
I'm fine with that. But I wanted to make sure that you know what is what is happening!
Thank you very much!
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
So on to the next thing! 
Well, things.
First, fader 1 (cc-0) on the X32 does not respond to MIDI in from LXConsole. That may be an error on my end, of course - but I've looked pretty hard, and I can't find it. MIDI from the X32 to LXConsole works fine. I can set the value of the channel. But - unlike every other fader - channel 1 never moves on the X32 during cue playback.
Is there any chance that cc-0 is being handled differently by LXConsole than other MIDI messages?
Next, if you are willing, I'd like to revisit the question of saving cues and times and so on to LXConsole using the X32 as an interface. I could, of course, use the Mac keyboard to do that, or even something like a phone or tablet with TouchOSC.
But what I would really like is some way to do routine tasks from the X32 itself.
I have some ideas for how it might work. But before I get into that, I need to ask if this is something that you might be interested it. It would require coding. I don't know if you have any interest in doing more to make LXConsole work well with the X32 - even assuming that my ideas would work!
Thanks again.
Well, things.
First, fader 1 (cc-0) on the X32 does not respond to MIDI in from LXConsole. That may be an error on my end, of course - but I've looked pretty hard, and I can't find it. MIDI from the X32 to LXConsole works fine. I can set the value of the channel. But - unlike every other fader - channel 1 never moves on the X32 during cue playback.
Is there any chance that cc-0 is being handled differently by LXConsole than other MIDI messages?
Next, if you are willing, I'd like to revisit the question of saving cues and times and so on to LXConsole using the X32 as an interface. I could, of course, use the Mac keyboard to do that, or even something like a phone or tablet with TouchOSC.
But what I would really like is some way to do routine tasks from the X32 itself.
I have some ideas for how it might work. But before I get into that, I need to ask if this is something that you might be interested it. It would require coding. I don't know if you have any interest in doing more to make LXConsole work well with the X32 - even assuming that my ideas would work!
Thanks again.
The sending out cc-0 was an error. This should be fixed in build 8909.1.
You can certainly request other features. Functions that have a broad general applicability are going to have a higher priority than ones that are narrow and focused on a single situation.
OSC is much more suited to remote interfaces than MIDI is. OSC provides a lot more flexibility in terms of carrying data than MIDI does. OSC's flexibility makes solutions based on it have much more general application. For example, you can design a custom interface in TouchOSC or Lemur that can be used with LXConsole with no configuration in the LXConsole file. Or, at the LXConsole end at all for that matter other than turning OSC on.
You can certainly request other features. Functions that have a broad general applicability are going to have a higher priority than ones that are narrow and focused on a single situation.
OSC is much more suited to remote interfaces than MIDI is. OSC provides a lot more flexibility in terms of carrying data than MIDI does. OSC's flexibility makes solutions based on it have much more general application. For example, you can design a custom interface in TouchOSC or Lemur that can be used with LXConsole with no configuration in the LXConsole file. Or, at the LXConsole end at all for that matter other than turning OSC on.
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
Thanks for the 8909.1 build. I appreciate it.
And I am a huge fan of OSC as well. I love how open and easy to work with it it. The X32 uses OSC extensively. Just not - as far as I can tell - for the user definable controls.
I certainly understand about prioritizing features that have general applicability over those which do not. And in the end, only you can decide how you want to spend your time.
I'll try to describe what I imagine as clearly as I can. And then - I'll keep my fingers crossed!
Thank you.
And I am a huge fan of OSC as well. I love how open and easy to work with it it. The X32 uses OSC extensively. Just not - as far as I can tell - for the user definable controls.
I certainly understand about prioritizing features that have general applicability over those which do not. And in the end, only you can decide how you want to spend your time.
I'll try to describe what I imagine as clearly as I can. And then - I'll keep my fingers crossed!
Thank you.
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
OK, here is what I imagine for input from the X32 to LXConsole.
The X32 has a set of User Assignable controls. There are 4 "encoders" - dials - and 8 buttons. All can be assigned to various functions. For this purpose, I would want to assign them to MIDI signals.
This document shows a photo of that section of the X32 and the interface from which you can assign each encoder and button to a function. Look for "Assignable Controls"
http://www.behringer.com/assets/x32_p0asf_eqsg_en.pdf
I imagine that there was a virtual keyboard in LXConsole which, when visible, accepted input from the Assignable Controls on the X32 via MIDI. Perhaps the buttons are configurable - perhaps they are hard coded. That might be up to you. I imagine that it looks like the Assignable controls on the X32, and has a command line below where you could see the command that you are building.
I would want to be able to, for example, press a button on the X32 which was mapped to "Record", then turn an encoder to dial up a integer which would appear on the screen in LXConsole, and the press a button on the X32 which was mapped to "Enter" - and save the cue.
Perhaps there would be a button for Time which would work the same way. Press the button on the X32 which is mapped to Time, turn the encoder to select a value, press the button mapped to "Enter".
And Cue. Same deal. Press the Cue button on the X32, spin the encoder to select a cue, press the Enter button on the X32.
You would know better how to use the 8 buttons and 4 encoders that I have available.
But the idea would be that we could do the ordinary tasks necessary to record light cues without having to use the LXConsole keyboard. It would be there, of course, if necessary - but for the sorts of things that you do normally, it wouldn't be necessary.
What do you think? Possible? Reasonable? Interesting?
Thank you!
The X32 has a set of User Assignable controls. There are 4 "encoders" - dials - and 8 buttons. All can be assigned to various functions. For this purpose, I would want to assign them to MIDI signals.
This document shows a photo of that section of the X32 and the interface from which you can assign each encoder and button to a function. Look for "Assignable Controls"
http://www.behringer.com/assets/x32_p0asf_eqsg_en.pdf
I imagine that there was a virtual keyboard in LXConsole which, when visible, accepted input from the Assignable Controls on the X32 via MIDI. Perhaps the buttons are configurable - perhaps they are hard coded. That might be up to you. I imagine that it looks like the Assignable controls on the X32, and has a command line below where you could see the command that you are building.
I would want to be able to, for example, press a button on the X32 which was mapped to "Record", then turn an encoder to dial up a integer which would appear on the screen in LXConsole, and the press a button on the X32 which was mapped to "Enter" - and save the cue.
Perhaps there would be a button for Time which would work the same way. Press the button on the X32 which is mapped to Time, turn the encoder to select a value, press the button mapped to "Enter".
And Cue. Same deal. Press the Cue button on the X32, spin the encoder to select a cue, press the Enter button on the X32.
You would know better how to use the 8 buttons and 4 encoders that I have available.
But the idea would be that we could do the ordinary tasks necessary to record light cues without having to use the LXConsole keyboard. It would be there, of course, if necessary - but for the sorts of things that you do normally, it wouldn't be necessary.
What do you think? Possible? Reasonable? Interesting?
Thank you!
The latest build, 3.8.6 (8910.1) adds the ability to simulate key presses in the command line to the list of possible actions triggered by MIDI.
These new actions all begin with "key=" followed by a letter. For example a "key=q" action triggers a simulated press of the "q" key in the command line. From a blank command line, this will expand to "cue: ". Two special keys are enter and escape. These are triggered by action commands "key=enter" and "key=clear". Finally, following the syntax for complete commands, the velocity/value of the MIDI message can be used by an action: "key=%v". This replaces any numeric characters at the end of the command line with the (1-127) velocity/data. The MIDI message received for a "key=" action must have a non-zero velocity in order to trigger the action.
To do what you outline, you would setup your buttons and encoders to send MIDI control changes (or notes in the case of the buttons).
Try mapping the buttons to the following actions:
key=q
key=t
key=r
key=0
key=.
key=enter
key=clear
Try mapping two of the encoders to
key=%v
The reason to use two encoders is to avoid big swings in a single encoder from cue 89 to time 3 and then back to cue 90.
The reason to give yourself a dot and a hard zero is that you can't use key=%v to generate a zero or a number that is not an integer in the range 1-127. ("key=" actions require a non-zero velocity/value to trigger) You may want to set a cue to "time: 0" or "record: 6.5".
You'll need "enter" to finish the command. And, in cases where you are asked for confirmation, to dismiss the warning sheet. You can also dismiss the warning with esc ("clear") and abort the record. esc/"clear" is also useful to clear the command line if you make a mistake building it.
All this follows the similar ability in OSC of using /key.lxconsole/ address patterns. It is general in a way that you could even build an LXConsole remote using the black and white keys of a MIDI keyboard to represent letters and numbers: F#, C, C# could become cue: 1<enter> G#, G, C# time: 5<enter>, etc.
These new actions all begin with "key=" followed by a letter. For example a "key=q" action triggers a simulated press of the "q" key in the command line. From a blank command line, this will expand to "cue: ". Two special keys are enter and escape. These are triggered by action commands "key=enter" and "key=clear". Finally, following the syntax for complete commands, the velocity/value of the MIDI message can be used by an action: "key=%v". This replaces any numeric characters at the end of the command line with the (1-127) velocity/data. The MIDI message received for a "key=" action must have a non-zero velocity in order to trigger the action.
To do what you outline, you would setup your buttons and encoders to send MIDI control changes (or notes in the case of the buttons).
Try mapping the buttons to the following actions:
key=q
key=t
key=r
key=0
key=.
key=enter
key=clear
Try mapping two of the encoders to
key=%v
The reason to use two encoders is to avoid big swings in a single encoder from cue 89 to time 3 and then back to cue 90.
The reason to give yourself a dot and a hard zero is that you can't use key=%v to generate a zero or a number that is not an integer in the range 1-127. ("key=" actions require a non-zero velocity/value to trigger) You may want to set a cue to "time: 0" or "record: 6.5".
You'll need "enter" to finish the command. And, in cases where you are asked for confirmation, to dismiss the warning sheet. You can also dismiss the warning with esc ("clear") and abort the record. esc/"clear" is also useful to clear the command line if you make a mistake building it.
All this follows the similar ability in OSC of using /key.lxconsole/ address patterns. It is general in a way that you could even build an LXConsole remote using the black and white keys of a MIDI keyboard to represent letters and numbers: F#, C, C# could become cue: 1<enter> G#, G, C# time: 5<enter>, etc.
Of course, you'd probably need to be a sound designer to do things this way Most lighting designers want their keys in a nice numeric style keypad rather than the 88 key black and white variety 
But, I respect every contribution to a production. I'm a #Collaborator and sound designers are too--regardless of what the American Theatre Wing thinks.
Most lighting designers want their keys in a nice numeric style keypad rather than the 88 key black and white variety But, I respect every contribution to a production. I'm a #Collaborator and sound designers are too--regardless of what the American Theatre Wing thinks.-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
I wonder if it might be slightly more elegant if we assigned an encoder to decimal values. That is, if encoder 1 was integer, maybe encoder 2 could be decimal. (And then encoder 3 could be integer and encoder 4 decimal - as you suggested.)
So then if I needed to record cue 10.3, I could use encoder 1 to choose 10 and then encoder 2 to choose 3. Just seems a little more natural.
I also wonder if there might be any way to avoid the need for a zero button. I see the issue...I just wonder if there might be some clever approach with the encoders.
Finally, might there be times when we would need values above 127? Perhaps a button to toggle "double input value"?
Thanks.
So then if I needed to record cue 10.3, I could use encoder 1 to choose 10 and then encoder 2 to choose 3. Just seems a little more natural.
I also wonder if there might be any way to avoid the need for a zero button. I see the issue...I just wonder if there might be some clever approach with the encoders.
Finally, might there be times when we would need values above 127? Perhaps a button to toggle "double input value"?
Thanks.
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
I'm happy to say that it all works nicely!
I configured the X32 to send MIDI CC data on cc-96 and cc-97 and on data on note 5-12 (which corresponds to the user button numbers on the X32). Then LXConsole to accept key q, t, r and Enter and Clear.
(I haven't done the zero and . yet.)
If anyone is curious, the user buttons are arranged like this:
5 6 7 8
9 10 11 12
I currently am using:
5 = q
6 = r
7 = unused
8 = Clear
9 = unused
10 = t
11 = unused
12 = Enter
I wonder - at this point - if anyone might have some thoughts on how to best use the buttons that are available. I don't have enough experience with actual light consoles to know what would be the most helpful.
The X32 does have 3 "sets" of user configurable encoders and buttons. And you can easily switch between set A and Set B and Set C.
So a certain set of tasks could be on Set A, another on Set B and so on. All of the 8 buttons and 4 encoders could send different MIDI and thus different keystrokes or functions in LXConsole.
I configured the X32 to send MIDI CC data on cc-96 and cc-97 and on data on note 5-12 (which corresponds to the user button numbers on the X32). Then LXConsole to accept key q, t, r and Enter and Clear.
(I haven't done the zero and . yet.)
If anyone is curious, the user buttons are arranged like this:
5 6 7 8
9 10 11 12
I currently am using:
5 = q
6 = r
7 = unused
8 = Clear
9 = unused
10 = t
11 = unused
12 = Enter
I wonder - at this point - if anyone might have some thoughts on how to best use the buttons that are available. I don't have enough experience with actual light consoles to know what would be the most helpful.
The X32 does have 3 "sets" of user configurable encoders and buttons. And you can easily switch between set A and Set B and Set C.
So a certain set of tasks could be on Set A, another on Set B and so on. All of the 8 buttons and 4 encoders could send different MIDI and thus different keystrokes or functions in LXConsole.