Slowing down a bargraph

Dries Kaspers

Hello all,

I was hoping that someone could help me out with the following.
Normally i would use an up/down button for controlling volume but in this case the customer specifically wants a bargraph.

It's a rebuild of an old system which uses an AMX Axcess cardframe with volume control by a Rane SRM66.

I have written a define_call for the Rane that is called when you move the bargraph, and keeps on calling it untill release.

The Rane can't seem to catch up with the amount of strings being sent out . Does anyone have a good idea to slow down the rate at which the strings get sent out? (remember, it's an axcess system, no timelines!).

Thanx!

jeffaco

Certainly you can use a named WAIT statement to slow things down. With a named wait statement, the WAIT statement will only execute once.

So, since you're using Access, you'd have something like this in mainline:

if (fAdjusting_Volume) {
wait 5 'VOLUME_ADJUST' {
(* Code to adjust volume *)
}
}

This will run twice a second. Reduce the WAIT time to run more frequently, but not frequently enough to overwhelm the device.

That said, I wouldn't do it this way (personally). A better way to do this is to get positive feedback from the device on where it's volume is, and to wait for that feedback (and use it to set the bargraph) before sending further commands. As a result, the software is self-limiting based on the speed of the automation system processor AND the speed of the device, and furthermore, you know the bargraph is always in-sync with the device you're controlling.

You can see an example of this in my Meridian code, for example. See:

http://cvs.sourceforge.net/viewcvs.py/netlinx-modules/NetLinx-Modules/

if you'd like to see how I handled it with the Meridian code. It's NetLinx, though.

jbeam

I've used the option like the one suggested by jeffaco many times with good success for buttons held down that increment a value sent to a serial device. ( some times had to increment the value by the value by 2 or 4 or 8 to get a better responce this would probably be hard to implement for a bargraph)

Another option I haven't tried but might work is to send a 'TXCLR' send command to the rs-232 port before each new command. This may keep commands from building up in the TX buffer.
Like
SEND_COMMAND RS_232, 'TXCLR'
NEW COMMAND

This may only send a volume when the user stops the bargraph slider or goes very slow with it.

Depending on how you want it to respond you may want to combine these techniques.


Software history description

'TXCLR' any characters waiting in the transmit out buffer will
be cleared and transmission will stop

Good Luck,

Jeff Beam

Dries Kaspers

Thanx guys! i'll try it

jbeam

A little addendum to my previous post. Send Commands seem to sometimes take a bit of time for a device to process so you may need a delay between sending it and your command.

Like:
CANCEL_WAIT 'NEW_CMD'
SEND_COMMAND RS_232, 'TXCLR'
WAIT 4 'NEW_CMD'
{
NEW COMMAND
}


Jeff