Reducing send rate of widgets

Control » General

Reducing send rate of widgets

(4 posts) (2 voices)

Started 2 years ago by paul@villagerstheatre.com
Latest reply from paul@villagerstheatre.com

Tags:

paul@villagerstheatre.com
Member

Is it possible to reduce the rate of transmission of OSC messages from widgets? I'm particularly concerned with sliders.

I'm really not a programmer, but I've dabbled in Perl for years for little stuff so when I discovered there was a CPAN module for OSC I decided to try out using it to control the lights at our theatre. It works, but I suppose maybe Perl is to slow for this task.

We use a Lanbox from http://www.lanbox.com to control the lights. The Lanbox has a very rudimentary but well documented API using one byte commands transmitted as hexidecimal ASCII over a TCP connection. Parameters are sent as additional bytes of hexidecimal.

I wrote a simple Perl script using the Net::OpenSoundControl::Server module http://search.cpan.org/~crenz/Net-OpenSoundControl-0.05/lib/Net/OpenSoundControl.pm to receive OSC messages from Control and send hexidecimal commands to the Lanbox. I'll post the script later if anyone is interested but right now it works poorly.

The problem is that it although the lights start to respond immediately after moving my finger on the iPad screen, they continue changing long after I lift my finger, especially if I drag my finger up and down the slider a couple times.

It appears that every OSC message is being dutifully send to the Lanbox, but the transmission rate of Control is much higher than the throughput of the Perl script because a backlog of level change messages continues to be sent after I lift my finger.

The messages get queued up and sent "as fast as possible" but that isn't fast enough.

It would appear that while touching a slider, Control is sending far more OSC level messages per second than I need. If I could reduce the rate to just a couple messages per second I think my script could keep up and the lights would still be plenty responsive.

Posted 2 years ago #
admin
Key Master
Hi Paul,

Hmmm. Something like this should work; it immediately transmits on initial touch, but after that only sends out every tenth message. You could of course change the 10 value to be whatever you want.
```
{
    "name": "slowSlider",
    "type": "Slider",
    "bounds": [0,0,.6,.2],
    "isLocal": true,
    "ontouchstart": "window.slowSliderCount = 0; PhoneGap.exec('OSCManager.send', this.address, 'f', this.value)",
    "ontouchmove":  "window.slowSliderCount++; if(window.slowSliderCount == 10) { window.slowSliderCount = 0; PhoneGap.exec('OSCManager.send', this.address, 'f', this.value)",
}
```
Please do post the script and the interface if you have a chance! There are a few other people using Control for lighting and I'm sure it will wing up being helpful to someone. Let me know how it goes... - Charlie
Posted 2 years ago #
paul@villagerstheatre.com
Member

After doing some profiling it looks like Perl isn't too slow after all. All the slowness is coming from the subroutine that sends commands to the Lanbox. It takes over a tenth of a second to send each level change command. I'm working on this at home and our Lanbox at the theatre is not Internet accessible so I've been testing against the vendor's demo Lanbox which is on the Internet.

The vendor (http://www.lanbox.com) is in the Netherlands and my average ping time from New Jersey, USA to the demo Lanbox is about 110 ms and the Lanbox protocol is TCP based so I think the Perl subroutine is probably waiting for TCP acknowledgments. I'm going to have to get over to the theatre and see what kind of response time I get when the server running the Perl script is plugged into the same Ethernet switch as the Lanbox.

That being said, the fix you provided works almost perfectly. The only think I had to add was an "ontouchend" function to send one last transmission, otherwise the level sent to the Lanbox tended to not match the level shown on screen in Control.

Posted 2 years ago #
paul@villagerstheatre.com
Member

Based on actual testing at the theatre tonight it looks like slow sending Javascript is the way to go, but a factor of 2 (i.e. sending one OSC message for every two updates of the fader is all that's required to make the lights appropriately responsive to finger movements on the iPad.

Posted 2 years ago #

RSS feed for this topic