Strange slowness with Lemur on iOs to control moving light
Strange slowness with Lemur on iOs to control moving light
I use my iPhone and iPad to adjust the pan tilt position of my moving light. It works extremely well and is very reactive. Today when I did it it asked incredibly Lafarge it on both the iPhone and the iPad moving a slider takes minutes to react to all the positions instead of moving in real time. Curious if you have any ideas or if I should go back to an older Version of LX
Mark Nizer
mark@nizer.com
mark@nizer.com
slow OSC
rollback to 5.0.0 fixed it.
I think you mean "Disable loopback prevention". I have that checked in the preferences.
Should try the new version and UNCHECK it?
I think you mean "Disable loopback prevention". I have that checked in the preferences.
Should try the new version and UNCHECK it?
Mark Nizer
mark@nizer.com
mark@nizer.com
loopback prevention will stay the same in both versions. What you are experiencing sounds like a feedback loop where things become unresponsive. But, if going back a version fixed the problem that may not be it. OR what gets you into the loop is a random set of circumstances. And, you lucked out when you started the older version. But, it will happen again. Unless you have a very good reason to disable loopback prevention, I wouldn't do it.
Are you using MIDI by any chance? The other possibility is that the default control changes for the faders are duplicated in your other controls and that is messing things up. Only the newer version has the faders tab. So, that could be the difference.
Are you using MIDI by any chance? The other possibility is that the default control changes for the faders are duplicated in your other controls and that is messing things up. Only the newer version has the faders tab. So, that could be the difference.
I am using MIDI
I am using MIDI.
What does MIDI have to do with it? What does that change?
What does MIDI have to do with it? What does that change?
Mark Nizer
mark@nizer.com
mark@nizer.com
More infö on slowness
Here are the OSC messages I am sending from Lemur.
Fire the light cue:
/cmd.lxconsole/GO:400.1
Select the cue:
/cmd.lxconsole/400
The slider: for pan
/cmd.lxconsole/400.2@%p
Close the shutter:
/cmd.lxconsole/400.50@0
Record the Group cue:
/cmd.lxconsole/recordgroup!:11
Oddly these all have 90 Note On in the MIDI tab (the default) in Lemur.
Fire the light cue:
/cmd.lxconsole/GO:400.1
Select the cue:
/cmd.lxconsole/400
The slider: for pan
/cmd.lxconsole/400.2@%p
Close the shutter:
/cmd.lxconsole/400.50@0
Record the Group cue:
/cmd.lxconsole/recordgroup!:11
Oddly these all have 90 Note On in the MIDI tab (the default) in Lemur.
Mark Nizer
mark@nizer.com
mark@nizer.com
This turns out to be a regression from early last March (fixing one thing broke another).
The problem had to do with an internal "shortcut" with OSC commands where a channel is set to a level. These commands are detected and then handled differently, bypassing the normal command line. Without this shortcut, the commands are processed as if they were typed into the command line. How the difference appears is that commands that don't use the "shortcut" lag horribly when levels are changed many time in rapid succession as with a slider or similar control. Specifically, the regression did not identify channels having a subchannel component. For example, 300@%p would be different than 400.2@%p because the former would bypass the UI and get handled faster.
This is fixed in the latest build. Now, 300@%p and 400.2@%p will both be interpreted with the faster code.
The problem had to do with an internal "shortcut" with OSC commands where a channel is set to a level. These commands are detected and then handled differently, bypassing the normal command line. Without this shortcut, the commands are processed as if they were typed into the command line. How the difference appears is that commands that don't use the "shortcut" lag horribly when levels are changed many time in rapid succession as with a slider or similar control. Specifically, the regression did not identify channels having a subchannel component. For example, 300@%p would be different than 400.2@%p because the former would bypass the UI and get handled faster.
This is fixed in the latest build. Now, 300@%p and 400.2@%p will both be interpreted with the faster code.