Home› AMX User Forum› AMX General Discussion
Options

Slowing down a bargraph

Dries KaspersDries Kaspers Posts: 142
in AMX General Discussion
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!

Comments

  • Options
    jeffacojeffaco Posts: 121
    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.
  • Options
    jbeamjbeam Posts: 14
    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
  • Options
    Dries KaspersDries Kaspers Posts: 142
    Thanx guys! i'll try it
  • Options
    jbeamjbeam Posts: 14
    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
Sign In or Register to comment.