It is very strange that the faders would stick during playback of a cue and their position would override what is being sent from LXConsole. Two questions, do the levels in LXConsole reflect the proper levels for the cue fade or do they show the levels of the faders as set by the X32? If you disable MIDI input on LXConsole, will the cue play back and move the faders on the X32 properly?
There are multiple MIDI modes for the X32 and they are not well explained by the documentation: http://www.behringer.com/assets/X32_MID ... -06-04.pdf
It would appear that PERMANENT MIDI ASSIGNMENTS OVERVIEW (REMOTE OFF) will work the best with LXConsole.
BTW, is the only MIDI in this setup the X32 and LXConsole?
Are all the MIDI actions in the LXConsole setup window using the commands like 1@%v, 2@%v, etc.?
X32 as a control surface?
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
1. When both MIDI input and MIDI output on LXConsole are enabled (and configured properly on the X32 as well), the X32 fader settings override the values set in the cues in LXConsole. That is, if Channel 2 in Cue 1 should have a value of 50% and the fader is set to 100%, the cue display in LXConsole shows 100%.
2. If I disable MIDI input on LXConsole (but leave MIDI output enabled), running cues in Live mode works properly and causes the faders to move as expected on the LXConsole.
As you say, there are multiple MIDI modes in LXConsole. I am using it in DAW Remote mode (although switching back to normal mode doesn't change the behavior that I have described). I am also using the following configuration on the X32:
Remote protocol: Mackie MCU
Remote interface: MIDI In/Out
MIDI control interface: MIDI In/Out
MIDI receive: <all types>
MIDI transmit: <all types>
I've actually experimented with other options, but the basic issue that we are discussing seems unaffected.
I have used MIDI in this set up to communicate with QLab as well, but that uses MIDI Channel 16 and is not currently active. No other MIDI devices are connected.
And yes, I am using this configuration to associate MIDI actions with faders:
All 64 faders are associated, and - for input to LXConsole - all work nicely.
[/code]
2. If I disable MIDI input on LXConsole (but leave MIDI output enabled), running cues in Live mode works properly and causes the faders to move as expected on the LXConsole.
As you say, there are multiple MIDI modes in LXConsole. I am using it in DAW Remote mode (although switching back to normal mode doesn't change the behavior that I have described). I am also using the following configuration on the X32:
Remote protocol: Mackie MCU
Remote interface: MIDI In/Out
MIDI control interface: MIDI In/Out
MIDI receive: <all types>
MIDI transmit: <all types>
I've actually experimented with other options, but the basic issue that we are discussing seems unaffected.
I have used MIDI in this set up to communicate with QLab as well, but that uses MIDI Channel 16 and is not currently active. No other MIDI devices are connected.
And yes, I am using this configuration to associate MIDI actions with faders:
Code: Select all
<?xml version="1.0" encoding="utf-8"?>
<midi_actions>
<midi_action>
<note>128</note>
<act>1@%v</act>
</midi_action>
<midi_action>
<note>129</note>
<act>2@%v</act>
</midi_action>
<midi_action>
<note>130</note>
<act>3@%v</act>
</midi_action>
<midi_action>
<note>131</note>
<act>4@%v</act>
</midi_action>
<midi_action>
<note>132</note>
<act>5@%v</act>
</midi_action>
...
[/code]
It sounds as though there is a loop that is preventing bi-directional control. I don't have an X32 to try this out. So I want to make sure I've got it correct: If only MIDI input (LXConsole) is enabled, the X32 controls LXConsole channels properly. If only MIDI output (LXConsole) is enabled, then LXConsole controls the X32 faders properly. It is when both are enabled that there is a problem.
These symptoms certainly point to a loop. On the Yamaha 01v96i that I do have acces to, there is an echo setting. With this disabled, bi-directional control is possible (but sometimes there is resistance when moving multiple faders at one time.)
I'm still wondering if, with both LXConsole MIDI in and out enabled, if you use the command line to adjust a level, does the corresponding fader on the mixer move to the correct level? Also, it would be good to know if when you try to play a cue and the faders don't move to the level recorded in the cue, what is showing as the level in LXConsole?
Without the ability to run MIDI Monitor, I can't tell what is being sent back and forth. But, it is possible that the X32 continuously sends fader levels over MIDI. The Yamaha only sends a message when a fader is moved. But, that could account for the difference between the two boards. If this is what is happening, then the continuous stream of input is telling LXConsole to keep the channel levels equal to the fader position, which overrides the level recorded in the cue. (With LXConsole alone by itself, it is possible to grab a channel and adjust it while a cue is running, overriding the level being played in the cue.) MIDI monitor would show the continuous stream of messages from the X32 and could confirm this theory. Solving the problem is another matter entirely.
If continuous updates from the X32 are not happening, the problem is different and is more of a simple loop prevention scheme. But, there are variations in between.
When any single channel is changed, LXConsole sends out the level of all channels defined in MIDI actions. The idea of this is to insure synchronization. But, it does cause some fader resistance on the Yamaha because there are intermittent points where LXConsole and the Yamaha trade message that are not quite the same. If the X32 sends out all the fader levels in response to a single change, it could be very much like continuous updates with conflicting levels passing each other.
I will think on a way of having LXConsole determine when to talk and when to listen. But, the answers to the above questions could provide clues in how to make this happen correctly.
These symptoms certainly point to a loop. On the Yamaha 01v96i that I do have acces to, there is an echo setting. With this disabled, bi-directional control is possible (but sometimes there is resistance when moving multiple faders at one time.)
I'm still wondering if, with both LXConsole MIDI in and out enabled, if you use the command line to adjust a level, does the corresponding fader on the mixer move to the correct level? Also, it would be good to know if when you try to play a cue and the faders don't move to the level recorded in the cue, what is showing as the level in LXConsole?
Without the ability to run MIDI Monitor, I can't tell what is being sent back and forth. But, it is possible that the X32 continuously sends fader levels over MIDI. The Yamaha only sends a message when a fader is moved. But, that could account for the difference between the two boards. If this is what is happening, then the continuous stream of input is telling LXConsole to keep the channel levels equal to the fader position, which overrides the level recorded in the cue. (With LXConsole alone by itself, it is possible to grab a channel and adjust it while a cue is running, overriding the level being played in the cue.) MIDI monitor would show the continuous stream of messages from the X32 and could confirm this theory. Solving the problem is another matter entirely.
If continuous updates from the X32 are not happening, the problem is different and is more of a simple loop prevention scheme. But, there are variations in between.
When any single channel is changed, LXConsole sends out the level of all channels defined in MIDI actions. The idea of this is to insure synchronization. But, it does cause some fader resistance on the Yamaha because there are intermittent points where LXConsole and the Yamaha trade message that are not quite the same. If the X32 sends out all the fader levels in response to a single change, it could be very much like continuous updates with conflicting levels passing each other.
I will think on a way of having LXConsole determine when to talk and when to listen. But, the answers to the above questions could provide clues in how to make this happen correctly.
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
Thanks for the thoughtful reply.
And yes, it seems to me as if it must be a loop.
As to your questions:
1. With both MIDI in and out enabled on the X32, typing 2@50<Enter> causes the fader on the X32 to move as expected.
2. Given three cues, 1 which sets Channel 1>4 to 0, 2 which sets those channels to 50, 3 which sets those channels to 100.
With MIDI in disabled and MIDI out enabled, running each cue moves the faders as expected and LXConsole shows the correct levels on its display. If I move the faders between cues, LXConsole will make them jump to the correct position for the start of the cue, and then move them slowly into the new position as the cue runs.
With MIDI in enabled and MIDI out enabled, LXConsole displays the value of the current position of the fader and never moves it. Running the cues has no effect - either on the display in LXConsole or on the faders. However, trying to move the faders is difficult - clearly, both LXConsole and the X32 are trying to control them.
And yes, it seems to me as if it must be a loop.
As to your questions:
1. With both MIDI in and out enabled on the X32, typing 2@50<Enter> causes the fader on the X32 to move as expected.
2. Given three cues, 1 which sets Channel 1>4 to 0, 2 which sets those channels to 50, 3 which sets those channels to 100.
With MIDI in disabled and MIDI out enabled, running each cue moves the faders as expected and LXConsole shows the correct levels on its display. If I move the faders between cues, LXConsole will make them jump to the correct position for the start of the cue, and then move them slowly into the new position as the cue runs.
With MIDI in enabled and MIDI out enabled, LXConsole displays the value of the current position of the fader and never moves it. Running the cues has no effect - either on the display in LXConsole or on the faders. However, trying to move the faders is difficult - clearly, both LXConsole and the X32 are trying to control them.
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
I have a MIDI monitor. I could likely capture some useful information if you could describe what you need. Would it be helpful if I tried to see if the X32 sends continuous MIDI information about the fader positions?
Also: The X32 forums are quite good. My guess is that if either you or I can formulate the question well, someone there will know (or could find) the answer.
http://forum.music-group.com/forumdispl ... leshooting
Thanks again.
Also: The X32 forums are quite good. My guess is that if either you or I can formulate the question well, someone there will know (or could find) the answer.
http://forum.music-group.com/forumdispl ... leshooting
Thanks again.
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
Running the MIDI Monitor, this is what I see:
The X32 does not send continuous fader position updates. It sends updates when the fader position is changed.
When MIDI out is enabled on LXConsole and MIDI in is disabled, running a cue shows a stream of MIDI updates begin sent from LXConsole to the X32.
But when MIDI out and MIDI in are both enabled, there is not stream of MIDI updates from LXConsole.
The X32 does not send continuous fader position updates. It sends updates when the fader position is changed.
When MIDI out is enabled on LXConsole and MIDI in is disabled, running a cue shows a stream of MIDI updates begin sent from LXConsole to the X32.
But when MIDI out and MIDI in are both enabled, there is not stream of MIDI updates from LXConsole.
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
I'm afraid that I don't see any difference in the interactions between the X32 and LXConsole with 3.8.5 (8904.4).
The behaviors we discussed seem to be unchanged.
Is there some more information that I can give you that might be helpful? Something that I can try, or MIDI logs, or perhaps something that I could try to track down?
Thanks.
The behaviors we discussed seem to be unchanged.
Is there some more information that I can give you that might be helpful? Something that I can try, or MIDI logs, or perhaps something that I could try to track down?
Thanks.
The prior loopback prevention scheme looked at outgoing MIDI messages (tied to channel control actions) and would not send a repeat message (one with the same velocity) for a fraction of a second.
The new strategy is to disable the ability send live channel changes out via MIDI when processing a channel change received from MIDI. And, if a channel change is received from MIDI with the same velocity as was just sent (within a fraction of a second) it is ignored.
I either missed or can't tell from your posts what the actual MIDI channel setup is. LXConsole activates the loopback suppression if both the MIDI in and out channel numbers are the same and the input and output connections have the same name. If the X32 is sending and receiving on different MIDI channels then non of the loopback suppression is applicable.
This last point may explain why there is no change with the new strategy. The solution in that case is to make a preference in the MIDI out section to specifically allow channel change passthrough.
There is a difference with the new scheme and the Yamaha. The resistance when moving multiple faders is eliminated. So, it is clearly an improvement at least for that use.
The new strategy is to disable the ability send live channel changes out via MIDI when processing a channel change received from MIDI. And, if a channel change is received from MIDI with the same velocity as was just sent (within a fraction of a second) it is ignored.
I either missed or can't tell from your posts what the actual MIDI channel setup is. LXConsole activates the loopback suppression if both the MIDI in and out channel numbers are the same and the input and output connections have the same name. If the X32 is sending and receiving on different MIDI channels then non of the loopback suppression is applicable.
This last point may explain why there is no change with the new strategy. The solution in that case is to make a preference in the MIDI out section to specifically allow channel change passthrough.
There is a difference with the new scheme and the Yamaha. The resistance when moving multiple faders is eliminated. So, it is clearly an improvement at least for that use.
It may very well be that manual control is no different. On the Yamaha, the faders are assigned to a specific MIDI channel (1) and specific control changes (cc-1, cc-2, etc. for faders 1,2, etc.). This means that LXConsole's MIDI in must be assigned to MIDI channel 1 to receive input from the faders. It also means that LXConsole's MIDI out must be assigned to MIDI channel 1 to control the faders. It appears that this is the case from the sparse Behringer documentation. If so, then the new version with preference control over allowing channel passthrough won't make a difference.
As an experiment, what happens if you do the following:
Record three cues with different levels. Lets say channels 1 and 2 are at zero in the first cue and at 50% in the second and at full in the third.
Start in cue one in Live mode in the main window and with MIDI Out ON and MIDI In OFF. Click the Go button in the Live window. It sounds like from past experience the faders on the X32 should move to 50% following the fade of cue two. Now enable MIDI In. Click the Go button again without doing anything else. The expected behavior is that the faders will continue to full as cue three runs. If they do not move and the levels in the live display don't change, it will be the same as before. But, it is more likely that we can definitively say it is the MIDI In setting that made the difference.
A MIDI capture may be useful. But, it is hard to correlate it with events. A place to start is with a simple experiment of capturing traffic with MIDI In and Out On and with a specific isolated thing like setting a level using the command line. A capture of an isolated sequence of running a cue might be useful if it is clearly only from the GO click to the end of the cue.
I'm tending to think that the problem is presenting as a MIDI issue but it very well could be something else and this is just where it shows up.
As an experiment, what happens if you do the following:
Record three cues with different levels. Lets say channels 1 and 2 are at zero in the first cue and at 50% in the second and at full in the third.
Start in cue one in Live mode in the main window and with MIDI Out ON and MIDI In OFF. Click the Go button in the Live window. It sounds like from past experience the faders on the X32 should move to 50% following the fade of cue two. Now enable MIDI In. Click the Go button again without doing anything else. The expected behavior is that the faders will continue to full as cue three runs. If they do not move and the levels in the live display don't change, it will be the same as before. But, it is more likely that we can definitively say it is the MIDI In setting that made the difference.
A MIDI capture may be useful. But, it is hard to correlate it with events. A place to start is with a simple experiment of capturing traffic with MIDI In and Out On and with a specific isolated thing like setting a level using the command line. A capture of an isolated sequence of running a cue might be useful if it is clearly only from the GO click to the end of the cue.
I'm tending to think that the problem is presenting as a MIDI issue but it very well could be something else and this is just where it shows up.
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
I tried your experiment
Start in cue one in Live mode in the main window and with MIDI Out ON and MIDI In OFF. Click the Go button in the Live window. It sounds like from past experience the faders on the X32 should move to 50% following the fade of cue two. Now enable MIDI In. Click the Go button again without doing anything else. The expected behavior is that the faders will continue to full as cue three runs. If they do not move and the levels in the live display don't change, it will be the same as before. But, it is more likely that we can definitively say it is the MIDI In setting that made the difference.
and precisely what you predicted occurred. So I think that we can confirm the diagnosis.
And yes, the Behringer does send cc-0 for fader 1, cc-1 for fader 2 and so on.
If you can think of a set of MIDI sequences that I could capture - labelling them as clearly as I can for you - I could do that next week.
As I think about this: Assuming that this is a MIDI feedback issue and not something else...
What if LXConsole didn't (as an option, perhaps) listen to incoming cc MIDI data during playback of a cue? Is there a way - either automatically or perhaps when it received some specific MIDI input - that it could switch between listening and not listening to incoming MIDI. Even if it couldn't be automatic: I could live with pressing some toggle on the X32 to signal to LXConsole when I wanted it to attend to the location of the faders. And then I could press it again to toggle it off and allow LXConsole to be in full control.
Of course, something slick and automatic would be better - but a manual toggle seems like it could work fine.
Thanks.
-
timmrogers
- Posts: 51
- Joined: Sat Sep 06, 2014 4:29 am
I'm looking forward to trying the latest version when I get into work tomorrow. I'll let you know.
But thinking about it: It seems as if this will likely work nicely for cue playback.
But my guess is that we will still have feedback problems if I want to change fader settings once the cue is complete. Both LXConsole and the X32 will be trying to control the fader.
Perhaps LXConsole should be "in charge" only when cues are running? Would it make sense for LXConsole to defer to the X32 the rest of the time, and only send fader CC data to the X32 when it is running a cue?
Thanks again. I'm excited to see if we can make this work!
But thinking about it: It seems as if this will likely work nicely for cue playback.
But my guess is that we will still have feedback problems if I want to change fader settings once the cue is complete. Both LXConsole and the X32 will be trying to control the fader.
Perhaps LXConsole should be "in charge" only when cues are running? Would it make sense for LXConsole to defer to the X32 the rest of the time, and only send fader CC data to the X32 when it is running a cue?
Thanks again. I'm excited to see if we can make this work!