Strange slowness with Lemur on iOs to control moving light

LXConsole support and feedback
Post Reply
nizer
Posts: 157
Joined: Sun Jan 23, 2011 1:27 pm
Location: Virginia
Contact:

Strange slowness with Lemur on iOs to control moving light

Post by nizer »

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
admin
Site Admin
Posts: 1643
Joined: Mon Nov 05, 2007 1:26 am
Contact:

Post by admin »

Have you disabled loopback protection? You can try rolling back to a previous version to see if it solves the problem. The only things that would change OSC is the new faders tab. Its unlikely that your custom controls use address patterns that include "fader.lxconsole".
nizer
Posts: 157
Joined: Sun Jan 23, 2011 1:27 pm
Location: Virginia
Contact:

slow OSC

Post by nizer »

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?
Mark Nizer
mark@nizer.com
admin
Site Admin
Posts: 1643
Joined: Mon Nov 05, 2007 1:26 am
Contact:

Post by admin »

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.
nizer
Posts: 157
Joined: Sun Jan 23, 2011 1:27 pm
Location: Virginia
Contact:

I am using MIDI

Post by nizer »

I am using MIDI.

What does MIDI have to do with it? What does that change?
Mark Nizer
mark@nizer.com
nizer
Posts: 157
Joined: Sun Jan 23, 2011 1:27 pm
Location: Virginia
Contact:

More infö on slowness

Post by nizer »

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.
Mark Nizer
mark@nizer.com
admin
Site Admin
Posts: 1643
Joined: Mon Nov 05, 2007 1:26 am
Contact:

Post by admin »

I know your setup is complex. You can e-mail the Lemur and LXConsole files and I can see if I can duplicate the issue and track it down. (I'd need some guidance on which controls in your Lemur do the above commands.)
admin
Site Admin
Posts: 1643
Joined: Mon Nov 05, 2007 1:26 am
Contact:

Post by admin »

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.
Post Reply